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

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 06/24/2014 01:16 AM, Markus Armbruster wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> 
>> 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 :)
>>
>> My current understanding is that multiple machines (like
>> pc-i440fx-1.4..2.1, and many others) are needed:
>>
>> 1) for the -nodefaults case when a lot of devices are still created and
>> there is no other way to configure them;
>>
>> in "pseries", only CPU + empty VIO + empty PCI buses are created,
>> everything else can be created explicitly; nothing to tweak;
>>
>> 2) to enable/disable CPUID_EXT_xxx bits (saw in x86);
>>
>> in "pseries", there is a "compat" property on CPU and that seems to be enough;
>>
>> 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;
>>
>> 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.
>>
>> Since I (almost) always miss the bigger picture, what do I miss now? :) Thanks!
> 
> Actually, the true reasons for versioned machine types are stable guest
> ABI and migration compatibility.
> 
> All the stuff you mentioned above (presence of devices, CPUID bits,
> optional device capabilities) is guest ABI.
> 
> For some machines such as PCs, we want to keep the guest ABI stable.  A
> release freezes the guest ABI.  When we do something that affects it, we
> take care to change only the current, unfrozen ABI, and not the
> previously frozen ABIs.
> 
> Versioned machine types let you pick a guest ABI.  Typical usage is to
> create a guest with the latest machine type, then stick to that machine
> type forever.
> 
> Migration turns "want to keep guest ABI stable" into "must keep guest
> ABI stable", and adds "must keep migration format compatible".  Ensured
> by using the same versioned machine type on source and destination.


As I mentioned in another mail, I am aware of migration :)

It just does not seem right that when we choose some PC version, some
device properties get tweaked, and these are not even devices which are
always present on PC machine (like NEC USB) and this tweak would make
perfect sense for other architectures but it is limited to PC anyway.



> If you don't care for migration, you probably don't need to bother with
> versioned machine types.
> 
> If all you want is configure the board, check out machine options (the
> prop=value,... you can specify in addition to the machine type).
> 


-- 
Alexey