On Fri, Mar 09, 2012 at 03:15:26PM -0600, Anthony Liguori wrote: > On 03/09/2012 03:04 PM, Daniel P. Berrange wrote: > >On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote: > >>Resurrecting an old thread: > >> > >>I didn't see any clear conclusion in this thread (this is why I am > >>resurrecting it), except that many were arguing that libvirt should > >>simply copy and/or generate the CPU model definitions from Qemu. I > >>really don't think it's reasonable to expect that. > >> > >>On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: > >>>Hi, > >>> > >>>Recently I realized that all modern CPU models defined in > >>>/etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. > >>>That's because we start qemu with -nodefconfig which results in qemu ignoring > >>>that file with CPU model definitions. We have a very good reason for using > >>>-nodefconfig because we need to control the ABI presented to a guest OS and we > >>>don't want any configuration file that can contain lots of things including > >>>device definitions to be read by qemu. However, we would really like the new > >>>CPU models to be understood by qemu even if used through libvirt. What would > >>>be the best way to solve this? > >>> > >>>I suspect this could have been already discussed in the past but obviously a > >>>workable solution was either not found or just not implemented. > >> > >>So, our problem today is basically: > >> > >>A) libvirt uses -nodefconfig; > >>B) -nodefconfig makes Qemu not load the config file containing the CPU > >> model definitions; and > >>C) libvirt expects the full CPU model list from Qemu to be available. > > > >I could have sworn we had this discussion a year ago or so, and had decided > >that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf > >and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf > >would be solely for end user configuration changes, not for QEMU builtin > >defaults. > > > >But looking at the code in QEMU, it doesn't seem we ever implemented this ? > > I don't remember that discussion and really don't think I agree with the conclusion. > > If libvirt wants to define CPU models on their own, they can. If > libvirt wants to use the user's definitions, don't use -nodefconfig. > > CPU models aren't a QEMU concept. The reason it's in the > configuration file is to allow a user to add their own as they see > fit. There is no right model names. It's strictly a policy. Honestly, I don't think every single detail of CPU definitions should be considered user-provided configuration, the cpudefs are a low-level definitions of known-to-work combinations of CPUID bits, not a proper way for a user (or even a upper layer such as libvirt) to configure a CPU from scratch. At least a set of sane defaults to be used as base should be part of what defines a "machine type". If we don't do that, we will be unable to fix bugs on those CPU definitions without having to tell users to edit their config files, and libvirt users won't be able to use any new CPU feature until support for them is implemented on libvirt. And we would confuse two sets of users: 1) the ones that are using old cpudefs but don't understand why new features aren't available even on newer machine-types (and will have to read the Intel or AMD developer manuals to understand how to enable the feature); 2) the ones that get their config files upgraded automatically and don't understand why they are getting a different virtual machine after the upgrade, even when using an older machine-type. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list