qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH for-3.2 v3 13/14] hw/i386: add pc-i44


From: Eduardo Habkost
Subject: Re: [Qemu-arm] [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
User-agent: Mutt/1.9.2 (2017-12-15)

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
> <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]