On 18/12/2025 08: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.
It's safe, but it still doesn't make sense for sun4u/v because there is no
machine-level I/O address space as per x86. It really does exist as a separate legacy
bus under a PCI bridge.
And it might be better to explicitly set ebus as not supporting hotplug
(via dc->hotpluggable = false).
That's correct, ebus does not support hotplug.
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?
My preference would be add to add the parent argument as it's easy to do, and doesn't
attempt to enforce x86-type constraints on other architectures.
ATB,
Mark.
