[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt
Date: Mon, 12 Mar 2012 13:42:09 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 03/12/2012 01:30 PM, Eduardo Habkost wrote:
On Mon, Mar 12, 2012 at 06:41:06PM +0100, Andreas Färber wrote:
Am 12.03.2012 17:50, schrieb Eduardo Habkost:
On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas Färber wrote:
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.

Not quite what I meant: In light of QOM we should be able to instantiate
a CPU based on its name and optional parameters IMO. No dependency on
the machine, please. An alias sure, but if the user explicitly says -cpu
Nehalem then on 1.1 it should always be an alias to Nehalem-1.1 whether
the machine is -M pc-0.15 or pc. If no -cpu was specified by the user,
then choosing a default of Nehalem-1.0 for pc-1.0 is fine. Just trying
to keep separate things separate here.

As Gleb explained, things aren't really separated:
"qemu-1.1 -M pc-1.0 -cpu Nehalem" should result in the same machine as
"qemu-1.0 -cpu Nehalem", no difference should be visible to the guest.
simply make incompatible changes.

So this is easy. CPU's need to be qdev/QOM and the various cpuid settings need to be done through qdev properties.

Then you can just add globals to the machine definition. No different than what we do with virtio-blk.


Anthony Liguori

Also keep in mind linux-user. There's no concept of a machine there, but
there's a cpu_copy() function used for forking that tries to re-create
the CPU based on its model. So currently cpu_*_init(env->cpu_model_str)
needs to be able to recreate an identical CPU through the central code
path, without access to a QEMUMachine.

So just translate the CPU alias given to "-cpu" to the true CPU model
name as soon as possible, at the command-line-handling code, so the rest
of the code always see the true CPU model name.

After all, the need to make the aliases is a command-line interface
compatibility problem, so it makes sense to handle this at the
command-line-handling code.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]