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

[Anthony Liguori]

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.

Regards,

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.
>