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

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

[Alexey Kardashevskiy]

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!


-- 
Alexey

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

[Paolo Bonzini]

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.

     (*) 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.

Paolo

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

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

[Markus Armbruster]

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.

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

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

[Alexey Kardashevskiy]

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

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

[Andreas Färber]

Am 23.06.2014 23:35, schrieb Alexey Kardashevskiy:
> 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?

Please don't. There's a series by Marcel on the list converting those PC
macros to QOM. You already have a QOM sPAPR machine, so you should just
derive new legacy types as needed and override things there.

Also, -machine *is* the global mechanism we have to tell QEMU which
version you want, it's a shorthand for setting a list of global
properties. Don't forget that QEMU can be used without libvirt, so the
knowledge of which properties to set for which version is kept in QEMU.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Peter Maydell]

On 23 June 2014 22:35, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> Others (ARM, s390) do not do that because they do not support PCI? Or
> migration? Or some other reason?

ARM doesn't have versioned machines because we do not
yet support migration between QEMU versions; I think it's
currently too early to commit to that, because it's a
maintenance burden and it means you accumulate
legacy cruft and there are some changes you can't make.
At some point enough people will care about cross
version migration for ARM that we'll have to do it,
but not just yet...

thanks
-- PMM

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

[Alexey Kardashevskiy]

On 06/24/2014 07:41 AM, Andreas Färber wrote:
> Am 23.06.2014 23:35, schrieb Alexey Kardashevskiy:
>> 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?
> 
> Please don't. There's a series by Marcel on the list converting those PC
> macros to QOM. You already have a QOM sPAPR machine, so you should just
> derive new legacy types as needed and override things there.


I failed to find the series in patchworks, was it long time ago? What was
the subject?

I actually wonder if it is not going to be "-machine pseries-2.0" then what
will it look like? "-machine pseries,qemucompat=2.0"? I would think there
will be TYPE_MACHINE_X_Y types which I would use as a parent
TYPE_SPAPR_MACHINE (dynamically, as we do for the "host" CPU type) but this
is not what you are saying, correct?


> Also, -machine *is* the global mechanism we have to tell QEMU which
> version you want, it's a shorthand for setting a list of global
> properties. Don't forget that QEMU can be used without libvirt, so the
> knowledge of which properties to set for which version is kept in QEMU.

I do not forget, I use libvirt once a month :)


-- 
Alexey

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

[Alexey Kardashevskiy]

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

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

[Paolo Bonzini]

Il 23/06/2014 23:35, Alexey Kardashevskiy ha scritto:
> nec-usb-xhci is off for PC_COMPAT_1_3 because of what? PIIX emulation was
> broken in 1.3? Or nec-usb-xhci?

nec-usb-xhci is not "off".

             .driver   = "nec-usb-xhci",\
             .property = "msi",\
             .value    = "off",\

What's off is MSI (and MSI-X), because it wasn't implemented.

> If it is the latter, why is the tweak limited by PC?

Because at the time nobody cared about migration compatibility (even now 
only pSeries is starting to care).

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

It's not necessary to do this retroactively, unless you're planning to 
test forward migration from 1.6 to 2.1.  Just start with 2.2 (and add 
pseries-2.1 now as an alias).

Note that firmware interfaces and CPU features should also be versioned 
if they're guest visible.  That's the point of functions like pc_compat_1_6.

> And then keep an eye on what is happening in PC
> world to copy same tweaks to pseries as they come. Is that correct?

Yes.  We should come up sooner or later with a way to share the tweaks 
though.

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

This is not limited to PCI.  Others do not support migration across 
different QEMU versions.

Paolo

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

[Paolo Bonzini]

Il 24/06/2014 00:33, Alexey Kardashevskiy ha scritto:
>
> I actually wonder if it is not going to be "-machine pseries-2.0" then what
> will it look like? "-machine pseries,qemucompat=2.0"?

I would keep using pseries-2.0.

There might be some class hierarchy, like

    spapr-machine
      spapr-machine-2.2
        spapr-machine-2.1

I don't know what Andreas had in mind though, but you can check out 
Eduardo's patches for QOMifying the PC machines and take inspiration 
from there.  That's probably a safe bet.

Paolo

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

[Alexey Kardashevskiy]

On 06/24/2014 03:15 PM, Paolo Bonzini wrote:
> Il 23/06/2014 23:35, Alexey Kardashevskiy ha scritto:
>> nec-usb-xhci is off for PC_COMPAT_1_3 because of what? PIIX emulation was
>> broken in 1.3? Or nec-usb-xhci?
> 
> nec-usb-xhci is not "off".

Yes, my bad, I understood (but explained this wrong) that XHCI is enabled
but without MSI.


> 
>             .driver   = "nec-usb-xhci",\
>             .property = "msi",\
>             .value    = "off",\
> 
> What's off is MSI (and MSI-X), because it wasn't implemented.
>
>> If it is the latter, why is the tweak limited by PC?
> 
> Because at the time nobody cared about migration compatibility (even now
> only pSeries is starting to care).


"only pSeries"? There are plenty of x86 machines already and if it is not
for migration support, then what are they all for? :)


>> 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.
> 
> It's not necessary to do this retroactively, unless you're planning to test
> forward migration from 1.6 to 2.1.  Just start with 2.2 (and add
> pseries-2.1 now as an alias).
>
> Note that firmware interfaces and CPU features should also be versioned if
> they're guest visible.  That's the point of functions like pc_compat_1_6.
>
>> And then keep an eye on what is happening in PC
>> world to copy same tweaks to pseries as they come. Is that correct?
> 
> Yes.  We should come up sooner or later with a way to share the tweaks though.
> 
>> Others (ARM, s390) do not do that because they do not support PCI? Or
>> migration? Or some other reason?
> 
> This is not limited to PCI.  Others do not support migration across
> different QEMU versions.

Yeah, I got that now. Thanks!



-- 
Alexey

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

[Markus Armbruster]

Alexey Kardashevskiy <aik@ozlabs.ru> writes:

> On 06/24/2014 03:15 PM, Paolo Bonzini wrote:
>> Il 23/06/2014 23:35, Alexey Kardashevskiy ha scritto:
>>> nec-usb-xhci is off for PC_COMPAT_1_3 because of what? PIIX emulation was
>>> broken in 1.3? Or nec-usb-xhci?
>> 
>> nec-usb-xhci is not "off".
>
> Yes, my bad, I understood (but explained this wrong) that XHCI is enabled
> but without MSI.
>
>
>> 
>>             .driver   = "nec-usb-xhci",\
>>             .property = "msi",\
>>             .value    = "off",\
>> 
>> What's off is MSI (and MSI-X), because it wasn't implemented.
>>
>>> If it is the latter, why is the tweak limited by PC?
>> 
>> Because at the time nobody cared about migration compatibility (even now
>> only pSeries is starting to care).
>
>
> "only pSeries"? There are plenty of x86 machines already and if it is not
> for migration support, then what are they all for? :)

At the time, nobody *else* cared.  Only PC did.

Back then gerd created a way to do the compatibility stuff without
getting into the other target's hair: compat_props.  They've served us
well enough, but now that more targets get interested in migration,
their shortcomings start to hurt.  Having to duplicate device
compatibility gunk in multiple places, all far away from the device, is
decidedly suboptimal.  Better ideas welcome.

[...]

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

[Alexey Kardashevskiy]

On 06/24/2014 06:17 PM, Markus Armbruster wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> 
>> On 06/24/2014 03:15 PM, Paolo Bonzini wrote:
>>> Il 23/06/2014 23:35, Alexey Kardashevskiy ha scritto:
>>>> nec-usb-xhci is off for PC_COMPAT_1_3 because of what? PIIX emulation was
>>>> broken in 1.3? Or nec-usb-xhci?
>>>
>>> nec-usb-xhci is not "off".
>>
>> Yes, my bad, I understood (but explained this wrong) that XHCI is enabled
>> but without MSI.
>>
>>
>>>
>>>             .driver   = "nec-usb-xhci",\
>>>             .property = "msi",\
>>>             .value    = "off",\
>>>
>>> What's off is MSI (and MSI-X), because it wasn't implemented.
>>>
>>>> If it is the latter, why is the tweak limited by PC?
>>>
>>> Because at the time nobody cared about migration compatibility (even now
>>> only pSeries is starting to care).
>>
>>
>> "only pSeries"? There are plenty of x86 machines already and if it is not
>> for migration support, then what are they all for? :)
> 
> At the time, nobody *else* cared.  Only PC did.

Ah. Misinterpret. My bad. Ok.

> 
> Back then gerd created a way to do the compatibility stuff without
> getting into the other target's hair: compat_props.  They've served us
> well enough, but now that more targets get interested in migration,
> their shortcomings start to hurt.  Having to duplicate device
> compatibility gunk in multiple places, all far away from the device, is
> decidedly suboptimal.  Better ideas welcome.


I would suggest moving PC_COMPAT_X_Y things to platform-independent place
but "[RFC v2 00/39] Convert PC machine-types to QOM classes" is already
huge and complicated, and also "pseries" does not really need stuff below
1.6, may be it is not worth it...



-- 
Alexey

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

[Andreas Färber]

