Nothing else does this, convert to regular memory_region_init_rom().

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
 hw/display/cg3.c | 5 ++---
 hw/display/tcx.c | 5 ++---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/hw/display/cg3.c b/hw/display/cg3.c
index 568d6048a6..61bdb0552e 100644
--- a/hw/display/cg3.c
+++ b/hw/display/cg3.c
@@ -282,8 +282,8 @@ static void cg3_initfn(Object *obj)
     SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
     CG3State *s = CG3(obj);
 
-    memory_region_init_rom_nomigrate(&s->rom, obj, "cg3.prom",
-                                     FCODE_MAX_ROM_SIZE, &error_fatal);
+    memory_region_init_rom(&s->rom, obj, "cg3.prom", FCODE_MAX_ROM_SIZE,
+                           &error_fatal);
     sysbus_init_mmio(sbd, &s->rom);
 
     memory_region_init_io(&s->reg, obj, &cg3_reg_ops, s, "cg3.reg",
@@ -299,7 +299,6 @@ static void cg3_realizefn(DeviceState *dev, Error **errp)
     char *fcode_filename;
 
     /* FCode ROM */
-    vmstate_register_ram_global(&s->rom);
     fcode_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, CG3_ROM_FILE);
     if (fcode_filename) {
         ret = load_image_mr(fcode_filename, &s->rom);
diff --git a/hw/display/tcx.c b/hw/display/tcx.c
index 36cad82abd..16114b9bb8 100644
--- a/hw/display/tcx.c
+++ b/hw/display/tcx.c
@@ -756,8 +756,8 @@ static void tcx_initfn(Object *obj)
     SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
     TCXState *s = TCX(obj);
 
-    memory_region_init_rom_nomigrate(&s->rom, obj, "tcx.prom",
-                                     FCODE_MAX_ROM_SIZE, &error_fatal);
+    memory_region_init_rom(&s->rom, obj, "tcx.prom", FCODE_MAX_ROM_SIZE,
+                           &error_fatal);
     sysbus_init_mmio(sbd, &s->rom);
 
     /* 2/STIP : Stippler */
@@ -822,7 +822,6 @@ static void tcx_realizefn(DeviceState *dev, Error **errp)
     vram_base = memory_region_get_ram_ptr(&s->vram_mem);
 
     /* 10/ROM : FCode ROM */
-    vmstate_register_ram_global(&s->rom);
     fcode_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, TCX_ROM_FILE);
     if (fcode_filename) {
         ret = load_image_mr(fcode_filename, &s->rom);
-- 
2.41.3

On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> Nothing else does this, convert to regular memory_region_init_rom().

> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
>  hw/display/cg3.c | 5 ++---
>  hw/display/tcx.c | 5 ++---
>  2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/hw/display/cg3.c b/hw/display/cg3.c
> index 568d6048a6..61bdb0552e 100644
> --- a/hw/display/cg3.c
> +++ b/hw/display/cg3.c
> @@ -282,8 +282,8 @@ static void cg3_initfn(Object *obj)
>      SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
>      CG3State *s = CG3(obj);
>
> -    memory_region_init_rom_nomigrate(&s->rom, obj, "cg3.prom",
> -                                     FCODE_MAX_ROM_SIZE, &error_fatal);
> +    memory_region_init_rom(&s->rom, obj, "cg3.prom", FCODE_MAX_ROM_SIZE,
> +                           &error_fatal);
>      sysbus_init_mmio(sbd, &s->rom);
>
>      memory_region_init_io(&s->reg, obj, &cg3_reg_ops, s, "cg3.reg",
> @@ -299,7 +299,6 @@ static void cg3_realizefn(DeviceState *dev, Error **errp)
>      char *fcode_filename;
>
>      /* FCode ROM */
> -    vmstate_register_ram_global(&s->rom);
>      fcode_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, CG3_ROM_FILE);
>      if (fcode_filename) {
>          ret = load_image_mr(fcode_filename, &s->rom);

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 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.

thanks
-- PMM

On Thu, 29 Jan 2026, Peter Maydell wrote:
> On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> Nothing else does this, convert to regular memory_region_init_rom().
>
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>>  hw/display/cg3.c | 5 ++---
>>  hw/display/tcx.c | 5 ++---
>>  2 files changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/display/cg3.c b/hw/display/cg3.c
>> index 568d6048a6..61bdb0552e 100644
>> --- a/hw/display/cg3.c
>> +++ b/hw/display/cg3.c
>> @@ -282,8 +282,8 @@ static void cg3_initfn(Object *obj)
>>      SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
>>      CG3State *s = CG3(obj);
>>
>> -    memory_region_init_rom_nomigrate(&s->rom, obj, "cg3.prom",
>> -                                     FCODE_MAX_ROM_SIZE, &error_fatal);
>> +    memory_region_init_rom(&s->rom, obj, "cg3.prom", FCODE_MAX_ROM_SIZE,
>> +                           &error_fatal);
>>      sysbus_init_mmio(sbd, &s->rom);
>>
>>      memory_region_init_io(&s->reg, obj, &cg3_reg_ops, s, "cg3.reg",
>> @@ -299,7 +299,6 @@ static void cg3_realizefn(DeviceState *dev, Error **errp)
>>      char *fcode_filename;
>>
>>      /* FCode ROM */
>> -    vmstate_register_ram_global(&s->rom);
>>      fcode_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, CG3_ROM_FILE);
>>      if (fcode_filename) {
>>          ret = load_image_mr(fcode_filename, &s->rom);
>
> 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.

> 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 but get rid of these other _nomigrate variants anyhow. Let me know 
which way you prefer.

Regards,
BALATON Zoltan

On Thu, 29 Jan 2026 at 17:20, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Thu, 29 Jan 2026, Peter Maydell wrote:
> > On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <balaton@eik.bme.hu> 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

On Thu, 29 Jan 2026, Peter Maydell wrote:
> On Thu, 29 Jan 2026 at 17:20, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> On Thu, 29 Jan 2026, Peter Maydell wrote:
>>> On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <balaton@eik.bme.hu> 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 
and I have no idea about xtensa but if only those few are left that's much 
better. There's one more _nomigrate in hw/m68k/next-cube.c which seems to 
be some shared memory region (not sure why it can't be migrated) and the 
one in backends/hostmem-ram.c which may be the only real place that needs 
this. But those could be taken care of later, converting the Sun machines 
would only leave 2 or 3 usages.

>>> 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.

I agree but wait for the maintainer's opinion (and maybe some more review 
on other patches) before doing a v2. (Mark may have some reason like old 
savevm files he may use for testing and does not want to redo them or 
similar to want to keep this but if that's the only reason for using this 
old stuff it might be time to refresh those testing images.)

Regards,
BALATON Zoltan

On Thu, 29 Jan 2026 at 19:08, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Thu, 29 Jan 2026, Peter Maydell wrote:
> > On Thu, 29 Jan 2026 at 17:20, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >> On Thu, 29 Jan 2026, Peter Maydell wrote:
> >>> On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <balaton@eik.bme.hu> 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.

-- PMM

On 29/01/2026 20:22, Peter Maydell wrote:

> On Thu, 29 Jan 2026 at 19:08, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> On Thu, 29 Jan 2026, Peter Maydell wrote:
>>> On Thu, 29 Jan 2026 at 17:20, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>> On Thu, 29 Jan 2026, Peter Maydell wrote:
>>>>> On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <balaton@eik.bme.hu> 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.


ATB,

Mark.

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 <balaton@eik.bme.hu> wrote:
>>> 
>>> On Thu, 29 Jan 2026, Peter Maydell wrote:
>>>> On Thu, 29 Jan 2026 at 17:20, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>> On Thu, 29 Jan 2026, Peter Maydell wrote:
>>>>>> On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <balaton@eik.bme.hu> 
>>>>>> 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

On Thu, 29 Jan 2026, Peter Maydell wrote:
> On Thu, 29 Jan 2026 at 19:08, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> On Thu, 29 Jan 2026, Peter Maydell wrote:
>>> On Thu, 29 Jan 2026 at 17:20, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>> On Thu, 29 Jan 2026, Peter Maydell wrote:
>>>>> On Thu, 29 Jan 2026 at 16:21, BALATON Zoltan <balaton@eik.bme.hu> 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.

I think pc machines use PCI which would not change so it would only break 
isapc where we probably don't care but I don't intend to change that now. 
Just getting rid of what we can do safely to simplify the 
memory_region_init API is enough for me. The remaining few can be 
considered later but we will likely need some _nomigrate option for 
backends/hostmem-ram.c so we probably can't get rid of them all.

Regards,
BALATON Zoltan