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