Re: Question about vmstate_register(), dc->vmsd and instance_id

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On Thu, 17 Mar 2022 at 14:03, Daniel Henrique Barboza
> <danielhb413@gmail.com> wrote:
> > I've been looking into converting some vmstate_register() calls to use dc->vmsd,
> > using as a base the docs in docs/devel/migration.rst. This doc mentions that we
> > can either register the vmsd by using vmstate_register() or we can use dc->vmsd
> > for qdev-based devices.
> >
> > When trying to convert this vmstate() call for the qdev alternative (hw/ppc/spapr_drc.c,
> > drc_realize()) I found this:
> >
> >      vmstate_register(VMSTATE_IF(drc), spapr_drc_index(drc), &vmstate_spapr_drc,
> >                       drc);
> >
> > spapr_drc_index() is an unique identifier for these DRC devices and it's being used
> > as instance_id. It is not clear to me how we can keep using this same instance_id when
> > using the dc->vmsd alternative. By looking a bit into migration files I understood
> > that if dc->vmsd is being used the instance_id is always autogenerated. Is that correct?
> 
> Not entirely. It is the intended common setup, but because changing
> the ID value breaks migration compatibility there is a mechanism
> for saying "my device is special and needs to set the instance ID
> to something else" -- qdev_set_legacy_instance_id().

Yes, this is normally only an issue for 'system' or memory mapped
devices;  for things hung off a bus that has it's own device naming,
then each instance of a device has it's own device due to the bus name
so instance_id's aren't used.  Where you've got a few of the
same device with the same name, and no bus for them to be named by, then
the instance_id is used to uniquify them.

Dave

> > Given that this is a 13 year old comment from Anthony Liguori I wanted to confirm its
> > validity. Is there a long term goal of getting rid of instance_id? Can I ignore its
> > role when converting these calls to dc->vmsd?
> 
> Only if you're prepared to break migration compatibility, I think.
> 
> -- PMM
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK