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