On Sun, 1 Dec 2019 at 17:27, Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > > Hi > > On Sun, Dec 1, 2019 at 9:18 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > > > On Sun, 1 Dec 2019 at 10:19, Marc-André Lureau > > <marcandre.lur...@gmail.com> 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
