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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to