On 07/07/2016 01:37 PM, Cedric Bosdonnat wrote: > Hi Jiri, all, Hey Cedric!
> As I mentioned earlier today on IRC, I have started implementing CPU > configuration > support for libxl driver. 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? > libxl expects a string definition the state of all the feature (easy to > create), but also > the numeric values for the CPU family and model. virCPUDef holds the name as > a string, but > not the numeric values though there are stored in the cpu_map.xml. > > For what libxl expects, search for 'cpuid=' in this man page: > http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html > > Any idea how to get those values from the libxl driver? 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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
