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

["Andreas Färber" <afaerber@suse.de>]

Am 12.03.2012 17:50, schrieb 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.
[...]
>> 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.

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.

(I'd really like to fix this "reentrancy" but we can't just trivially
memcpy().)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg