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

[Eduardo Habkost]

On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas Färber wrote:
> Am 11.03.2012 17:16, schrieb Gleb Natapov:
> > On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote:
> >> On 03/11/2012 09:56 AM, Gleb Natapov wrote:
> >>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
> >>>> -cpu best wouldn't solve this.  You need a read/write configuration
> >>>> file where QEMU probes the available CPU and records it to be used
> >>>> for the lifetime of the VM.
> >>> That what I thought too, but this shouldn't be the case (Avi's idea).
> >>> We need two things: 1) CPU model config should be per machine type.
> >>> 2) QEMU should refuse to start if it cannot create cpu exactly as
> >>> specified by model config.
> >>
> >> This would either mean:
> >>
> >> A. pc-1.1 uses -cpu best with a fixed mask for 1.1
> >>
> >> B. pc-1.1 hardcodes Westmere or some other family
> >>
> > This would mean neither A nor B. May be it wasn't clear but I didn't talk
> > about -cpu best above. I am talking about any CPU model with fixed meaning
> > (not host or best which are host cpu dependant). Lets take Nehalem for
> > example (just to move from Westmere :)). Currently it has level=2. Eduardo
> > wants to fix it to be 11, but old guests, installed with -cpu Nehalem,
> > should see the same CPU exactly. How do you do it? Have different
> > Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11).
> > Lets get back to Westmere. It actually has level=11, but that's only
> > expose another problem. Kernel 3.3 and qemu-1.1 combo will support
> > architectural PMU which is exposed in cpuid leaf 10. We do not want
> > guests installed with -cpu Westmere and qemu-1.0 to see architectural
> > PMU after upgrade. How do you do it? Have different Westmere definitions
> > for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens
> > if you'll try to run qemu-1.1 -cpu Westmere on Kernel < 3.3 (without
> > PMU support)? Qemu will fail to start.
> 
> This sounds pretty much like what Liu Jinsong and Jan are discussing in
> the TSC thread on qemu-devel. (cc'ing)

I'll look for that thread. Thanks!

> 
> IMO interpreting an explicit -cpu parameter depending on -M would be
> wrong. Changing the default CPU based on -M is fine with me. For an
> explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the
> user gets what the user asks for, without unexpected magic.

It is not unexpected magic. It would be a documented mechanism:
"-cpu Nehalem-1.0" and "-cpu Nehalem-1.1" would have the same meaning
every time, with any machine-type, but "-cpu Nehalem" would be an alias,
whose meaning depends on the machine-type.

Otherwise we would be stuck with a broken "Nehalem" model forever, and
we don't want that.

> Note that on my qom-cpu-wip branch [1] (that I hope to have cleaned up
> and sent out by tomorrow), all built-in CPUs become statically
> registered QOM types. The external definitions that get passed in via
> -cpudef become dynamically registered QOM types; I took care to allow
> overriding existing classes with the specified -cpudef fields (but
> untested). Setting family, level, etc. for -cpu is done on the X86CPU
> object instance. [2]
> What I don't have yet are QOM properties to set the fields from, e.g.,
> machine code, but those should be fairly easy to add.

Sounds interesting. I will have to take a look at the code to understand how it
affects what's being discussed in this thread.

> 
> Andreas
> 
> [1] http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-wip
> 
> [2]
> http://repo.or.cz/w/qemu/afaerber.git/commit/8a6ede101a2722b790489989f21cad38d3e41fb5
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

-- 
Eduardo