Re: [libvirt] cpu_map data access for libxl driver
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