Hello Joao! On Thu, 2016-07-07 at 16:20 +0100, Joao Martins wrote: > 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?
I started looking at the host cpu detection yesterday, but it seems the libxl hw_map bits aren't too easy to understand. But sure, if we can join efforts that would be good. I also couldn't find your RFC in the mailing list archives. Do you have code available somewhere? Joining efforts without stepping on each other's toes isn't that easy ;) > 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). Sure the xend format would be more flexible, however it's fairly easy to map the libvirt names to the xen ones: those are mostly the same. This also helps checking for the xen unsupported flags. Doing the mapping manually helped me see that libxl has CPU features flags that libvirt doesn't have (maybe we'll have to add them). And anyway, we will have to adjust the libvirt feature set if there are more features supported in future libxl/xen versions as libvirt's <cpu> doesn't hold the register bits but strings. > 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. The warning thing sounds good to me since we don't have a tight control on what the guest will see. > 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) Good to see things will improve soon ;) -- Cedric -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
