Re: [Qemu-devel] machines and versions - why so many?

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 06/24/2014 12:59 AM, Paolo Bonzini wrote:
> Il 23/06/2014 16:15, Alexey Kardashevskiy ha scritto:
>> Hi!
>>
>> I have been hearing recently that we (server PPC) should have more that
>> just one pseries machine in QEMU because this is what everybody else does :)
> 
> If you want to support live upgrades from QEMU 2.1 to QEMU 2.2, you should
> indeed prepare by adding a stable name such as pseries-2.1 already in QEMU
> 2.1.
>
>> My current understanding is that multiple machines (like
>> pc-i440fx-1.4..2.1, and many others) are needed:
>>
>> 3) for devices which are created explicitly and for which we want some
>> capabilities be disabled and we do not want to bother about this every time
>> we run QEMU;
> 
> This is not the exact reason.  What you wrote _could_ be a reason to use
> compat_properties, but it is not why x86 has multiple machine types.
> 
> The reason is because when you migrate from QEMU 1.7 to QEMU 2.1, the
> machine should behave exactly the same as it did in QEMU 1.7.  Any
> guest-visible change introduced between QEMU 1.7 and QEMU 2.1 (*) must be
> removed from QEMU 2.1.  This is the reason why x86 has one machine type per
> version.


Yes, migration is why I want this, correct.


>     (*) X got faster is not a guest-visible change.  A guest-visible
>         change is something like:
> 
>         - a register gets a new default value
> 
>         - a register that was read-only is now read-write
> 
>         - the size of a memory region changed (e.g. a ROM BAR grew
>           from 128k to 256k)
> 
>         Sometimes, if no known guest is using the register (e.g. only
>         firmware uses it) it is okay to skip the creation of the
>         compat property.  However, if in doubt, better add it.
> 
>> ok, this one makes some sense for "pseries" to have (and upcoming
>> endianness register on VGA seems to be the case) but it seems that adding a
>> "compat" or "feature" property to the VGA device (and other devices which
>> deal with this kind of compatibility) is still more architecturally correct
>> thing to do, and let libvirt deal with the rest.
> 
> Yes, this sounds sensible.

What does sound sensible exactly? :)

I understand that this is all needed for migration, I should have mentioned
this :) I do not understand why it has to be a new machine type every time.
No device has "compat" option yet because of legacy? Some global
machine-independent property set per QEMU version would make sense and it
would work for every machine in that QEMU version.

nec-usb-xhci is off for PC_COMPAT_1_3 because of what? PIIX emulation was
broken in 1.3? Or nec-usb-xhci? If it is the latter, why is the tweak
limited by PC?

Looks like I must copy PC_COMPAT_X_X as PSERIES_COMPAT_X_X starting 1.6 (or
1.7 - whichever starts supporting migration well enough on pseries) because
pretty much of what they do is tweaking PCI devices and we can have all of
these devices on pseries. And then keep an eye on what is happening in PC
world to copy same tweaks to pseries as they come. Is that correct?

Others (ARM, s390) do not do that because they do not support PCI? Or
migration? Or some other reason?


> Paolo
> 
>> Since I (almost) always miss the bigger picture, what do I miss now? :)
>> Thanks!
>>
>>
> 


-- 
Alexey