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
