* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Thu, 17 Mar 2022 at 14:03, Daniel Henrique Barboza > <danielhb...@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 / dgilb...@redhat.com / Manchester, UK
