On Thu, 29 Jan 2026 at 17:20, BALATON Zoltan <[email protected]> wrote: > > On Thu, 29 Jan 2026, Peter Maydell wrote: > > On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <[email protected]> wrote: > > This is a migration compatibility break, because the > > memory_region_init_rom() function registers the MR > > for migration via vmstate_register_ram(), which picks > > an ID string for the memory that includes the path > > of the device, whereas vmstate_register_ram_global() > > picks an ID string for the memory that does not include > > the path of any device. It is this difference that is the > > reason why they're still using the _nomigrate functions. > > I thought it might be the case but wasn't sure. How was this handled in > all other machines where they were converted to not use _nomigrate? Only > some Sun machines still seem to use this and this may be a good > opportunity to bring them inline with all other machines.
If I remember correctly, we converted all the machines where we were happy at the time to have a compat break. The remainder are not only Sun machines -- you can see in your patch 4 that xtensa and vga are also affected. > > I think it's reasonable to accept a compat break for the purposes > > of cleaning up the codebase, because these are used on sparc machine > > types and we don't version those, but the commit message needs to > > note that this is a compat break. > > If we accept that then the other memory_region_init_ram_nomigrate usages > in Sun machines could also be converted. If Mark is not open to that I'm > inclined to convert these two rom_nomigrate usages to > memory_region_init_ram_flags_nomigrate + memory_region_set_readonly > instead My preference would be to convert all these Sun devices. I think we're a bit more clear these days that migration compat matters for versioned machine types but can be (cleanly) broken for non-versioned machine types: back then it was a bit less of a well-defined rule. -- PMM
