On 18/12/2025 11:22, Philippe Mathieu-Daudé wrote:
On 18/12/25 09:52, Zhao Liu wrote:
I think maybe one reason to use `ebus` is because...
- sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
- memory_region_add_subregion(pci_address_space_io(ebus), BIOS_CFG_IOPORT,
^^^^^^^^^^^^^^^^^^^^^^^^^^
... because the parent region is managed by ebus.
Perhaps we should add another argument: Object *parent?
I thought about it but don't think so, all instances but this one use
the machine container.
I'll improve the description.
The reason that the fw_cfg device lives under ebus on sun4u is because the
ebus device is effectively a PCI-ISA bridge, and the fw_cfg port is mapped
into I/O address space along with other ISA devices. I'm not sure that
setting the parent to the machine is the right thing to do here.
Thanks Philippe and Mark, IIUC, ebus doesn't have the hotplug use case,
so it lives long enough like the sun4u/v machine, therefore replacing
the parent object "ebus" with machine is safe.
And it might be better to explicitly set ebus as not supporting hotplug
(via dc->hotpluggable = false).
Adding a "parent" argument to the generic interface fw_cfg_init_io_nodma()
doesn't seem necessary at the moment, since using the default machine as
parent seems enough to meet all current needs in QEMU.
What do you think?
fw_cfg is per guest, and there can only be once instance of it; so IMHO it
makes sense to use the machine as parent. I should have posted a better
commit description upfront, sorry.
That's true, but the I/O is mapped to the ISA bus and so if the ISA bus does not
exist, it is impossible to access the device even if it exists on the machine.
Following on from this: at some point should we not be aiming for a qdev bus to have
its devices as QOM children? Assigning fw_cfg directly to the machine would also be
wrong in this scenario.
ATB,
Mark.
