Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc

[Michael S. Tsirkin]

On Wed, Jun 17, 2015 at 06:17:19PM +0200, Paolo Bonzini wrote:
> 
> 
> On 17/06/2015 16:29, Michael S. Tsirkin wrote:
> > On Wed, Jun 17, 2015 at 04:27:13PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 17/06/2015 16:18, Michael S. Tsirkin wrote:
> >>>>> Yes, that's what was done for parallel and pcspk as well.  There's no
> >>>>> infrastructure to avoid it.
> >>>>>
> >>>>> Paolo
> >>> How do you mean? We have multiple ways to keep devices
> >>> compatible with old versions.
> >>> Set a new property to skip the extra stuff.
> >>
> >> Not if the device didn't have a vmstate at all, unfortunately.
> > 
> > Skip creating the device completely for old machine types.
> 
> Which device?  The vmstate is tied to the same device that has always
> been created.

Just disable the new functionality. Make it behave in
a compatible way.

>  we enable this thing by default (why do we?)

Sigh. There is a very simple way to add a device in qemu: let user
request it with -device.  If one does this, one gets to maintain the
resulting mess without bothering with pc maintainers in any way.

But of course, everyone implementing a new feature feels it's such a
great thing, and completel zero risk, it must be part of the default
machine. Guess what, one then gets to bother with versioning from day 0.

> >>> this seems like a big deal ...
> >>
> >> The PC speaker device is also enabled by default.
> > 
> > This is historical, isn't it?
> 
> Yes, but it has broken 2.3->2.2 migration.
> 
> Let's just stop fighting windmills.
> 
> Paolo

I don't see what you are saying. Suddenly guest visible
changes within a machine type are ok?

So we have a bug, need to fix it, preferably before piling up
more features. The best way imho is for 2.4 to avoid
this device unless requested explicitly.

-- 
MST