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
--
|: