| Message ID | 20250125181343.59151-1-philmd@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | hw/sysbus/platform-bus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE | expand |
On 25.01.25 10:13, Philippe Mathieu-Daudé wrote: > Some SysBus devices can optionally be dynamically plugged onto > the sysbus-platform-bus (then virtual guests are aware of > mmio mapping and IRQs via device tree / ACPI rules). > > This series makes these devices explicit by having them implement > the DYNAMIC_SYS_BUS_DEVICE class, which only sets 'user_creatable' > flag to %true but makes the codebase a bit clearer (IMHO, at least > now we can grep for DYNAMIC_SYS_BUS_DEVICE). I love it. Thank you! This is clearly much more readable than the magical hint swizzling I did :). Reviewed-by: Alexander Graf <graf@amazon.com> Alex
On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote: > Some SysBus devices can optionally be dynamically plugged onto > the sysbus-platform-bus (then virtual guests are aware of > mmio mapping and IRQs via device tree / ACPI rules). Do we have some sane way to have user-pluggable sysbus devices on arm? I've played around with that a bit, with the uefi variable service I'm working on. Specifically I'd prefer to *not* have a patch wiring things up in machine type code like this ... https://lore.kernel.org/qemu-devel/20250107153353.1144978-20-kraxel@redhat.com/ ... and just use 'qemu -device uefi-vars-sysbus' instead. Something like AcpiDevAmlIfClass but for device tree seems to not exist though. Also apparently AcpiDevAmlIfClass is not used. take care, Gerd
On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote: > > Some SysBus devices can optionally be dynamically plugged onto > > the sysbus-platform-bus (then virtual guests are aware of > > mmio mapping and IRQs via device tree / ACPI rules). > > Do we have some sane way to have user-pluggable sysbus devices on arm? The answer in a general sense is "no, because user pluggable sysbus is a weird idea". "sysbus" means "it's wired into a specific bit of the memory map and to specific IRQs, and whoever does that needs to know what IRQs and bits of memory are usable, and the guest OS needs to know it's there". "user-pluggable" means "it's all automatic and the guest can just do some kind of probing for what is or isn't present". All the platform bus stuff is a nasty mess that's working around the things people want to plug in not being clean devices on probeable buses :-( And the platform bus is only supported on the "virt" board, because that's the only one where QEMU is generating its own dtb or ACPI tables where it can tell the guest "hey, there's some device here". -- PMM
On Tue, 28 Jan 2025, Peter Maydell wrote: > On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@redhat.com> wrote: >> >> On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote: >>> Some SysBus devices can optionally be dynamically plugged onto >>> the sysbus-platform-bus (then virtual guests are aware of >>> mmio mapping and IRQs via device tree / ACPI rules). >> >> Do we have some sane way to have user-pluggable sysbus devices on arm? > > The answer in a general sense is "no, because user pluggable > sysbus is a weird idea". "sysbus" means "it's wired into a > specific bit of the memory map and to specific IRQs, and whoever > does that needs to know what IRQs and bits of memory are usable, > and the guest OS needs to know it's there". "user-pluggable" means > "it's all automatic and the guest can just do some kind of > probing for what is or isn't present". All the platform bus stuff > is a nasty mess that's working around the things people want > to plug in not being clean devices on probeable buses :-( > And the platform bus is only supported on the "virt" board, > because that's the only one where QEMU is generating its > own dtb or ACPI tables where it can tell the guest "hey, > there's some device here". There are some SoCs that have memory mapped devices but different versions in the same family have different devices. Either older ones missing some devices or have less USB or network ports while newer SoCs have more of those or they have PCIe instead of PCI. Modelling these could use pluggable sysbus devices so one could add the devices needed for a SoC version without having to write or modify a board code. I think Bernhard's attempt to try creating e500 SoCs from a device tree goes in that direction too. We could also model this by having a SoC that can instantiate devices based on some properties but maybe pluggable devices could be more generic for this. The issue seems to be how to tell the board or SoC where to map it and what IRQ to connect it as this is done by the board and not the device so properties on the device to set these does not really help unless the board can somehow query it and instantiate the devices based on that. Otherwise whatever handles the -device option to create the device would need knowledge about the board. (E.g. the e500 devices are mapped in the CCSR memory region so one can't just use system address space for them.) Regards, BALATON Zoltan
On 28/1/25 13:57, BALATON Zoltan wrote: > On Tue, 28 Jan 2025, Peter Maydell wrote: >> On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@redhat.com> wrote: >>> >>> On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote: >>>> Some SysBus devices can optionally be dynamically plugged onto >>>> the sysbus-platform-bus (then virtual guests are aware of >>>> mmio mapping and IRQs via device tree / ACPI rules). >>> >>> Do we have some sane way to have user-pluggable sysbus devices on arm? >> >> The answer in a general sense is "no, because user pluggable >> sysbus is a weird idea". "sysbus" means "it's wired into a >> specific bit of the memory map and to specific IRQs, and whoever >> does that needs to know what IRQs and bits of memory are usable, >> and the guest OS needs to know it's there". "user-pluggable" means >> "it's all automatic and the guest can just do some kind of >> probing for what is or isn't present". All the platform bus stuff >> is a nasty mess that's working around the things people want >> to plug in not being clean devices on probeable buses :-( >> And the platform bus is only supported on the "virt" board, >> because that's the only one where QEMU is generating its >> own dtb or ACPI tables where it can tell the guest "hey, >> there's some device here". > > There are some SoCs that have memory mapped devices but different > versions in the same family have different devices. Either older ones > missing some devices or have less USB or network ports while newer SoCs > have more of those or they have PCIe instead of PCI. Modelling these > could use pluggable sysbus devices so one could add the devices needed > for a SoC version without having to write or modify a board code. I > think Bernhard's attempt to try creating e500 SoCs from a device tree > goes in that direction too. We could also model this by having a SoC > that can instantiate devices based on some properties but maybe > pluggable devices could be more generic for this. The issue seems to be > how to tell the board or SoC where to map it and what IRQ to connect it > as this is done by the board and not the device so properties on the > device to set these does not really help unless the board can somehow > query it and instantiate the devices based on that. Otherwise whatever > handles the -device option to create the device would need knowledge > about the board. (E.g. the e500 devices are mapped in the CCSR memory > region so one can't just use system address space for them.) IIRC Bernard's series takes a DTB as input and create the machine matching this DTB. As Peter explained, sysbus-platform-bus fits TYPE_DYNAMIC_SYS_BUS_DEVICE in free slots, then generates the corresponding ACPI/DTB. What you describe seems closer to the QEMU Dynamic Machine project, following Damien's idea: https://lore.kernel.org/qemu-devel/20220223090706.4888-1-damien.hedde@greensocs.com/ We are not quite there yet...
Am 28. Januar 2025 15:10:18 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>: >On 28/1/25 13:57, BALATON Zoltan wrote: >> On Tue, 28 Jan 2025, Peter Maydell wrote: >>> On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@redhat.com> wrote: >>>> >>>> On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote: >>>>> Some SysBus devices can optionally be dynamically plugged onto >>>>> the sysbus-platform-bus (then virtual guests are aware of >>>>> mmio mapping and IRQs via device tree / ACPI rules). >>>> >>>> Do we have some sane way to have user-pluggable sysbus devices on arm? >>> >>> The answer in a general sense is "no, because user pluggable >>> sysbus is a weird idea". "sysbus" means "it's wired into a >>> specific bit of the memory map and to specific IRQs, and whoever >>> does that needs to know what IRQs and bits of memory are usable, >>> and the guest OS needs to know it's there". "user-pluggable" means >>> "it's all automatic and the guest can just do some kind of >>> probing for what is or isn't present". All the platform bus stuff >>> is a nasty mess that's working around the things people want >>> to plug in not being clean devices on probeable buses :-( >>> And the platform bus is only supported on the "virt" board, >>> because that's the only one where QEMU is generating its >>> own dtb or ACPI tables where it can tell the guest "hey, >>> there's some device here". >> >> There are some SoCs that have memory mapped devices but different versions in the same family have different devices. Either older ones missing some devices or have less USB or network ports while newer SoCs have more of those or they have PCIe instead of PCI. Modelling these could use pluggable sysbus devices so one could add the devices needed for a SoC version without having to write or modify a board code. I think Bernhard's attempt to try creating e500 SoCs from a device tree goes in that direction too. We could also model this by having a SoC that can instantiate devices based on some properties but maybe pluggable devices could be more generic for this. The issue seems to be how to tell the board or SoC where to map it and what IRQ to connect it as this is done by the board and not the device so properties on the device to set these does not really help unless the board can somehow query it and instantiate the devices based on that. Otherwise whatever handles the -device option to create the device would need knowledge about the board. (E.g. the e500 devices are mapped in the CCSR memory region so one can't just use system address space for them.) > >IIRC Bernard's series takes a DTB as input and create the machine >matching this DTB. That's correct. It's still on my todo list to send an RFC. I first wanted to gain some experience implementing a machine in the classic way which I've now done by means of the imx8mp-evk series. Once I clean up the e500-fdt branch I'd send an RFC. Best regards, Bernhard > >As Peter explained, sysbus-platform-bus fits TYPE_DYNAMIC_SYS_BUS_DEVICE >in free slots, then generates the corresponding ACPI/DTB. > >What you describe seems closer to the QEMU Dynamic Machine project, >following Damien's idea: >https://lore.kernel.org/qemu-devel/20220223090706.4888-1-damien.hedde@greensocs.com/ >We are not quite there yet...
Some SysBus devices can optionally be dynamically plugged onto the sysbus-platform-bus (then virtual guests are aware of mmio mapping and IRQs via device tree / ACPI rules). This series makes these devices explicit by having them implement the DYNAMIC_SYS_BUS_DEVICE class, which only sets 'user_creatable' flag to %true but makes the codebase a bit clearer (IMHO, at least now we can grep for DYNAMIC_SYS_BUS_DEVICE). Philippe Mathieu-Daudé (9): hw/sysbus: Use sizeof(BusState) in main_system_bus_create() hw/sysbus: Declare QOM types using DEFINE_TYPES() macro hw/sysbus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE hw/vfio: Have VFIO_PLATFORM devices inherit from DYNAMIC_SYS_BUS_DEVICE hw/display: Have RAMFB device inherit from DYNAMIC_SYS_BUS_DEVICE hw/i386: Have X86_IOMMU devices inherit from DYNAMIC_SYS_BUS_DEVICE hw/net: Have eTSEC device inherit from DYNAMIC_SYS_BUS_DEVICE hw/tpm: Have TPM TIS sysbus device inherit from DYNAMIC_SYS_BUS_DEVICE hw/xen: Have legacy Xen backend inherit from DYNAMIC_SYS_BUS_DEVICE include/hw/sysbus.h | 2 ++ include/hw/xen/xen_pvdev.h | 3 +- hw/core/sysbus.c | 53 ++++++++++++++++++++--------------- hw/display/ramfb-standalone.c | 3 +- hw/i386/amd_iommu.c | 2 -- hw/i386/intel_iommu.c | 2 -- hw/i386/x86-iommu.c | 2 +- hw/net/fsl_etsec/etsec.c | 4 +-- hw/tpm/tpm_tis_sysbus.c | 3 +- hw/vfio/amd-xgbe.c | 2 -- hw/vfio/calxeda-xgmac.c | 2 -- hw/vfio/platform.c | 4 +-- hw/xen/xen-legacy-backend.c | 7 ++--- 13 files changed, 42 insertions(+), 47 deletions(-)