On Thu, Jul 07, 2016 at 02:37:39PM +0200, Cedric Bosdonnat wrote: I'd suggest just extending the virCPUDef to hold them, and populating it from the cpu_map.xml Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On Thu, Jul 07, 2016 at 03:46:41PM +0200, Jiri Denemark wrote: I don't see a problem with allowing the user to set these in the domain XML in general, particularly since Xen is explicitly making them settable by users. The fact that QEMU refuses to allow us to set fine grained CPU model data is just a restriction we have to live with in the QEMU driver. eg, we'd just have to report VIR_ERR_NO_SUPPORT in QEMU if these fields are set. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On 07/07/2016 01:37 PM, Cedric Bosdonnat wrote: Hey Cedric! FYI I too am working on guest <cpu> config work and have an RFC wrt to libvirt host cpu detection. Perhaps we could joint work on this? As you know, there are two forms to represent this info in xen libxl cpuid: 1) is the xend format which provides the input leaf and output registers values raw CPUID data, and 2) the libxl format. Though while man page depicts what the feature names are - the correspondent input, output registers, and feature names aren't really exported by libxl headers and will have to be replicated in libvirt and adjusted to API changes. So probably xend format would be better suited - which can possible accomodate other leafs than those described by the libxl format? There is also a special case for 'vmx' where we need to set libxl-side nestedhvm attribute to true (on HVM guests). There is one issue wrt to guest cpu features though: currently Xen and libxl don't provide a way for libxl callers to fetch the cpuid policy that the guest will actually see at boot. So, when applying a cpuid policy the lower toolstack layer (libxc) will validate may possibly disable or change some bits. Some features are incompatible depending on guest type or feature dependencies whether it is a PV or HVM guest or HAP enabled etc, alongside host supported levelling capabilities (e.g. CPUID Faulting support on Intel boxes >= IvyBridge give PV guests CPUID being controlled like HVM guests, or otherwise warn libvirt user if not supported). My point here is that even if we set the CPU features we would be blindly doing so with no assurance that the domain will see those enabled. CPU topology too isn't specifiable under libxl or Xen. But I guess this could be solved as part 2 (which I intend to tackle on) and warn the user when it's not possible to double-check cpu features info - which would be for all supported versions so far. Xen 4.7 had a great deal of improvement in this area, and future versions will have more things coming in. (http://xenbits.xen.org/docs/4.7-testing/features/feature-levelling.html) Joao

On 07/08/2016 09:08 AM, Cedric Bosdonnat 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. 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). 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? 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?), 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. 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? Joao