qemu-devel
[Top][All Lists]
Advanced

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

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc
Date: Wed, 17 Jun 2015 20:43:57 +0200

On Wed, Jun 17, 2015 at 06:48:40PM +0200, Paolo Bonzini wrote:
> 
> 
> On 17/06/2015 18:29, Michael S. Tsirkin wrote:
> > 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.
> 
> Ok.  Doesn't solve the fact that the migration stream changes just
> because dc->vmsd was NULL and now isn't.  We cannot add a subsection:
> there is no toplevel section for it to hang it from.

It seems pretty obvious:

+        vmport_rpc = isa_try_create(isa_bus, "vmport_rpc");
+        if (vmport_rpc) {
+            qdev_init_nofail(DEVICE(vmport_rpc));
+        }


Don't do this. Let user specify the device using -device vmport_rpc.
Then all issues just go away.  I don't see any reason not to do it like
this - we should have done the same for other vmport things.

-- 
MST



reply via email to

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