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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list