[libvirt] cpu_map data access for libxl driver

[Daniel P. Berrange]

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.
eg, we'd just have to report VIR_ERR_NO_SUPPORT in QEMU if these fields
are set.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|