Am 24.06.2014 07:21, schrieb Paolo Bonzini:
> Il 24/06/2014 00:33, Alexey Kardashevskiy ha scritto:
>>
>> I actually wonder if it is not going to be "-machine pseries-2.0" then
>> what
>> will it look like? "-machine pseries,qemucompat=2.0"?
> 
> I would keep using pseries-2.0.
> 
> There might be some class hierarchy, like
> 
>    spapr-machine
>      spapr-machine-2.2
>        spapr-machine-2.1
> 
> I don't know what Andreas had in mind though, but you can check out
> Eduardo's patches for QOMifying the PC machines and take inspiration
> from there.  That's probably a safe bet.

That's pretty much what I meant, yes. (Eduardo, not Marcel then. :))
Not sure about spapr-machine vs. spapr-machine-2.2, but
pseries-2.1-machine inheriting from and overriding properties of
pseries[-2.2]-machine definitely. Whatever works.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Andreas Färber]

Am 24.06.2014 10:17, schrieb Markus Armbruster:
> Back then gerd created a way to do the compatibility stuff without
> getting into the other target's hair: compat_props.  They've served us
> well enough, but now that more targets get interested in migration,
> their shortcomings start to hurt.  Having to duplicate device
> compatibility gunk in multiple places, all far away from the device, is
> decidedly suboptimal.  Better ideas welcome.

Might it make sense to reconsider the proposed machine type hierarchy
and have machine-2.2 <- pc-i440fx-2.2, with global properties in
machine-x.y types and pc_compat_x_y() taking care of PC inheritence? We
can't inherit from both pc-x.y and machine-x.y though, so probably not,
just throwing thoughts around.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Marcel Apfelbaum]

On Mon, 2014-06-23 at 23:41 +0200, Andreas Färber wrote:
> Am 23.06.2014 23:35, schrieb Alexey Kardashevskiy:
> > 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?
> 
> Please don't. There's a series by Marcel on the list converting those PC
> macros to QOM.

Actually, I think you are referring to is Eduardo's series :)
http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg03155.html

Thanks,
Marcel

>  You already have a QOM sPAPR machine, so you should just
> derive new legacy types as needed and override things there.
> 
> Also, -machine *is* the global mechanism we have to tell QEMU which
> version you want, it's a shorthand for setting a list of global
> properties. Don't forget that QEMU can be used without libvirt, so the
> knowledge of which properties to set for which version is kept in QEMU.
> 
> Cheers,
> Andreas
> 

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

[Alexey Kardashevskiy]

On 06/24/2014 09:22 PM, Andreas Färber wrote:
> Am 24.06.2014 10:17, schrieb Markus Armbruster:
>> Back then gerd created a way to do the compatibility stuff without
>> getting into the other target's hair: compat_props.  They've served us
>> well enough, but now that more targets get interested in migration,
>> their shortcomings start to hurt.  Having to duplicate device
>> compatibility gunk in multiple places, all far away from the device, is
>> decidedly suboptimal.  Better ideas welcome.
> 
> Might it make sense to reconsider the proposed machine type hierarchy
> and have machine-2.2 <- pc-i440fx-2.2, with global properties in
> machine-x.y types and pc_compat_x_y() taking care of PC inheritence? We
> can't inherit from both pc-x.y and machine-x.y though, so probably not,
> just throwing thoughts around.


I wanted to suggest this but I do not want even think about multiple
inheritance in QOM :)

And in fact all I would possibly want for pseries from those versioned PCs
is those PC_COMPAT_X_Y things with enforced device properties.


-- 
Alexey

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

[Alexey Kardashevskiy]

On 06/24/2014 09:15 PM, Andreas Färber wrote:
> Am 24.06.2014 07:21, schrieb Paolo Bonzini:
>> Il 24/06/2014 00:33, Alexey Kardashevskiy ha scritto:
>>>
>>> I actually wonder if it is not going to be "-machine pseries-2.0" then
>>> what
>>> will it look like? "-machine pseries,qemucompat=2.0"?
>>
>> I would keep using pseries-2.0.
>>
>> There might be some class hierarchy, like
>>
>>    spapr-machine
>>      spapr-machine-2.2
>>        spapr-machine-2.1
>>
>> I don't know what Andreas had in mind though, but you can check out
>> Eduardo's patches for QOMifying the PC machines and take inspiration
>> from there.  That's probably a safe bet.
> 
> That's pretty much what I meant, yes. (Eduardo, not Marcel then. :))

Aha. Eduardo, okaaaay :)

I looked there, I fail to see why I should not cut-n-paste PC_COMPAT_XXX
stuff to pseries and how that patchset helps me at all so any clues are
very appreciated :)


> Not sure about spapr-machine vs. spapr-machine-2.2, but
> pseries-2.1-machine inheriting from and overriding properties of
> pseries[-2.2]-machine definitely. Whatever works.


-- 
Alexey