Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

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

Am 23.06.2015 um 18:32 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
>>> On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote:
>>>> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
>>>>> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
>>>>>> Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
>>>>>>>> To help libvirt in the transition, a x86-cpu-model-dump script is provided,
>>>>>>>> that will generate a config file that can be loaded using -readconfig, based on
>>>>>>>> the -cpu and -machine options provided in the command-line.
>>>>>>>
>>>>>>> Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU
>>>>>>> configuration data to libvirt, but now I think it actually makes sense.
>>>>>>> We already have a partial copy of CPU model definitions in libvirt
>>>>>>> anyway, but as QEMU changes some CPU models in some machine types (and
>>>>>>> libvirt does not do that) we have no real control over the guest CPU
>>>>>>> configuration. While what we really want is full control to enforce
>>>>>>> stable guest ABI.
>>>>>>
>>>>>> That sounds like FUD to me. Any concrete data points where QEMU does not
>>>>>> have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machines
>>>>>> for.
>>>>>
>>>>> What Jiri is saying that the CPUs change depending on -mmachine, not
>>>>> that the ABI is broken by a given machine.
>>>>>
>>>>> The problem here is that libvirt needs to provide CPU models whose
>>>>> runnability does not depend on the machine-type. If users have a VM that
>>>>> is running in a host and the VM machine-type changes,
>>>>
>>>> How does it change, and why?
>>>
>>> Sometimes we add features to a CPU model because they were not emulated by KVM
>>> and now they are. Sometimes we remove or add features or change other fields
>>> because we are fixing previous mistakes. Recently we we were going to remove
>>> features from models because of an Intel CPU errata, but then decided to create
>>> a new CPU model name instead.
>>>
>>> See some examples at the end of this message.
>>>
>>>>
>>>>> the VM should be
>>>>> still runnable in that host. QEMU doesn't provide that, our CPU models
>>>>> may change when we introduce new machine-types, so we are giving them a
>>>>> mechanism that allows libvirt to implement the policy they need.
>>>>
>>>> I don't mind wrt CPU specifically, but we absolutely do change guest ABI
>>>> in many ways when we change machine types.
>>>
>>> All the other ABI changes we introduce in QEMU don't affect runnability of the
>>> VM in a given host, that's the problem we are trying to address here. ABI
>>> changes are expected when changing to a new machine, runnability changes
>>> aren't.
>>>
>>>
>>> Examples of commits changing CPU models:
>> [snip]
>>
>> I've always advocated remaining backwards-compatible and only making CPU
>> model changes for new machines. You among others felt that was not
>> always necessary, and now you're using the lack thereof as an argument
>> to stop using QEMU's CPU models at all? That sounds convoluted...
>>
> 
> Uh? I don't remember anybody suggesting changing CPU models on existing
> machines. We always tried to keep existing machines compatible.

Yes, we try in general. And in a few cases I was overruled, possibly
related to TCG feature filtering or something. Thought that was the
problem here - apparently not. Explanations seem to be the culprit here!

>> BTW your list does not answer my question. You would need examples where
>> a CPU model changes between machines, and I am not aware of any example
>> beyond the intentional -x.y variations. There are differences between
>> KVM and TCG though, did you mean that? i440fx and q35 should be
>> identical and isa-pc, too, and none anyway. None of this has anything to
>> do with the host CPU.
> 
> We are talking about the -x.y variations (that, yes, are intentional).
> But the fact that CPU features change (even the intentional ones in the
> -x.y machine variations) affect runnability of VMs (because enabling new
> CPU features in KVM require it to be supported by the host kernel code
> and by the host CPU).
> 
> I was not thinking about the KVM and TCG differences, but this may also
> help libvirt deal with the KVM and TCG differences if necessary.
> 
> I don't know what you mean by "i440fx and q35 should be identical"
> above.

In this thread there was a claim that CPU models varied between machine
types. I am saying that there should be no CPU model differences between
pc-i440fx-2.3 and pc-q35-2.3 etc. Thus the CPU model is not tied to one
machine, but to the version of QEMU, with -x.y matching the
corresponding release. No news to you, I would hope?

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)