On Fri, 30 Jan 2026, Mark Cave-Ayland wrote:
On 29/01/2026 20:22, Peter Maydell wrote:
On Thu, 29 Jan 2026 at 19:08, BALATON Zoltan <[email protected]> wrote:
On Thu, 29 Jan 2026, Peter Maydell wrote:
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.
Well, almost all of the usages are because of the Sun machines and those
could be easily converted accepting one time migration break. The VGA one
seems to be because of isa cards which may not have been QOM'ified so
could not be converted before but maybe could be now but I haven't checked
We can't change the the vga usage, because it's a migration compat
break, and you can use vga on x86 PC machines, where we do care
about not breaking migration.
Yeah. Whilst we don't necessarily guarantee Sun machine migration between
QEMU versions, I'd still like to keep it if possible. If the Sun machines
were the last holdout here then I'd say let's just accept the break: however
given that it's impossible to remove these functions because of VGA then the
reasons for breaking migration compatibility become much less compelling.
The Sun machines are pretty much the last ones using these. The
memory_region_init_rom_nomigrate() function is only used by cg3 and tcx
and nothing else so if we remove those we already have a migration break
for these devices so it would be a good time to also convert the Sun
machines now. The memory_region_init_ram_nomigrate() function is used by
cg3, tcx, sun4m, sun4u, xtfpga and vga so most of the usage is in Sun
machines and related devices. I think we could also convert xtfpga used by
xtensa as that's also not versioned so no migration guarantee but I know
nothing about that so I'm waiting for some opinion from the maintainers of
that machine.
In vga the memory_region_init_ram_nomigrate function is used only to keep
compatibility for old machines based on the global-vmstate property which
is recognised by VGA, vmware-svga, cirrus-vga and qxl but defaults to
false for all of these so all machines where we care about migration
already use the new way and would not break when we converted vga to
memory_region_init_ram. The global-vmstate property is only set to true in
hw_compat_2_12 (which probably can be removed because due to auto
deprecation and Philippe's previous work the oldest visible pc and q35
machine is currently 5.1). Apart from that global-vmstate is also set to
true by isa-vga, isa-cirrus-vga and vga-mmio (the last of which is used by
mips/jazz machine) so we don't have any machines with migration
compatibility requirement that would prevent removing the usage from vga
as well if we accept migration break for isa-pc and mips/jazz which I
think we could but I'd leave that for later to untangle this after at
least the old no longer needed hw_compat settings are removed from
hw/core/machine.c.
So besides the vga and xtensa which I think could also be converted all
remaining usages are in the Sun machines and their display devices and
converting those are easy that I'm willing to do in this series. In light
of that would you accept the migration break for the Sun machines to
remove most of the still active usages of these functions? If I hear back
from xtensa I can convert that too and vga could be done separately
afterwards as I think that does not fit the scope of this series but
there's nothing that makes it impossible to do as no active versioned
machines still depend on this feature of vga.
Do you know about anybody using migration with these Sun machines that
would be affected by this change? As we make no guarantee about migration
compatibility for these it would still not prevent us from changing it but
if we don't even know about any active users then it's even less critical
to keep to the old way for these machines when all other machines were
long converted.
Regards,
BALATON Zoltan
