[libvirt] cpu_map data access for libxl driver

[Cedric Bosdonnat]

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