Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Eduardo Habkost]

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