Re: [PATCH] hw/display/tcx: Init memory regions in realize

[Peter Xu <peterx@redhat.com>]

On Mon, Mar 16, 2026 at 04:36:23PM +0000, Peter Maydell wrote:
> On Mon, 16 Mar 2026 at 16:23, Thomas Huth <thuth@redhat.com> wrote:
> >
> > On 16/03/2026 17.06, Peter Xu wrote:
> > > On Mon, Mar 16, 2026 at 02:06:51PM +0100, BALATON Zoltan wrote:
> > >> Due to aux-ram-share property qemu_ram_alloc_internal dereferences
> > >> current_machine which is not set during init when inspecting the
> > >> device. This causes the qtest/device-introspect-test to fail since a
> > >
> > > Does it has anything to do with aux-ram-share?  I thought it's because the
> > > qom introspect test will create yet another sun-tcx device, causing double
> > > registration?
> >
> > I think it happens because the test starts QEMU with the sun4m machine (or
> > whichever machine uses this device by default), and then creates another
> > instance of the device for introspection (without realizing it). You can
> > easily recreate the bug manually like this:
> >
> >   $ ./qemu-system-sparc -M SS-20 -display none -monitor stdio
> >   QEMU 10.2.50 monitor - type 'help' for more information
> >   (qemu) device_add sun-tcx,help
> >   RAMBlock "tcx.prom" already registered, abort!
> >   Aborted (core dumped)
> >
> > An instance_init() function should not change the global state of QEMU, so
> > registering memory regions this way is a no-go. This has to be done in
> > realize() instead.
> 
> Ah, and previously we created the MR in instance_init but did
> the vmstate_register_ram_global() in realize, so we didn't see this.
> 
> I'm a little surprised that this causes a problem, though -- I
> thought that we constructed the RAM idstr not just from the
> provided string but also including the qdev path, so that
> you could have multiple devices of the same type. I guess that
> we don't get that happening correctly because the device isn't
> sufficiently created to have a qdev path yet when we haven't
> even finished instance_init ?

Device sun-tcx's parent bus is TYPE_SYSTEM_BUS, which doesn't provide
->get_dev_path().. so IIUC it'll generate the same name.

Thanks,

-- 
Peter Xu