Re: [Qemu-devel] [PATCH for-3.2 v3 13/14] hw/i386: add pc-i440fx-3.2 & pc-q35-3.2

From: Eduardo Habkost <ehabkost@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: QEMU <qemu-devel@nongnu.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org, "Corey Minyard" <minyard@acm.org>,
	amit@kernel.org, hpoussin@reactos.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"open list:ARM" <qemu-arm@nongnu.org>,
	"open list:sPAPR pseries" <qemu-ppc@nongnu.org>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	stefanb@linux.ibm.com, "Andreas Färber" <afaerber@suse.de>,
	atar4qemu@gmail.com, "Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH for-3.2 v3 13/14] hw/i386: add pc-i440fx-3.2 & pc-q35-3.2
Date: Wed, 7 Nov 2018 17:01:14 -0200	[thread overview]
Message-ID: <20181107190114.GD12503@habkost.net> (raw)
In-Reply-To: <CAJ+F1CLWy0xbb-Pc7yUNpHh70GsSTKJ=v+TeoTGJOThYO_xE2g@mail.gmail.com>

On Wed, Nov 07, 2018 at 07:49:54PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Wed, Nov 7, 2018 at 4:49 PM Marc-André Lureau
> <marcandre.lureau@redhat.com> wrote:
> >
> > The following patch is going to add compatiblity parameters for
> > qemu <= 3.1.
> >
> 
> I realize this may be good enough for x86 i440/q35 machines, but what
> about other machines & architectures?
> 
> What do we officially support, for migration, across different versions?
> 
> It seems we have versionized:
> - arm "virt" machines
> - "s390-ccw-virtio" machines
> - ppc "pseries" machines
> - x86 piix/q35 machines
> 
> At least, I think I should update this patch to add new 3.2 machines for those.

This QEMU release seems to be unusual: normally we add features
that require adding new machine-types long before soft freeze.
If we didn't add new machine-types until now, this means we
didn't introduce any guest ABI changes that require them.

Now, this is an interesting case: we probably don't _need_ the
new machine-types, but users might be confused if they don't see
new machine-types.  Should we add them anyway?

> 
> Is there any way to check compat properties are handled properly for
> those various machines? It looks like it is generally lacking. For
> example, if there is a new HW_COMPAT, it would be nice if something
> failed if a corresponding machine hasn't been added.
> 
> It also looks like there is a bit of code duplication and a bit too
> much macros :) unfortunately, I don't yet have a good idea how to
> improve things...

I dream with the day all this compatibility data will be treated
like what it is: just data.  The ugly macro trickery needs to go
away eventually, but this requires making the QOM/machine-type
APIs more practical.

Removing very old machine-types will probably make this task
easier, because they are the main source of compatibility code
that is not represented as <driver.property=value> tuples (grep
for "static void pc_compat_" and you'll see them).

-- 
Eduardo