[libvirt] cpu_map data access for libxl driver

[Cedric Bosdonnat]

Hey Joao,

On Fri, 2016-07-08 at 16:22 +0100, Joao Martins wrote:
> Indeed, libxl hw_caps changes from Xen 4.4-4.6 to Xen 4.7 - and it wasn't somewhat
> stabilized until the latter, although field is provided from even earlier xen
> versions. So the quirk there is to handle that, other than that is plain cpuid leaves
> output.

Hum, hopefully you're much more aware of the libxl things than me ;) I didn't notice
the hw_caps changed.

> Ah, sure! I don't have a public tree available these days - let me post that shortly
> on the list for discussion and we could continue from there (will CC you on the series).

Thanks for the patch series. I'll have a look at it.

> Hmm, mapping would be fairly easy indeed. I was more concerned about duplication
> in libxl driver - specially as these feature names in libxl are private (as seen from
> a library perspective and will have to piggy back what it is on libxl_cpuid.c, even
> though mnemonics are similar). While having to keep up with changes between libxl and
> cpu_map.xml in between. But perhaps may be that's less of a concern as cpu_map.xml is
> made thinking for that sort of adjustments?

For sure using the bits would avoid duplicating the feature strings in the libxl driver,
though I find them much more readable... but that point doesn't weight that much in the
balance.

> The register bits can be fetched as far as I could see from the APIs (see below). I
> was more thinking along the lines of knowing the register bits from each feature name
> somehow and just construct the string accordingly (potentially leading to a smaller
> amounts of code?),

Getting the register bits for each feature name from the cpu_map is something Jiri
could surely help us with ;)

>  and then support xl format whenever everything is exported. Or you
> think it's a less preferable way to how it should be handled in libvirt? On the other
> hand the xend syntax might be more cumbersome when setting things that we shouldn't,
> even though is up to the libxl cpuid policy to validate.

We will still have some sort of prevalidation on the libxl driver side I think, whatever
the format we use: this would help error reporting by failing earlier.

> Irrespective of the format we decide to use - we need somehow to convert a guest
> <cpu> definition a complete list of CPUID/featurename data or pre-store id in cpu map
> definitions in libxl cfg object. We can actually get the CPUID part through
> cpuGuestData() (the input/ouput registers). Say for example on running on a Broadwell
> processor and we use this cpu definition (the example doesn't make a lot of sense
> here, it's just for the purpose of pointing out the issue):
> 
> <cpu match='exact'>
>    <model>Nehalem</model>
>    <feature policy='require' name='avx'/>
> </cpu>
> 
> The CPUID registers part coming from cpuGuestData returns me this:
> 
> libxlMakeCPU:318 : CPUID[0] input=(EAX=1,ECX=0) :EAX=000306d0, EBX=00000000
> ECX=10982201 EDX=078bfbfd
> libxlMakeCPU:318 : CPUID[1] input=(EAX=7,ECX=0) :EAX=00000000, EBX=00000000
> ECX=00000000 EDX=00000000
> libxlMakeCPU:318 : CPUID[2] input=(EAX=d,ECX=1) :EAX=00000000, EBX=00000000
> ECX=00000000 EDX=00000000
> libxlMakeCPU:318 : CPUID[3] input=(EAX=80000001,ECX=0) :EAX=00000000, EBX=00000000
> ECX=00000001 EDX=20100800
> libxlMakeCPU:318 : CPUID[4] input=(EAX=80000007,ECX=0) :EAX=00000000, EBX=00000000
> ECX=00000000 EDX=00000000
> 
> So we would need to set too all features corresponding to Nehalem model as described
> by cpu_map.xml, plus setting up AVX (in the context of this example). libxl keeps no
> info of features associated with each model/family so there wouldn't be a shortcut
> akin to QEMU where IIUC libvirt feeds qemu with the expected models and features that
> it will use. Thoughts?

Not sure what is the best way to do it... may be Jiri knows.

--
Cedric