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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list