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

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

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.

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