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

[Andreas Färber]

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

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.

Regards,
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)