[libvirt] cpu_map data access for libxl driver

[Jiri Denemark]

On Thu, Jul 07, 2016 at 15:02:05 +0100, Daniel P. Berrange wrote:
> On Thu, Jul 07, 2016 at 03:46:41PM +0200, Jiri Denemark wrote:
> > On Thu, Jul 07, 2016 at 13:47:28 +0100, Daniel P. Berrange wrote:
> > > On Thu, Jul 07, 2016 at 02:37:39PM +0200, Cedric Bosdonnat wrote:
> > > > Hi Jiri, all,
> > > > 
> > > > As I mentioned earlier today on IRC, I have started implementing CPU configuration
> > > > support for libxl driver.
> > > > 
> > > > 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.
> > 
> > Yeah, the family/model values are currently only used for better host
> > CPU detection so they are not exposed outside the cpu driver.
> > 
> > > > For what libxl expects, search for 'cpuid=' in this man page:
> > > > http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
> > 
> > Oh, I was about to suggest the cpuEncode API to translate virCPUDef into
> > CPUID data, but now I see libxl added a new syntax which does not
> > require messing with raw CPUID data, which is nice.
> > 
> > > > Any idea how to get those values from the libxl driver?
> > > 
> > > I'd suggest just extending the virCPUDef to hold them, and populating it from
> > > the cpu_map.xml
> > 
> > This is an option, but if model/family is stored in virCPUDef, which is
> > just an internal representation of the <cpu> XML element, we should
> > probably format and parse the values. But doing so would mean users can
> > set them in domain XML, which I believe is not something we want to
> > allow. So either we will not add any formatting/parsing code for family
> > and model breaking the relation between *Def and XML elements, or we
> > need to come up with a different solution...
> 
> I don't see a problem with allowing the user to set these in the domain
> XML in general, particularly since Xen is explicitly making them settable
> by users. The fact that QEMU refuses to allow us to set fine grained CPU
> model data is just a restriction we have to live with in the QEMU driver.

Well, QEMU allows a user to select a CPU model by name while libxl uses
family/model numbers directly. Since our XML definition already includes
a model name (which implies the corresponding family/model numbers),
adding the raw family/model numbers sounds somewhat redundant (although
it provides more control) to me and we need to deal with this
redundancy. We'd need to clearly document what happens when the provided
family/model numbers do not match the CPU model name (even if the
documentation would say the result is undefined and either the CPU model
name or family/model numbers may be just ignored depending on the
hypervisor). In general, I think we should discourage users from using
the family/model numbers directly (unless they know what they are doing)
and let libvirt translate the model name into family/model numbers if
needed.

If we go this way, libxl will be able to use a new virCPUUpdate[1]
internal API to fill in the missing family/model numbers in the CPU
definition provided in domain XML.

[1] it's not even on the mailing list, but you can look at
https://gitlab.com/jirkade/libvirt/commits/cpu-probing -- the branch is
most likely broken and will not even compile in its current state, but
you can get the idea about what it may going to look like once I send it
for review on this list.

Jirka