Re: [PATCH v4 00/37] Clean-ups: qom-ify serial and remove QDEV_PROP_PTR

[Peter Maydell]

On Sun, 1 Dec 2019 at 17:27, Marc-André Lureau
<address@hidden> wrote:
>
> Hi
>
> On Sun, Dec 1, 2019 at 9:18 PM Peter Maydell <address@hidden> wrote:
> >
> > On Sun, 1 Dec 2019 at 10:19, Marc-André Lureau
> > <address@hidden> wrote:
> > >
> > > - "serial: register vmsd with DeviceClass"
> > >
> > > This is standard qdev-ification, however it breaks backward migration,
> > > but that's just how qdev_set_legacy_instance_id() works.
> >
> > I don't understand this part. Surely the whole point
> > of setting a legacy instance ID is exactly to preserve
> > migration compatibility? If it doesn't do that then what
> > does setting legacy ID value do?
> >
>
> It works in old->new direction only, because new code can match the
> legacy instance id.
>
> But when going from new->old, the legacy instance id is lost, as it
> uses new 0-based instance_id.

I still don't understand. My mental model of the situation is:

 * in the old (current) version of the code, the instance ID
   is some random thing resulting from what the old code does
 * in the new version of the code, we use qdev_set_legacy_instance_id,
   and so instead of using the ID you'd naturally get as a
   written-from-scratch qdev device, it uses the legacy value
   you pass in
 * thus the device/board in both old and new versions of QEMU
   uses the same value and migration in both directions works

I don't understand why we would ever be using a "new 0-based
instance_id" -- it seems to me that the whole point of setting
a legacy ID value is that we will use it always, and I don't
understand how the board code can know that it's going to be
the target of an old->new migration as opposed to being the
source of a new->old migration such that it can end up with
a different ID value in the latter case.

If qdev_set_legacy_instance_id() doesn't work the way I
think it does above, what *does* it do ?

thanks
-- PMM