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 18:42 schrieb Daniel P. Berrange:
> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
>> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
>>> 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...
>>>
>>> Whether QEMU changed the CPU for existing machines, or only for new
>>> machines is actually not the core problem. Even if we only changed
>>> the CPU in new machines that would still be an unsatisfactory situation
>>> because we want to be able to be able to access different versions of
>>> the CPU without the machine type changing, and access different versions
>>> of the machine type, without the CPU changing. IOW it is the fact that the
>>> changes in CPU are tied to changes in machine type that is the core
>>> problem.
>>
>> But that's because we are fixing bugs.  If CPU X used to work on
>> hardware Y in machine type A and stopped in machine type B, this is
>> because we have determined that it's the right thing to do for the
>> guests and the users. We don't break stuff just for fun.
>> Why do you want to bring back the bugs we fixed?
> 
> Huh, I never said we wanted to bring back bugs. This is about allowing
> libvirt to fix the CPU bugs in a way that is independant of the machine
> types and portable across hypervisors we deal with. We're absolutely
> still going to fix CPU model bugs and ensure stable guest ABI.

No, that's contradictory! Through the -x.y machines we leave bugs in the
old models *exactly* to assure a stable guest ABI. Fixes are only be
applied to new machines, thus I'm pointing out that you should not use a
new CPU model with an old machine type.

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)