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 19:08 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 18:38 schrieb Eduardo Habkost:
>>> 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:
>>>>> 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?
>>>
>>> I didn't take the time to count them, but I bet most of the commits I
>>> listed on my previous e-mail message are not bug fixes, but new
>>> features.
>>
>> Huh? Of course the latest machine model get new features. The point is
>> that the previous ones don't and that's what we are providing them for -
>> libvirt is expected to choose one machine and the contract with QEMU is
>> that for that machine the CPU does *not* grow new features, and we're
>> going at great lengths to achieve that. So this thread feels more and
>> more weird...
> 
> We are not talking about changes to existing machines. We are talking
> about having changes introduced in new machines (the one we did on
> purpose) affecting the runnability of the VM.

You are talking abstract!


Example 1:

Point A: Machine pc-i440fx-2.3 exists

Runs or runs not.

Point B: Machine pc-i440fx-2.3 still exists

Still runs or runs not due to guest ABI stability rules.


Example 2:

Point A: pc-i440fx-2.4 does not exist in 2.3

Does not run becomes it doesn't exist.

Point B: New pc-i440fx-2.4

Runs or does not run, and if so has more features than pc-i440fx-2.3.

There is no runnability problem - either it runs or it doesn't, but
there's no change over time.

This is what the machine -x.y versioning is all about.

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)