* Call to clean up QOM onboard devices lacking a parent
@ 2026-07-09 14:59 Markus Armbruster
2026-07-09 16:02 ` BALATON Zoltan
0 siblings, 1 reply; 9+ messages in thread
From: Markus Armbruster @ 2026-07-09 14:59 UTC (permalink / raw)
To: qemu-devel
Cc: Aditya Gupta, Alexander Graf, Alexandre Iooss,
Alexey Kardashevskiy, Alistair Francis, Alistair Francis,
Antony Pavlov, Artyom Tarasenko, BALATON Zoltan, Bernhard Beschow,
Bibo Mao, Brian Cain, Chao Liu, Christian Borntraeger,
Clément Chigot, Cédric Le Goater, Dorjoy Chowdhury,
Edgar E. Iglesias, Eric Farman, Farhan Ali, Felipe Balbi,
Francisco Iglesias, Frederic Konrad, Gaurav Sharma, Gautam Gala,
Glenn Miles, Halil Pasic, Hao Wu, Harsh Prateek Bora,
Helge Deller, Hendrik Brueckner, Hervé Poussineau,
Huacai Chen, Jan Kiszka, Jared Rossi, Joel Stanley,
Laurent Vivier, Manos Pitsidianakis, Mark Cave-Ayland,
Matthew Rosato, Max Filippov, Michael Rolnik, Michael S. Tsirkin,
Nicholas Piggin, Niek Linnenbank, Palmer Dabbelt, Paolo Bonzini,
Peter Maydell, Philippe Mathieu-Daudé, Pierrick Bouvier,
Ran Wang, Richard Henderson, Sai Pavan Boddu, Samuel Tardieu,
Sergio Lopez, Song Gao, Stafford Horne, Subbaraya Sundeep,
Thomas Huth, Tyrone Ting, qemu-arm, qemu-ppc, qemu-riscv,
qemu-s390x
A QOM object must be the child of exactly one parent. This defines the
QOM composition tree. The link from parent to child is a property of
the parent, and therefore has a name that is unique within its parent.
An object's canonical QOM path is these names on the path from root to
object in the QOM composition tree separated by '/'.
For devices:
* If a device is plugged in with -device / device_add, and it has an ID,
we make it a child of /machine/peripheral/ with name ID. If it
doesn't have an ID, we make it a child of /machine/peripheral-anon/
with name device[N], where N counts up from zero. The canonical QOM
path /machine/peripheral/ID is stable. The canonical QOM path
/machine/peripheral-anon/device[N] isn't: it depends on the number of
devices already there.
* If a device is part of another device, it should be its child. The
child's canonical QOM path is the parent's plus '/CHILD-NAME'. Stable
as long as the parent's path and the child name are.
* "Should" because we have a lot of code that fails to pick the parent.
When such a device gets realized, we make it a child of
/machine/unattached/ orphanage with name device[N], where N counts up
from zero. The canonical QOM path /machine/unattached/device[N]
depends on the number of children already in the orphanage, which
makes it unstable.
Letting code get away with not picking a parent was a mistake. I
guess it "saved" us some thinking about what's part of what when
converting existing devices to QOM. In other words, it enabled sloppy
hardware modeling. We've been "saving" thinking ever since.
I want /machine/unattached/ to be empty. If an onboard device isn't
part of another device, put it into /machine/ with a sensible name.
How big is the problem? I put a printf() into device_set_realized() to
show me devices being put into the orphanage, then ran every machine
with arguments "-nodefaults -S -display none -monitor stdio". A few
machines crash, which I just reported[*]. For these, my results are
incomplete.
Of course, a device being put into the orphanage is not the device's
fault, but the code's that creates and realizes it.
The following machines don't trigger the printf:
target machines
------------------------------------------------
<any> none
aarch64 arm kzm musca-a musca-b1 netduino2
i386 x64_64 x-remote
microblaze xlnx-zynqmp-pmu
ppc ppc64 ppe42_machine
rx gdbsim-r5f562n7 gdbsim-r5f562n8
tricore KIT_AURIX_TC277_TRB
Most machines do, i.e. they put onboard devices into the orphanage.
Often just a few. If you maintain a machine, please having a look.
= target
== machine type
device-type count
------------------------------------------------
= ../qemu/bld/qemu-system-aarch64
== amd-versal-virt
mt35xu01g 4
== amd-versal2-virt
mt35xu01g 4
== anacapa-bmc
aspeed.i2c.slave 16
at24c-eeprom 10
pca9546 3
pca9548 4
pca9552 6
== ast1030-evb
aspeed.i2c.slave 14
smbus-eeprom 1
tmp105 1
== ast1040-evb
aspeed.i2c.slave 14
smbus-eeprom 1
tmp105 1
== ast1060-evb
aspeed.i2c.slave 14
== ast2500-evb
aspeed.i2c.slave 14
smbus-eeprom 1
tmp105 1
unimplemented-device 1
== ast2600-evb
aspeed.i2c.slave 16
smbus-eeprom 1
tmp105 1
unimplemented-device 1
== ast2700a1-evb
aspeed.i2c.slave 48
tmp105 1
== ast2700a2-evb
aspeed.i2c.slave 48
tmp105 1
== ast2700fc
aspeed.i2c.slave 48
tmp105 1
w25q01jvq 2
w25q512jv 1
== b-l475e-iot01a
unimplemented-device 44
== bletchley-bmc
aspeed.i2c.slave 16
at24c-eeprom 2
ds1338 1
pca9552 14
tmp421 10
== bpim2u
axp221_pmu 1
sd-card 4
serial-mm 8
unimplemented-device 76
== canon-a1100
cfi.pflash02 1
digic 1
== catalina-bmc
aspeed.i2c.slave 16
at24c-eeprom 17
ds1338 1
pca9535 2
pca9546 6
pca9548 2
pca9552 12
pca9554 1
tmp105 3
tmp421 2
== collie
cfi.pflash01 2
pxa25x-timer 1
sa1110-arm-cpu 1
scoop 1
strongarm-gpio 1
strongarm-ppc 1
strongarm-rtc 1
strongarm-ssp 1
strongarm-uart 3
strongarm_pic 1
== cubieboard
axp209_pmu 1
sd-card 1
serial-mm 1
unimplemented-device 1
== emcraft-sf2
s25sl12801 1
unimplemented-device 10
== fby35-bmc
adm1272 1
aspeed.i2c.slave 16
at24c-eeprom 5
tmp105 3
tmp421 1
== fuji-bmc
aspeed.i2c.slave 16
at24c-eeprom 24
pca9548 15
tmp105 39
tmp422 1
== g220a-bmc
aspeed.i2c.slave 14
emc1413 3
smbus-eeprom 1
== gb200nvl-bmc
aspeed.i2c.slave 16
at24c-eeprom 3
pca9546 6
pca9554 3
unimplemented-device 1
== imx25-pdk
sd-card 2
== imx8mm-evk
unimplemented-device 68
== imx8mp-evk
unimplemented-device 101
== integratorcp
arm926-arm-cpu 1
icp-ctrl-regs 1
integrator_core 1
integrator_debug 1
integrator_pic 2
integrator_pit 1
pl011 2
pl031 1
pl041 1
pl050_keyboard 1
pl050_mouse 1
pl181 1
== kudo-bmc
at24c-eeprom 2
l2x0 1
mx66u51235f 2
pca9548 4
sd-card 1
serial-mm 4
tmp105 8
unimplemented-device 33
== kzm
== lm3s6965evb
pl022 1
pl061_luminary 7
sd-card-spi 1
ssi-sd 1
stellaris-adc 1
stellaris-i2c 2
unimplemented-device 6
== lm3s811evb
pl022 1
pl061_luminary 5
ssd0303 1
stellaris-adc 1
stellaris-i2c 1
unimplemented-device 6
== max78000fthr
unimplemented-device 43
== mcimx6ul-evk
sd-card 2
unimplemented-device 28
== mcimx7d-sabre
sd-card 3
unimplemented-device 25
== microbit
unimplemented-device 2
== mori-bmc
l2x0 1
mx66u51235f 1
serial-mm 4
unimplemented-device 33
== mps2-an385
cmsdk-apb-uart 5
lan9118 1
or-irq 3
pl022 5
unimplemented-device 16
versatile_i2c 4
== mps2-an386
cmsdk-apb-uart 5
lan9118 1
or-irq 3
pl022 5
unimplemented-device 16
versatile_i2c 4
== mps2-an500
cmsdk-apb-uart 5
lan9118 1
or-irq 3
pl022 5
unimplemented-device 16
versatile_i2c 4
== mps2-an505
lan9118 1
unimplemented-device 1
== mps2-an511
cmsdk-apb-uart 5
lan9118 1
or-irq 8
pl022 5
unimplemented-device 16
versatile_i2c 4
== mps2-an521
lan9118 1
unimplemented-device 1
== mps3-an524
lan9118 1
unimplemented-device 1
== mps3-an536
cortex-r52-arm-cpu 1
lan9118 1
unimplemented-device 8
== mps3-an547
lan9118 1
unimplemented-device 3
== musca-a
== musca-b1
== musicpal
arm926-arm-cpu 1
gpio_i2c 1
musicpal-misc 1
musicpal_gpio 1
musicpal_key 1
musicpal_lcd 1
mv88w8618_eth 1
mv88w8618_flashcfg 1
mv88w8618_pic 1
mv88w8618_pit 1
mv88w8618_wlan 1
or-irq 1
serial-mm 2
wm8750 1
== netduino2
== netduinoplus2
unimplemented-device 42
== none
== npcm750-evb
l2x0 1
serial-mm 4
tmp105 4
unimplemented-device 33
w25q256 1
== npcm845-evb
serial-mm 7
tmp105 1
unimplemented-device 60
w25q256 1
== nuri
arm_gic 1
exynos4210-ehci-usb 1
exynos4210.clk 1
exynos4210.fimd 1
exynos4210.i2c 9
exynos4210.mct 1
exynos4210.pmu 1
exynos4210.pwm 1
exynos4210.rng 1
exynos4210.rtc 1
exynos4210.uart 4
l2x0 1
pl330 3
s3c-sdhci 4
sd-card 4
== olimex-stm32-h405
unimplemented-device 42
== orangepi-pc
aw-h3-ehci-usb 4
sd-card 1
serial-mm 4
sysbus-ohci 4
unimplemented-device 57
== palmetto-bmc
aspeed.i2c.slave 14
ds1338 1
smbus-eeprom 1
tmp423 1
unimplemented-device 1
== quanta-gbs-bmc
l2x0 1
mx66u51235f 1
sd-card 1
serial-mm 4
unimplemented-device 33
== quanta-gsj
at24c-eeprom 2
l2x0 1
mx25l25635e 1
pca9548 1
serial-mm 4
tmp105 4
unimplemented-device 33
== quanta-q71l-bmc
aspeed.i2c.slave 14
pca9546 2
pca9548 1
tmp105 3
unimplemented-device 1
== rainier-bmc
aspeed.i2c.slave 16
at24c-eeprom 21
dps310 1
max31785 1
pca9546 4
pca9552 16
tmp105 13
tmp423 4
unimplemented-device 1
== raspi0
sd-card 1
== raspi1ap
sd-card 1
== raspi2b
sd-card 1
== raspi3ap
sd-card 1
== raspi3b
sd-card 1
== raspi4b
sd-card 1
== realview-eb
arm926-arm-cpu 1
pl041 1
realview_gic 1
realview_sysctl 1
== realview-eb-mpcore
arm11mpcore-arm-cpu 1
l2x0 1
pl041 1
realview_mpcore 1
realview_sysctl 1
== realview-pb-a8
cortex-a8-arm-cpu 1
pl041 1
realview_gic 1
realview_sysctl 1
== realview-pbx-a9
a9mpcore_priv 1
cortex-a9-arm-cpu 1
l2x0 1
pl041 1
realview_sysctl 1
== romulus-bmc
aspeed.i2c.slave 14
ds1338 1
unimplemented-device 1
== sabrelite
l2x0 1
sst25vf016b 1
unimplemented-device 1
== sbsa-ref
arm-gicv3 1
arm-gicv3-its 1
arm-smmuv3 1
bochs-display 1
gpex-pcihost 1
gpio-key 1
neoverse-n2-arm-cpu 4
pl011 3
pl031 1
pl061 1
sbsa-gwdt 1
sysbus-ahci 1
sysbus-xhci 1
== smdkc210
arm_gic 1
exynos4210-ehci-usb 1
exynos4210.clk 1
exynos4210.fimd 1
exynos4210.i2c 9
exynos4210.mct 1
exynos4210.pmu 1
exynos4210.pwm 1
exynos4210.rng 1
exynos4210.rtc 1
exynos4210.uart 4
l2x0 1
pl330 3
s3c-sdhci 4
sd-card 4
== stm32vldiscovery
unimplemented-device 30
== supermicro-x11spi-bmc
aspeed.i2c.slave 14
ds1338 1
smbus-eeprom 1
tmp423 1
unimplemented-device 1
== supermicrox11-bmc
aspeed.i2c.slave 14
ds1338 1
smbus-eeprom 1
tmp423 1
unimplemented-device 1
== sx1
omap-gpio 1
omap-intc 2
omap-mmc 1
omap_i2c 1
serial-mm 3
ti925t-arm-cpu 1
== sx1-v1
omap-gpio 1
omap-intc 2
omap-mmc 1
omap_i2c 1
serial-mm 3
ti925t-arm-cpu 1
== tiogapass-bmc
aspeed.i2c.slave 14
at24c-eeprom 2
tmp421 3
== versatileab
arm926-arm-cpu 1
ds1338 1
pl011 4
pl031 1
pl041 1
pl050_keyboard 1
pl050_mouse 1
pl061 4
pl080 1
pl110_versatile 1
pl181 2
pl190 1
realview_sysctl 1
sp804 2
versatile_i2c 1
versatile_pci 1
versatile_pci_host 1
versatilepb_sic 1
== versatilepb
arm926-arm-cpu 1
ds1338 1
pl011 4
pl031 1
pl041 1
pl050_keyboard 1
pl050_mouse 1
pl061 4
pl080 1
pl110_versatile 1
pl181 2
pl190 1
realview_sysctl 1
sp804 2
versatile_i2c 1
versatile_pci 1
versatile_pci_host 1
versatilepb_sic 1
== vexpress-a15
a15mpcore_priv 1
cortex-a15-arm-cpu 1
pl041 1
realview_sysctl 1
== vexpress-a9
a9mpcore_priv 1
cortex-a9-arm-cpu 1
l2x0 1
pl041 1
pl111 1
realview_sysctl 1
sp804 1
== virt-10.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-10.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-10.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-11.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-11.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-5.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-6.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-6.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-6.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-7.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-7.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-7.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-8.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-8.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-8.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-9.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-9.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-9.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== witherspoon-bmc
aspeed.i2c.slave 14
dps310 1
ds1338 1
max31785 1
pca9552 2
smbus-eeprom 1
tmp105 1
tmp423 2
unimplemented-device 1
== xilinx-zynq-a9
a9mpcore_priv 1
cadence_gem 2
cadence_ttc 2
cadence_uart 2
cfi.pflash02 1
cortex-a9-arm-cpu 1
generic-sdhci 2
l2x0 1
n25q128 12
pl330 1
sd-card 2
unimplemented-device 30
usb-chipidea 2
xilinx-zynq_slcr 1
xlnx-zynq-xadc 1
xlnx.ps7-dev-cfg 1
xlnx.ps7-qspi 1
xlnx.ps7-spi 2
zynq.ddr-ctlr 1
== xlnx-zcu102
== yosemitev2-bmc
aspeed.i2c.slave 14
at24c-eeprom 2
tmp421 3
unimplemented-device 1
= ../qemu/bld/qemu-system-alpha
== clipper
cmd646-ide 1
ev67-alpha-cpu 1
i82374 1
i82378 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
mc146818rtc 1
smc37c669-superio 1
typhoon-pcihost 1
== none
= ../qemu/bld/qemu-system-arm
== anacapa-bmc
aspeed.i2c.slave 16
at24c-eeprom 10
pca9546 3
pca9548 4
pca9552 6
== ast1030-evb
aspeed.i2c.slave 14
smbus-eeprom 1
tmp105 1
== ast1040-evb
aspeed.i2c.slave 14
smbus-eeprom 1
tmp105 1
== ast1060-evb
aspeed.i2c.slave 14
== ast2500-evb
aspeed.i2c.slave 14
smbus-eeprom 1
tmp105 1
unimplemented-device 1
== ast2600-evb
aspeed.i2c.slave 16
smbus-eeprom 1
tmp105 1
unimplemented-device 1
== b-l475e-iot01a
unimplemented-device 44
== bletchley-bmc
aspeed.i2c.slave 16
at24c-eeprom 2
ds1338 1
pca9552 14
tmp421 10
== bpim2u
axp221_pmu 1
sd-card 4
serial-mm 8
unimplemented-device 76
== canon-a1100
cfi.pflash02 1
digic 1
== catalina-bmc
aspeed.i2c.slave 16
at24c-eeprom 17
ds1338 1
pca9535 2
pca9546 6
pca9548 2
pca9552 12
pca9554 1
tmp105 3
tmp421 2
== collie
cfi.pflash01 2
pxa25x-timer 1
sa1110-arm-cpu 1
scoop 1
strongarm-gpio 1
strongarm-ppc 1
strongarm-rtc 1
strongarm-ssp 1
strongarm-uart 3
strongarm_pic 1
== cubieboard
axp209_pmu 1
sd-card 1
serial-mm 1
unimplemented-device 1
== emcraft-sf2
s25sl12801 1
unimplemented-device 10
== fby35-bmc
adm1272 1
aspeed.i2c.slave 16
at24c-eeprom 5
tmp105 3
tmp421 1
== fuji-bmc
aspeed.i2c.slave 16
at24c-eeprom 24
pca9548 15
tmp105 39
tmp422 1
== g220a-bmc
aspeed.i2c.slave 14
emc1413 3
smbus-eeprom 1
== gb200nvl-bmc
aspeed.i2c.slave 16
at24c-eeprom 3
pca9546 6
pca9554 3
unimplemented-device 1
== imx25-pdk
sd-card 2
== integratorcp
arm926-arm-cpu 1
icp-ctrl-regs 1
integrator_core 1
integrator_debug 1
integrator_pic 2
integrator_pit 1
pl011 2
pl031 1
pl041 1
pl050_keyboard 1
pl050_mouse 1
pl181 1
== kudo-bmc
at24c-eeprom 2
l2x0 1
mx66u51235f 2
pca9548 4
sd-card 1
serial-mm 4
tmp105 8
unimplemented-device 33
== kzm
== lm3s6965evb
pl022 1
pl061_luminary 7
sd-card-spi 1
ssi-sd 1
stellaris-adc 1
stellaris-i2c 2
unimplemented-device 6
== lm3s811evb
pl022 1
pl061_luminary 5
ssd0303 1
stellaris-adc 1
stellaris-i2c 1
unimplemented-device 6
== max78000fthr
unimplemented-device 43
== mcimx6ul-evk
sd-card 2
unimplemented-device 28
== mcimx7d-sabre
sd-card 3
unimplemented-device 25
== microbit
unimplemented-device 2
== mori-bmc
l2x0 1
mx66u51235f 1
serial-mm 4
unimplemented-device 33
== mps2-an385
cmsdk-apb-uart 5
lan9118 1
or-irq 3
pl022 5
unimplemented-device 16
versatile_i2c 4
== mps2-an386
cmsdk-apb-uart 5
lan9118 1
or-irq 3
pl022 5
unimplemented-device 16
versatile_i2c 4
== mps2-an500
cmsdk-apb-uart 5
lan9118 1
or-irq 3
pl022 5
unimplemented-device 16
versatile_i2c 4
== mps2-an505
lan9118 1
unimplemented-device 1
== mps2-an511
cmsdk-apb-uart 5
lan9118 1
or-irq 8
pl022 5
unimplemented-device 16
versatile_i2c 4
== mps2-an521
lan9118 1
unimplemented-device 1
== mps3-an524
lan9118 1
unimplemented-device 1
== mps3-an536
cortex-r52-arm-cpu 1
lan9118 1
unimplemented-device 8
== mps3-an547
lan9118 1
unimplemented-device 3
== musca-a
== musca-b1
== musicpal
arm926-arm-cpu 1
gpio_i2c 1
musicpal-misc 1
musicpal_gpio 1
musicpal_key 1
musicpal_lcd 1
mv88w8618_eth 1
mv88w8618_flashcfg 1
mv88w8618_pic 1
mv88w8618_pit 1
mv88w8618_wlan 1
or-irq 1
serial-mm 2
wm8750 1
== netduino2
== netduinoplus2
unimplemented-device 42
== none
== npcm750-evb
l2x0 1
serial-mm 4
tmp105 4
unimplemented-device 33
w25q256 1
== nuri
arm_gic 1
exynos4210-ehci-usb 1
exynos4210.clk 1
exynos4210.fimd 1
exynos4210.i2c 9
exynos4210.mct 1
exynos4210.pmu 1
exynos4210.pwm 1
exynos4210.rng 1
exynos4210.rtc 1
exynos4210.uart 4
l2x0 1
pl330 3
s3c-sdhci 4
sd-card 4
== olimex-stm32-h405
unimplemented-device 42
== orangepi-pc
aw-h3-ehci-usb 4
sd-card 1
serial-mm 4
sysbus-ohci 4
unimplemented-device 57
== palmetto-bmc
aspeed.i2c.slave 14
ds1338 1
smbus-eeprom 1
tmp423 1
unimplemented-device 1
== quanta-gbs-bmc
l2x0 1
mx66u51235f 1
sd-card 1
serial-mm 4
unimplemented-device 33
== quanta-gsj
at24c-eeprom 2
l2x0 1
mx25l25635e 1
pca9548 1
serial-mm 4
tmp105 4
unimplemented-device 33
== quanta-q71l-bmc
aspeed.i2c.slave 14
pca9546 2
pca9548 1
tmp105 3
unimplemented-device 1
== rainier-bmc
aspeed.i2c.slave 16
at24c-eeprom 21
dps310 1
max31785 1
pca9546 4
pca9552 16
tmp105 13
tmp423 4
unimplemented-device 1
== raspi0
sd-card 1
== raspi1ap
sd-card 1
== raspi2b
sd-card 1
== realview-eb
arm926-arm-cpu 1
pl041 1
realview_gic 1
realview_sysctl 1
== realview-eb-mpcore
arm11mpcore-arm-cpu 1
l2x0 1
pl041 1
realview_mpcore 1
realview_sysctl 1
== realview-pb-a8
cortex-a8-arm-cpu 1
pl041 1
realview_gic 1
realview_sysctl 1
== realview-pbx-a9
a9mpcore_priv 1
cortex-a9-arm-cpu 1
l2x0 1
pl041 1
realview_sysctl 1
== romulus-bmc
aspeed.i2c.slave 14
ds1338 1
unimplemented-device 1
== sabrelite
l2x0 1
sst25vf016b 1
unimplemented-device 1
== smdkc210
arm_gic 1
exynos4210-ehci-usb 1
exynos4210.clk 1
exynos4210.fimd 1
exynos4210.i2c 9
exynos4210.mct 1
exynos4210.pmu 1
exynos4210.pwm 1
exynos4210.rng 1
exynos4210.rtc 1
exynos4210.uart 4
l2x0 1
pl330 3
s3c-sdhci 4
sd-card 4
== stm32vldiscovery
unimplemented-device 30
== supermicro-x11spi-bmc
aspeed.i2c.slave 14
ds1338 1
smbus-eeprom 1
tmp423 1
unimplemented-device 1
== supermicrox11-bmc
aspeed.i2c.slave 14
ds1338 1
smbus-eeprom 1
tmp423 1
unimplemented-device 1
== sx1
omap-gpio 1
omap-intc 2
omap-mmc 1
omap_i2c 1
serial-mm 3
ti925t-arm-cpu 1
== sx1-v1
omap-gpio 1
omap-intc 2
omap-mmc 1
omap_i2c 1
serial-mm 3
ti925t-arm-cpu 1
== tiogapass-bmc
aspeed.i2c.slave 14
at24c-eeprom 2
tmp421 3
== versatileab
arm926-arm-cpu 1
ds1338 1
pl011 4
pl031 1
pl041 1
pl050_keyboard 1
pl050_mouse 1
pl061 4
pl080 1
pl110_versatile 1
pl181 2
pl190 1
realview_sysctl 1
sp804 2
versatile_i2c 1
versatile_pci 1
versatile_pci_host 1
versatilepb_sic 1
== versatilepb
arm926-arm-cpu 1
ds1338 1
pl011 4
pl031 1
pl041 1
pl050_keyboard 1
pl050_mouse 1
pl061 4
pl080 1
pl110_versatile 1
pl181 2
pl190 1
realview_sysctl 1
sp804 2
versatile_i2c 1
versatile_pci 1
versatile_pci_host 1
versatilepb_sic 1
== vexpress-a15
a15mpcore_priv 1
cortex-a15-arm-cpu 1
pl041 1
realview_sysctl 1
== vexpress-a9
a9mpcore_priv 1
cortex-a9-arm-cpu 1
l2x0 1
pl041 1
pl111 1
realview_sysctl 1
sp804 1
== virt-10.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-10.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-10.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-11.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-11.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-5.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-6.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-6.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-6.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-7.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-7.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-7.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-8.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-8.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-8.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-9.0
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-9.1
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== virt-9.2
arm-gicv2m 1
arm_gic 1
cortex-a15-arm-cpu 1
gpex-pcihost 1
gpio-key 1
pl011 1
pl031 1
pl061 1
platform-bus-device 1
virtio-mmio 32
== witherspoon-bmc
aspeed.i2c.slave 14
dps310 1
ds1338 1
max31785 1
pca9552 2
smbus-eeprom 1
tmp105 1
tmp423 2
unimplemented-device 1
== xilinx-zynq-a9
a9mpcore_priv 1
cadence_gem 2
cadence_ttc 2
cadence_uart 2
cfi.pflash02 1
cortex-a9-arm-cpu 1
generic-sdhci 2
l2x0 1
n25q128 12
pl330 1
sd-card 2
unimplemented-device 30
usb-chipidea 2
xilinx-zynq_slcr 1
xlnx-zynq-xadc 1
xlnx.ps7-dev-cfg 1
xlnx.ps7-qspi 1
xlnx.ps7-spi 2
zynq.ddr-ctlr 1
== yosemitev2-bmc
aspeed.i2c.slave 14
at24c-eeprom 2
tmp421 3
unimplemented-device 1
= ../qemu/bld/qemu-system-avr
== arduino-duemilanove
unimplemented-device 16
== arduino-mega-2560-v3
unimplemented-device 24
== arduino-mega
unimplemented-device 24
== arduino-uno
unimplemented-device 16
== none
= ../qemu/bld/qemu-system-hexagon
== V66G_1024
v66-hexagon-cpu 4
== none
== virt
pl011 1
v68-hexagon-cpu 8
= ../qemu/bld/qemu-system-hppa
== 715
isa-i8259 2
isabus-bridge 1
lasi-chip 1
lasips2 1
pa-7300lc-hppa-cpu 1
serial-mm 1
== A400
astro-chip 1
diva-gsp 1
elroy-pcihost 4
pa-8500-hppa-cpu 1
== B160L
dino-pcihost 1
isa-i8259 2
isabus-bridge 1
lasi-chip 1
lasips2 1
pa-7300lc-hppa-cpu 1
serial-mm 2
== C3700
astro-chip 1
diva-gsp 1
elroy-pcihost 4
pa-8700-hppa-cpu 1
== none
= ../qemu/bld/qemu-system-i386
== microvm
acpi-ged 1
ioapic 1
isa-i8259 2
isa-pit 1
isabus-bridge 1
kvmvapic 1
mc146818rtc 1
qemu32-i386-cpu 1
virtio-mmio 24
== xenfv-4.2
== pc-i440fx-9.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-9.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-9.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-8.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-8.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-8.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-7.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-7.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-7.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-6.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-6.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-6.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-5.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-11.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-11.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-10.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-10.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-10.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-9.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-9.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-9.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-8.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-8.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-8.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-7.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-7.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-7.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-6.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-6.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-6.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-5.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-11.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-11.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-10.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-10.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-10.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu32-i386-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== isapc
486-i386-cpu 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-ide 2
isa-pcspk 1
isa-pit 1
isabus-bridge 1
mc146818rtc 1
port92 1
vmmouse 1
vmport 1
== none
== x-remote
== xenpv
== xenpvh
= ../qemu/bld/qemu-system-loongarch64
== none
== virt-11.1
acpi-ged 1
gpex-pcihost 1
la464-loongarch-cpu 1
loongarch.extioi 1
loongarch_ipi 1
loongarch_pch_msi 1
loongarch_pic 1
ls7a_rtc 1
platform-bus-device 1
serial-mm 4
unimplemented-device 1
= ../qemu/bld/qemu-system-m68k
== an5206
m5206-m68k-cpu 1
mcf-uart 2
mcf5206-mbar 1
== mcf5208evb
m5208-m68k-cpu 1
mcf-intc 1
mcf-uart 3
== next-cube
empty_slot 3
m68040-m68k-cpu 1
next-fb 1
next-kbd 1
next-pc 1
== none
== q800
adb-keyboard 1
adb-mouse 1
== virt-10.0
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-10.1
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-10.2
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-11.0
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-11.1
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-6.0
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-6.1
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-6.2
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-7.0
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-7.1
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-7.2
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-8.0
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-8.1
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-8.2
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-9.0
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-9.1
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
== virt-9.2
goldfish_pic 6
goldfish_rtc 2
goldfish_tty 1
m68040-m68k-cpu 1
m68k-irq-controller 1
virt-ctrl 1
virtio-mmio 128
= ../qemu/bld/qemu-system-microblaze
== none
== petalogix-ml605
cfi.pflash01 1
microblaze-cpu 1
n25q128 4
serial-mm 1
xlnx.xps-intc 1
xlnx.xps-spi 1
xlnx.xps-timer 1
== petalogix-s3adsp1800
cfi.pflash01 1
microblaze-cpu 1
unimplemented-device 1
xlnx.xps-ethernetlite 1
xlnx.xps-intc 1
xlnx.xps-timer 1
xlnx.xps-uartlite 1
== xlnx-zynqmp-pmu
= ../qemu/bld/qemu-system-mips
== malta
24Kf-mips-cpu 1
cfi.pflash01 1
empty_slot 1
fdc37m81x-superio 1
gt64120 1
gt64120_pci 1
isa-i8259 2
isa-pit 1
mips-malta 1
piix4-isa 1
serial-mm 1
smbus-eeprom 8
== none
= ../qemu/bld/qemu-system-mips64
== magnum
R4000-mips64-cpu 1
ds1225y 1
i8042-mmio 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
isabus-bridge 1
jazz-led 1
mc146818rtc 1
rc4030 1
serial-mm 2
sysbus-esp 1
sysbus-fdc 1
sysbus-g364 1
== malta
20Kc-mips64-cpu 1
cfi.pflash01 1
empty_slot 1
fdc37m81x-superio 1
gt64120 1
gt64120_pci 1
isa-i8259 2
isa-pit 1
mips-malta 1
piix4-isa 1
serial-mm 1
smbus-eeprom 8
== none
== pica61
R4000-mips64-cpu 1
ds1225y 1
i8042-mmio 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
isabus-bridge 1
jazz-led 1
mc146818rtc 1
rc4030 1
serial-mm 2
sysbus-esp 1
sysbus-fdc 1
vga-mmio 1
= ../qemu/bld/qemu-system-mips64el
== boston
I6400-mips64-cpu 1
ich9-ahci 1
mips-boston 1
serial-mm 1
xilinx-pcie-host 3
== fuloong2e
Bonito 1
Bonito-pcihost 1
Loongson-2E-mips64-cpu 1
isa-i8259 2
isa-pit 1
unimplemented-device 7
vt82c686b-isa 1
== loongson3-virt
Loongson-3A1000-mips64-cpu 1
goldfish_rtc 1
loongson.liointc 1
loongson_ipi 1
serial-mm 1
unimplemented-device 2
== magnum
R4000-mips64-cpu 1
ds1225y 1
i8042-mmio 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
isabus-bridge 1
jazz-led 1
mc146818rtc 1
rc4030 1
serial-mm 2
sysbus-esp 1
sysbus-fdc 1
sysbus-g364 1
== malta
20Kc-mips64-cpu 1
cfi.pflash01 1
empty_slot 1
fdc37m81x-superio 1
gt64120 1
gt64120_pci 1
isa-i8259 2
isa-pit 1
mips-malta 1
piix4-isa 1
serial-mm 1
smbus-eeprom 8
== none
== pica61
R4000-mips64-cpu 1
ds1225y 1
i8042-mmio 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
isabus-bridge 1
jazz-led 1
mc146818rtc 1
rc4030 1
serial-mm 2
sysbus-esp 1
sysbus-fdc 1
vga-mmio 1
= ../qemu/bld/qemu-system-mipsel
== malta
24Kf-mips-cpu 1
cfi.pflash01 1
empty_slot 1
fdc37m81x-superio 1
gt64120 1
gt64120_pci 1
isa-i8259 2
isa-pit 1
mips-malta 1
piix4-isa 1
serial-mm 1
smbus-eeprom 8
== none
= ../qemu/bld/qemu-system-or1k
== none
== or1k-sim
or1200-or1k-cpu 1
serial-mm 4
== virt
goldfish_rtc 1
gpex-pcihost 1
or1200-or1k-cpu 1
riscv.sifive.test 1
serial-mm 1
virtio-mmio 8
= ../qemu/bld/qemu-system-ppc
== 40p
604-powerpc-cpu 1
i82374 1
i82378 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
mc146818rtc 1
or-irq 1
prep-systemio 1
raven 1
rs6000-mc 1
== amigaone
7457_v1.2-powerpc-cpu 1
a1-nvram 1
articia 1
articia-pci-bridge 1
articia-pci-host 1
isa-i8259 2
isa-pit 1
smbus-eeprom 1
vt82c686b-isa 1
== bamboo
440epb-powerpc-cpu 1
ppc-uic 1
ppc4xx-host-bridge 1
ppc4xx-pci-host 1
ppc4xx-sdram-ddr 1
== g3beige
750_v3.1-powerpc-cpu 1
adb-keyboard 1
adb-mouse 1
grackle 1
grackle-pcihost 1
macio-oldworld 1
== mac99
7400_v2.9-powerpc-cpu 1
adb-keyboard 1
adb-mouse 1
macio-newworld 1
macio-nvram 1
uni-north 1
uni-north-agp 1
uni-north-agp-pcihost 1
uni-north-internal-pci 1
uni-north-internal-pci-pcihost 1
uni-north-pci 1
uni-north-pci-pcihost 1
== mpc8544ds
ds1338 1
e500-host-bridge 1
e500-spin 1
e500v2_v30-powerpc-cpu 1
mpc-i2c 1
mpc8544-guts 1
platform-bus-device 1
== none
== pegasos1
750cxe_v3.1b-powerpc-cpu 1
articia 1
articia-pci-bridge 1
articia-pci-host 1
isa-i8259 2
isa-pit 1
vt8231-isa 1
== pegasos2
7457_v1.2-powerpc-cpu 1
isa-i8259 2
isa-pit 1
mv64361 1
mv64361-pcibridge 2
vt8231-isa 1
== ppce500
ds1338 1
e500-host-bridge 1
e500-spin 1
e500v2_v30-powerpc-cpu 1
fsl-esdhc-be 1
mpc-i2c 1
mpc8544-guts 1
mpc8xxx_gpio 1
platform-bus-device 1
unimplemented-device 1
== ppe42_machine
== sam460ex
460exb-powerpc-cpu 1
cfi.pflash01 1
i2c-ddc 1
m41t80 1
ppc-uic 4
ppc440-pcix-host 1
ppc460ex-pcie-host 2
ppc4xx-ebc 1
ppc4xx-ehci-usb 1
ppc4xx-i2c 2
ppc4xx-mal 1
ppc4xx-plb 1
ppc4xx-sdram-ddr2 1
sm501 1
smbus-eeprom 1
sysbus-ohci 1
usb-kbd 1
usb-mouse 1
== virtex-ml507
440-xilinx-powerpc-cpu 1
cfi.pflash01 1
ppc-uic 1
serial-mm 1
xlnx.xps-intc 1
xlnx.xps-timer 1
= ../qemu/bld/qemu-system-ppc64
== 40p
604-powerpc64-cpu 1
i82374 1
i82378 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
mc146818rtc 1
or-irq 1
prep-systemio 1
raven 1
rs6000-mc 1
== amigaone
7457_v1.2-powerpc64-cpu 1
a1-nvram 1
articia 1
articia-pci-bridge 1
articia-pci-host 1
isa-i8259 2
isa-pit 1
smbus-eeprom 1
vt82c686b-isa 1
== bamboo
440epb-powerpc64-cpu 1
ppc-uic 1
ppc4xx-host-bridge 1
ppc4xx-pci-host 1
ppc4xx-sdram-ddr 1
== g3beige
750_v3.1-powerpc64-cpu 1
adb-keyboard 1
adb-mouse 1
grackle 1
grackle-pcihost 1
macio-oldworld 1
== mac99
970fx_v3.1-powerpc64-cpu 1
adb-keyboard 1
adb-mouse 1
macio-newworld 1
macio-nvram 1
u3-agp 1
u3-agp-pcihost 1
uni-north 1
== mpc8544ds
ds1338 1
e500-host-bridge 1
e500-spin 1
e500v2_v30-powerpc64-cpu 1
mpc-i2c 1
mpc8544-guts 1
platform-bus-device 1
== none
== pegasos1
750cxe_v3.1b-powerpc64-cpu 1
articia 1
articia-pci-bridge 1
articia-pci-host 1
isa-i8259 2
isa-pit 1
vt8231-isa 1
== pegasos2
7457_v1.2-powerpc64-cpu 1
isa-i8259 2
isa-pit 1
mv64361 1
mv64361-pcibridge 2
vt8231-isa 1
== powernv10
isabus-bridge 1
mc146818rtc 1
pnv-pnor 1
== powernv10-rainier
isabus-bridge 1
mc146818rtc 1
pca9552 1
pca9554 1
pnv-pnor 1
== powernv11
isabus-bridge 1
mc146818rtc 1
pnv-pnor 1
== powernv8
isabus-bridge 1
mc146818rtc 1
pnv-pnor 1
== powernv9
isabus-bridge 1
mc146818rtc 1
pnv-pnor 1
== ppce500
ds1338 1
e500-host-bridge 1
e500-spin 1
e500v2_v30-powerpc64-cpu 1
fsl-esdhc-be 1
mpc-i2c 1
mpc8544-guts 1
mpc8xxx_gpio 1
platform-bus-device 1
unimplemented-device 1
== ppe42_machine
== pseries-10.0
power10_v2.0-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-10.1
power10_v2.0-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-10.2
power10_v2.0-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-11.0
power10_v2.0-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-11.1
power11_v2.0-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-5.2
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-6.0
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-6.1
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-6.2
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-7.0
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-7.1
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-7.2
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-8.0
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-8.1
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-8.2
power9_v2.2-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-9.0
power10_v2.0-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-9.1
power10_v2.0-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== pseries-9.2
power10_v2.0-spapr-cpu-core 1
spapr-nvram 1
spapr-pci-host-bridge 1
spapr-vio-bridge 1
spapr-xive 1
== sam460ex
460exb-powerpc64-cpu 1
cfi.pflash01 1
i2c-ddc 1
m41t80 1
ppc-uic 4
ppc440-pcix-host 1
ppc460ex-pcie-host 2
ppc4xx-ebc 1
ppc4xx-ehci-usb 1
ppc4xx-i2c 2
ppc4xx-mal 1
ppc4xx-plb 1
ppc4xx-sdram-ddr2 1
sm501 1
smbus-eeprom 1
sysbus-ohci 1
usb-kbd 1
usb-mouse 1
== virtex-ml507
440-xilinx-powerpc64-cpu 1
cfi.pflash01 1
ppc-uic 1
serial-mm 1
xlnx.xps-intc 1
xlnx.xps-timer 1
= ../qemu/bld/qemu-system-riscv32
== amd-microblaze-v-generic
rv32-riscv-cpu 1
serial-mm 1
unimplemented-device 5
xlnx.xps-ethernetlite 1
xlnx.xps-intc 1
xlnx.xps-timer 2
xlnx.xps-uartlite 1
== none
== opentitan
unimplemented-device 26
== sifive_e
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.e.prci 1
riscv.sifive.plic 1
riscv.sifive.uart 2
unimplemented-device 6
== sifive_u
is25wp256 1
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.plic 1
riscv.sifive.uart 2
sd-card-spi 1
ssi-sd 1
unimplemented-device 3
== spike
riscv.aclint.mtimer 1
riscv.aclint.swi 1
== virt
goldfish_rtc 1
gpex-pcihost 1
platform-bus-device 1
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.plic 1
riscv.sifive.test 1
serial-mm 1
virtio-mmio 8
= ../qemu/bld/qemu-system-riscv64
== amd-microblaze-v-generic
rv64-riscv-cpu 1
serial-mm 1
unimplemented-device 5
xlnx.xps-ethernetlite 1
xlnx.xps-intc 1
xlnx.xps-timer 2
xlnx.xps-uartlite 1
== boston-aia
ich9-ahci 1
mips-boston-aia 1
mips-p8700-riscv-cpu 1
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.aplic 2
serial-mm 1
xilinx-pcie-host 1
== k230
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.plic 1
serial-mm 5
unimplemented-device 57
== microchip-icicle-kit
mchp.pfsoc.uart 5
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.plic 1
unimplemented-device 27
== none
== shakti_c
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.plic 1
== sifive_e
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.e.prci 1
riscv.sifive.plic 1
riscv.sifive.uart 2
unimplemented-device 6
== sifive_u
is25wp256 1
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.plic 1
riscv.sifive.uart 2
sd-card-spi 1
ssi-sd 1
unimplemented-device 3
== spike
riscv.aclint.mtimer 1
riscv.aclint.swi 1
== tt-atlantis
ds1338 1
riscv.aclint.mtimer 1
riscv.aplic 2
riscv.imsic 16
serial-mm 1
tmp105 1
unimplemented-device 1
== virt
goldfish_rtc 1
gpex-pcihost 1
platform-bus-device 1
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.sifive.plic 1
riscv.sifive.test 1
serial-mm 1
virtio-mmio 8
== xiangshan-kunminghu
riscv.aclint.mtimer 1
riscv.aclint.swi 1
riscv.aplic 2
riscv.imsic 2
serial-mm 1
= ../qemu/bld/qemu-system-rx
== gdbsim-r5f562n7
== gdbsim-r5f562n8
== none
= ../qemu/bld/qemu-system-s390x
== none
== s390-ccw-virtio-10.0
qemu-s390x-cpu 1
== s390-ccw-virtio-10.1
qemu-s390x-cpu 1
== s390-ccw-virtio-10.2
qemu-s390x-cpu 1
== s390-ccw-virtio-11.0
qemu-s390x-cpu 1
== s390-ccw-virtio-11.1
qemu-s390x-cpu 1
== s390-ccw-virtio-5.2
qemu-s390x-cpu 1
== s390-ccw-virtio-6.0
qemu-s390x-cpu 1
== s390-ccw-virtio-6.1
qemu-s390x-cpu 1
== s390-ccw-virtio-6.2
qemu-s390x-cpu 1
== s390-ccw-virtio-7.0
qemu-s390x-cpu 1
== s390-ccw-virtio-7.1
qemu-s390x-cpu 1
== s390-ccw-virtio-7.2
qemu-s390x-cpu 1
== s390-ccw-virtio-8.0
qemu-s390x-cpu 1
== s390-ccw-virtio-8.1
qemu-s390x-cpu 1
== s390-ccw-virtio-8.2
qemu-s390x-cpu 1
== s390-ccw-virtio-9.0
qemu-s390x-cpu 1
== s390-ccw-virtio-9.1
qemu-s390x-cpu 1
== s390-ccw-virtio-9.2
qemu-s390x-cpu 1
= ../qemu/bld/qemu-system-sh4
== none
== r2d
cfi.pflash02 1
i2c-ddc 1
mmio-ide 1
sh-serial 2
sh7751r-superh-cpu 1
sh_pci 1
sh_pci_host 1
sysbus-sm501 1
usb-kbd 1
= ../qemu/bld/qemu-system-sh4eb
== none
== r2d
cfi.pflash02 1
i2c-ddc 1
mmio-ide 1
sh-serial 2
sh7751r-superh-cpu 1
sh_pci 1
sh_pci_host 1
sysbus-sm501 1
usb-kbd 1
= ../qemu/bld/qemu-system-sparc
== LX
TI-MicroSparc-I-sparc-cpu 1
empty_slot 2
escc 2
macio_idreg 1
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun-fdtwo 1
sun4m-iommu 1
sysbus-m48t08 1
== SPARCClassic
TI-MicroSparc-I-sparc-cpu 1
apc 1
empty_slot 1
escc 2
macio_idreg 1
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun-fdtwo 1
sun4m-iommu 1
sysbus-m48t08 1
== SPARCbook
TI-MicroSparc-I-sparc-cpu 1
apc 1
empty_slot 1
escc 2
macio_idreg 1
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun-fdtwo 1
sun4m-iommu 1
sysbus-m48t08 1
== SS-10
TI-SuperSparc-II-sparc-cpu 1
apc 1
eccmemctl 1
escc 2
macio_idreg 1
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun-fdtwo 1
sun4m-iommu 1
sysbus-m48t08 1
== SS-20
TI-SuperSparc-II-sparc-cpu 1
apc 1
eccmemctl 1
empty_slot 4
escc 2
macio_idreg 1
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun-fdtwo 1
sun4m-iommu 1
sysbus-m48t08 1
unimplemented-device 4
== SS-4
Fujitsu-MB86904-sparc-cpu 1
apc 1
empty_slot 1
escc 2
macio_idreg 1
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun-CS4231 1
sun-fdtwo 1
sun4m-iommu 1
sysbus-m48t08 1
== SS-5
Fujitsu-MB86904-sparc-cpu 1
apc 1
empty_slot 2
escc 2
macio_idreg 1
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun-CS4231 1
sun-fdtwo 1
sun4m-iommu 1
sysbus-m48t08 1
tcx_afx 1
== SS-600MP
TI-SuperSparc-II-sparc-cpu 1
apc 1
eccmemctl 1
escc 2
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun4m-iommu 1
sysbus-m48t08 1
== Voyager
Fujitsu-MB86904-sparc-cpu 1
apc 1
empty_slot 1
escc 2
macio_idreg 1
memory 1
openprom 1
or-irq 2
slavio_intctl 1
slavio_misc 1
slavio_timer 1
sparc32-dma 1
sun-fdtwo 1
sun4m-iommu 1
sysbus-m48t08 1
== leon3_generic
LEON3-sparc-cpu 1
grlib-ahbpnp 1
grlib-apbpnp 1
grlib-irqmp 1
== none
= ../qemu/bld/qemu-system-sparc64
== niagara
Sun-UltraSparc-T1-sparc64-cpu 1
== none
== sun4u
TI-UltraSparc-IIi-sparc64-cpu 1
cmd646-ide 1
ebus 1
i8042 1
isa-fdc 1
memory 1
openprom 1
pbm-bridge 2
power 1
sabre 1
sabre-pci 1
sun4u-iommu 1
sysbus-m48t59 1
== sun4v
Sun-UltraSparc-T1-sparc64-cpu 1
cmd646-ide 1
ebus 1
i8042 1
isa-fdc 1
memory 1
openprom 1
pbm-bridge 2
power 1
sabre 1
sabre-pci 1
sun4u-iommu 1
sysbus-m48t59 1
= ../qemu/bld/qemu-system-tricore
== KIT_AURIX_TC277_TRB
== none
== tricore_testboard
tc1796-tricore-cpu 1
= ../qemu/bld/qemu-system-x86_64
== microvm
acpi-ged 1
ioapic 1
isa-i8259 2
isa-pit 1
isabus-bridge 1
kvmvapic 1
mc146818rtc 1
qemu64-x86_64-cpu 1
virtio-mmio 24
== xenfv-4.2
== pc-i440fx-9.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-9.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-9.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-8.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-8.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-8.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-7.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-7.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-7.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-6.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-6.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-6.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-5.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-11.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-11.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-10.2
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-10.1
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-i440fx-10.0
PIIX3 1
hpet 1
i440FX 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-9.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-9.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-9.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-8.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-8.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-8.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-7.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-7.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-7.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-6.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-6.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-6.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-5.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-11.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-11.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-10.2
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-10.1
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== pc-q35-10.0
ICH9-LPC 1
ICH9-SMB 1
hpet 1
i8042 1
ich9-ahci 1
isa-i8259 2
isa-pcspk 1
isa-pit 1
kvmvapic 1
port92 1
qemu64-x86_64-cpu 1
smbus-eeprom 8
vmmouse 1
vmport 1
== isapc
486-x86_64-cpu 1
i8042 1
isa-fdc 1
isa-i8259 2
isa-ide 2
isa-pcspk 1
isa-pit 1
isabus-bridge 1
mc146818rtc 1
port92 1
vmmouse 1
vmport 1
== nitro
== none
== x-remote
== xenpv
== xenpvh
= ../qemu/bld/qemu-system-xtensa
== kc705
dc232b-xtensa-cpu 1
serial-mm 1
== kc705-nommu
de212-xtensa-cpu 1
serial-mm 1
== lx200
dc232b-xtensa-cpu 1
serial-mm 1
== lx200-nommu
de212-xtensa-cpu 1
serial-mm 1
== lx60
dc232b-xtensa-cpu 1
serial-mm 1
== lx60-nommu
de212-xtensa-cpu 1
serial-mm 1
== ml605
dc232b-xtensa-cpu 1
serial-mm 1
== ml605-nommu
de212-xtensa-cpu 1
serial-mm 1
== none
== sim
dc232b-xtensa-cpu 1
== virt
dc232b-xtensa-cpu 1
gpex-pcihost 1
= ../qemu/bld/qemu-system-xtensaeb
== kc705
fsf-xtensa-cpu 1
serial-mm 1
== kc705-nommu
fsf-xtensa-cpu 1
serial-mm 1
== lx200
fsf-xtensa-cpu 1
serial-mm 1
== lx200-nommu
fsf-xtensa-cpu 1
serial-mm 1
== lx60
fsf-xtensa-cpu 1
serial-mm 1
== lx60-nommu
fsf-xtensa-cpu 1
serial-mm 1
== ml605
fsf-xtensa-cpu 1
serial-mm 1
== ml605-nommu
fsf-xtensa-cpu 1
serial-mm 1
== none
== sim
fsf-xtensa-cpu 1
== virt
fsf-xtensa-cpu 1
gpex-pcihost 1
[*] Subject: A few Machines crash when "no default audio driver available"
Date: Thu, 09 Jul 2026 13:44:19 +0200
Message-ID: <87o6gge6b0.fsf@pond.sub.org>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Call to clean up QOM onboard devices lacking a parent
2026-07-09 14:59 Call to clean up QOM onboard devices lacking a parent Markus Armbruster
@ 2026-07-09 16:02 ` BALATON Zoltan
2026-07-09 16:45 ` Graf (AWS), Alexander
2026-07-10 7:05 ` Markus Armbruster
0 siblings, 2 replies; 9+ messages in thread
From: BALATON Zoltan @ 2026-07-09 16:02 UTC (permalink / raw)
To: Markus Armbruster
Cc: qemu-devel, Aditya Gupta, Alexander Graf, Alexandre Iooss,
Alexey Kardashevskiy, Alistair Francis, Alistair Francis,
Antony Pavlov, Artyom Tarasenko, Bernhard Beschow, Bibo Mao,
Brian Cain, Chao Liu, Christian Borntraeger, Clément Chigot,
Cédric Le Goater, Dorjoy Chowdhury, Edgar E. Iglesias,
Eric Farman, Farhan Ali, Felipe Balbi, Francisco Iglesias,
Frederic Konrad, Gaurav Sharma, Gautam Gala, Glenn Miles,
Halil Pasic, Hao Wu, Harsh Prateek Bora, Helge Deller,
Hendrik Brueckner, Hervé Poussineau, Huacai Chen, Jan Kiszka,
Jared Rossi, Joel Stanley, Laurent Vivier, Manos Pitsidianakis,
Mark Cave-Ayland, Matthew Rosato, Max Filippov, Michael Rolnik,
Michael S. Tsirkin, Nicholas Piggin, Niek Linnenbank,
Palmer Dabbelt, Paolo Bonzini, Peter Maydell,
Philippe Mathieu-Daudé, Pierrick Bouvier, Ran Wang,
Richard Henderson, Sai Pavan Boddu, Samuel Tardieu, Sergio Lopez,
Song Gao, Stafford Horne, Subbaraya Sundeep, Thomas Huth,
Tyrone Ting, qemu-arm, qemu-ppc, qemu-riscv, qemu-s390x
On Thu, 9 Jul 2026, Markus Armbruster wrote:
> A QOM object must be the child of exactly one parent. This defines the
> QOM composition tree. The link from parent to child is a property of
> the parent, and therefore has a name that is unique within its parent.
> An object's canonical QOM path is these names on the path from root to
> object in the QOM composition tree separated by '/'.
>
> For devices:
>
> * If a device is plugged in with -device / device_add, and it has an ID,
> we make it a child of /machine/peripheral/ with name ID. If it
> doesn't have an ID, we make it a child of /machine/peripheral-anon/
> with name device[N], where N counts up from zero. The canonical QOM
> path /machine/peripheral/ID is stable. The canonical QOM path
> /machine/peripheral-anon/device[N] isn't: it depends on the number of
> devices already there.
>
> * If a device is part of another device, it should be its child. The
> child's canonical QOM path is the parent's plus '/CHILD-NAME'. Stable
> as long as the parent's path and the child name are.
>
> * "Should" because we have a lot of code that fails to pick the parent.
> When such a device gets realized, we make it a child of
> /machine/unattached/ orphanage with name device[N], where N counts up
> from zero. The canonical QOM path /machine/unattached/device[N]
> depends on the number of children already in the orphanage, which
> makes it unstable.
>
> Letting code get away with not picking a parent was a mistake. I
> guess it "saved" us some thinking about what's part of what when
> converting existing devices to QOM. In other words, it enabled sloppy
> hardware modeling. We've been "saving" thinking ever since.
>
> I want /machine/unattached/ to be empty. If an onboard device isn't
> part of another device, put it into /machine/ with a sensible name.
The last time this came up I've asked a few questions but did not get an
answer:
1. What's the use of the QOM composition tree? I never needed it and apart
from being able to admire it in info qom-tree I don't know if it's used
for anything. For a long time I did not even know about info qom-tree
because I only needed info qtree and info mtree and rarely if ever need to
look at the qom-tree. If it has no real use I'm happy to not think about
it.
2. What is a QOM parent? There were proposals to parent devices to their
bus if they have any, that's what qtree shows anyway. If it's something
else it should be better defined somewhere.
Without getting answers for these questions I don't think I'm able to fix
the machines I maintain.
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Call to clean up QOM onboard devices lacking a parent
2026-07-09 16:02 ` BALATON Zoltan
@ 2026-07-09 16:45 ` Graf (AWS), Alexander
2026-07-10 6:25 ` Markus Armbruster
2026-07-10 7:05 ` Markus Armbruster
1 sibling, 1 reply; 9+ messages in thread
From: Graf (AWS), Alexander @ 2026-07-09 16:45 UTC (permalink / raw)
To: BALATON Zoltan, Markus Armbruster
Cc: qemu-devel@nongnu.org, Aditya Gupta, Alexandre Iooss,
Alexey Kardashevskiy, Alistair Francis, Alistair Francis,
Antony Pavlov, Artyom Tarasenko, Bernhard Beschow, Bibo Mao,
Brian Cain, Chao Liu, Christian Borntraeger, Clément Chigot,
Cédric Le Goater, Dorjoy Chowdhury, Edgar E. Iglesias,
Eric Farman, Farhan Ali, Felipe Balbi, Francisco Iglesias,
Frederic Konrad, Gaurav Sharma, Gautam Gala, Glenn Miles,
Halil Pasic, Hao Wu, Harsh Prateek Bora, Helge Deller,
Hendrik Brueckner, Hervé Poussineau, Huacai Chen, Jan Kiszka,
Jared Rossi, Joel Stanley, Laurent Vivier, Manos Pitsidianakis,
Mark Cave-Ayland, Matthew Rosato, Max Filippov, Michael Rolnik,
Michael S. Tsirkin, Nicholas Piggin, Niek Linnenbank,
Palmer Dabbelt, Paolo Bonzini, Peter Maydell,
Philippe Mathieu-Daudé, Pierrick Bouvier, Ran Wang,
Richard Henderson, Sai Pavan Boddu, Samuel Tardieu, Sergio Lopez,
Song Gao, Stafford Horne, Subbaraya Sundeep, Thomas Huth,
Tyrone Ting, qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
qemu-riscv@nongnu.org, qemu-s390x@nongnu.org
Hi Markus,
On 09.07.26 18:02, BALATON Zoltan wrote:
>
> On Thu, 9 Jul 2026, Markus Armbruster wrote:
>> A QOM object must be the child of exactly one parent. This defines the
>> QOM composition tree. The link from parent to child is a property of
>> the parent, and therefore has a name that is unique within its parent.
>> An object's canonical QOM path is these names on the path from root to
>> object in the QOM composition tree separated by '/'.
>>
>> For devices:
>>
>> * If a device is plugged in with -device / device_add, and it has an ID,
>> we make it a child of /machine/peripheral/ with name ID. If it
>> doesn't have an ID, we make it a child of /machine/peripheral-anon/
>> with name device[N], where N counts up from zero. The canonical QOM
>> path /machine/peripheral/ID is stable. The canonical QOM path
>> /machine/peripheral-anon/device[N] isn't: it depends on the number of
>> devices already there.
>>
>> * If a device is part of another device, it should be its child. The
>> child's canonical QOM path is the parent's plus '/CHILD-NAME'. Stable
>> as long as the parent's path and the child name are.
>>
>> * "Should" because we have a lot of code that fails to pick the parent.
>> When such a device gets realized, we make it a child of
>> /machine/unattached/ orphanage with name device[N], where N counts up
>> from zero. The canonical QOM path /machine/unattached/device[N]
>> depends on the number of children already in the orphanage, which
>> makes it unstable.
>>
>> Letting code get away with not picking a parent was a mistake. I
>> guess it "saved" us some thinking about what's part of what when
>> converting existing devices to QOM. In other words, it enabled sloppy
>> hardware modeling. We've been "saving" thinking ever since.
>>
>> I want /machine/unattached/ to be empty. If an onboard device isn't
>> part of another device, put it into /machine/ with a sensible name.
>
> The last time this came up I've asked a few questions but did not get an
> answer:
>
> 1. What's the use of the QOM composition tree? I never needed it and
> apart
> from being able to admire it in info qom-tree I don't know if it's used
> for anything. For a long time I did not even know about info qom-tree
> because I only needed info qtree and info mtree and rarely if ever
> need to
> look at the qom-tree. If it has no real use I'm happy to not think about
> it.
>
> 2. What is a QOM parent? There were proposals to parent devices to their
> bus if they have any, that's what qtree shows anyway. If it's something
> else it should be better defined somewhere.
>
> Without getting answers for these questions I don't think I'm able to fix
> the machines I maintain.
I'm also curious on whether there is anything that makes sysbus device
spawns both easy (as they are today) and at the same time fully QOM
parent compliant.
I had a quick look at the vmapple machine and most of the offenders are
sysbus devices I spawn via qdev_new(). Would you want all of these to
get their parent declared via object_property_add_child()? If that's the
case, why don't we introduce a new qdev_new_child() which does that
automatically?
Alex
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Call to clean up QOM onboard devices lacking a parent
2026-07-09 16:45 ` Graf (AWS), Alexander
@ 2026-07-10 6:25 ` Markus Armbruster
2026-07-10 7:38 ` Graf (AWS), Alexander
0 siblings, 1 reply; 9+ messages in thread
From: Markus Armbruster @ 2026-07-10 6:25 UTC (permalink / raw)
To: Graf (AWS), Alexander
Cc: BALATON Zoltan, Markus Armbruster, qemu-devel@nongnu.org,
Aditya Gupta, Alexandre Iooss, Alexey Kardashevskiy,
Alistair Francis, Alistair Francis, Antony Pavlov,
Artyom Tarasenko, Bernhard Beschow, Bibo Mao, Brian Cain,
Chao Liu, Christian Borntraeger, Clément Chigot,
Cédric Le Goater, Dorjoy Chowdhury, Edgar E. Iglesias,
Eric Farman, Farhan Ali, Felipe Balbi, Francisco Iglesias,
Frederic Konrad, Gaurav Sharma, Gautam Gala, Glenn Miles,
Halil Pasic, Hao Wu, Harsh Prateek Bora, Helge Deller,
Hendrik Brueckner, Hervé Poussineau, Huacai Chen, Jan Kiszka,
Jared Rossi, Joel Stanley, Laurent Vivier, Manos Pitsidianakis,
Mark Cave-Ayland, Matthew Rosato, Max Filippov, Michael Rolnik,
Michael S. Tsirkin, Nicholas Piggin, Niek Linnenbank,
Palmer Dabbelt, Paolo Bonzini, Peter Maydell,
Philippe Mathieu-Daudé, Pierrick Bouvier, Ran Wang,
Richard Henderson, Sai Pavan Boddu, Samuel Tardieu, Sergio Lopez,
Song Gao, Stafford Horne, Subbaraya Sundeep, Thomas Huth,
Tyrone Ting, qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
qemu-riscv@nongnu.org, qemu-s390x@nongnu.org
"Graf (AWS), Alexander" <graf@amazon.de> writes:
> Hi Markus,
[...]
> I'm also curious on whether there is anything that makes sysbus device
> spawns both easy (as they are today) and at the same time fully QOM
> parent compliant.
>
> I had a quick look at the vmapple machine and most of the offenders are
> sysbus devices I spawn via qdev_new(). Would you want all of these to
> get their parent declared via object_property_add_child()? If that's the
> case, why don't we introduce a new qdev_new_child() which does that
> automatically?
We do have such convenience functions at the QOM layer: object_new() and
object_property_add_child() etc., are basic building blocks, and
object_new_with_props() etc. combine them in useful ways.
We don't have such convenience functions at the qdev layer. Can't see
why we couldn't add them.
Number of orphaned device types I see by bus_type:
69 busless
15 ISA
33 PCI
11 SSI
209 System
2 apple-desktop-bus
23 i2c-bus
2 sd-bus
1 spapr-vio-bus
2 usb-bus
Again, not a problem with the device types, but the code that creates
and realizes them.
Bus types commonly provide a layer above qdev for that. Perhaps these
layers could also use convenience functions to more easily deal with
setting the QOM parent.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Call to clean up QOM onboard devices lacking a parent
2026-07-09 16:02 ` BALATON Zoltan
2026-07-09 16:45 ` Graf (AWS), Alexander
@ 2026-07-10 7:05 ` Markus Armbruster
2026-07-10 12:13 ` BALATON Zoltan
1 sibling, 1 reply; 9+ messages in thread
From: Markus Armbruster @ 2026-07-10 7:05 UTC (permalink / raw)
To: BALATON Zoltan
Cc: qemu-devel, Aditya Gupta, Alexander Graf, Alexandre Iooss,
Alexey Kardashevskiy, Alistair Francis, Alistair Francis,
Antony Pavlov, Artyom Tarasenko, Bernhard Beschow, Bibo Mao,
Brian Cain, Chao Liu, Christian Borntraeger, Clément Chigot,
Cédric Le Goater, Dorjoy Chowdhury, Edgar E. Iglesias,
Eric Farman, Farhan Ali, Felipe Balbi, Francisco Iglesias,
Frederic Konrad, Gaurav Sharma, Gautam Gala, Glenn Miles,
Halil Pasic, Hao Wu, Harsh Prateek Bora, Helge Deller,
Hendrik Brueckner, Hervé Poussineau, Huacai Chen, Jan Kiszka,
Jared Rossi, Joel Stanley, Laurent Vivier, Manos Pitsidianakis,
Mark Cave-Ayland, Matthew Rosato, Max Filippov, Michael Rolnik,
Michael S. Tsirkin, Nicholas Piggin, Niek Linnenbank,
Palmer Dabbelt, Paolo Bonzini, Peter Maydell,
Philippe Mathieu-Daudé, Pierrick Bouvier, Ran Wang,
Richard Henderson, Sai Pavan Boddu, Samuel Tardieu, Sergio Lopez,
Song Gao, Stafford Horne, Subbaraya Sundeep, Thomas Huth,
Tyrone Ting, qemu-arm, qemu-ppc, qemu-riscv, qemu-s390x
BALATON Zoltan <balaton@eik.bme.hu> writes:
> On Thu, 9 Jul 2026, Markus Armbruster wrote:
>> A QOM object must be the child of exactly one parent. This defines the
>> QOM composition tree. The link from parent to child is a property of
>> the parent, and therefore has a name that is unique within its parent.
>> An object's canonical QOM path is these names on the path from root to
>> object in the QOM composition tree separated by '/'.
>>
>> For devices:
>>
>> * If a device is plugged in with -device / device_add, and it has an ID,
>> we make it a child of /machine/peripheral/ with name ID. If it
>> doesn't have an ID, we make it a child of /machine/peripheral-anon/
>> with name device[N], where N counts up from zero. The canonical QOM
>> path /machine/peripheral/ID is stable. The canonical QOM path
>> /machine/peripheral-anon/device[N] isn't: it depends on the number of
>> devices already there.
>>
>> * If a device is part of another device, it should be its child. The
>> child's canonical QOM path is the parent's plus '/CHILD-NAME'. Stable
>> as long as the parent's path and the child name are.
>>
>> * "Should" because we have a lot of code that fails to pick the parent.
>> When such a device gets realized, we make it a child of
>> /machine/unattached/ orphanage with name device[N], where N counts up
>> from zero. The canonical QOM path /machine/unattached/device[N]
>> depends on the number of children already in the orphanage, which
>> makes it unstable.
>>
>> Letting code get away with not picking a parent was a mistake. I
>> guess it "saved" us some thinking about what's part of what when
>> converting existing devices to QOM. In other words, it enabled sloppy
>> hardware modeling. We've been "saving" thinking ever since.
>>
>> I want /machine/unattached/ to be empty. If an onboard device isn't
>> part of another device, put it into /machine/ with a sensible name.
>
> The last time this came up I've asked a few questions but did not get an answer:
>
> 1. What's the use of the QOM composition tree? I never needed it and apart from being able to admire it in info qom-tree I don't know if it's used for anything. For a long time I did not even know about info qom-tree because I only needed info qtree and info mtree and rarely if ever need to look at the qom-tree. If it has no real use I'm happy to not think about it.
>
> 2. What is a QOM parent? There were proposals to parent devices to their bus if they have any, that's what qtree shows anyway. If it's something else it should be better defined somewhere.
>
> Without getting answers for these questions I don't think I'm able to fix the machines I maintain.
Unfortunately, I don't have the time to teach a class on QOM basics
today. The text you quoted explains what QOM parent and canonical QOM
path are, albeit briefly. It also explains how to pick the QOM parent
properly, what happens when you neglect to pick one, and why that's
undesirable. I'm going to elaborate a bit.
A fully constructed QOM object is part of the QOM composition tree.
This is a fundamental property of QOM's design.
A QOM object can be composed of sub-objects. Its sub-objects are its
children in the composition tree. That's why it's named *composition*
tree.
Canonical QOM paths are visible at external interfaces both as input and
as output. A few quick examples:
* QMP command query-cpus-fast reports a CPU's canonical QOM path. For
some machines, we get something like "/machine/unattached/device[0]".
Fine as long as the client treats it as an opaque handle. For other
machines, we get something like "/machine/soc/cpu", which is clearly
better.
* Error messages use canonical QOM paths to identify devices. With
properly modeled hardware, these paths are actually helpful for
humans. Something like "/machine/unattached/device[7]" not so much.
* QMP command device-sync-config accepts a QOM path argument. With
properly modeled hardware, you can use a stable canonical QOM path.
But when the device is in the /machine/unattached orphanage, its
canonical QOM path is unstable. A client has to first search the
orphanage to find today's path.
Further questions?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Call to clean up QOM onboard devices lacking a parent
2026-07-10 6:25 ` Markus Armbruster
@ 2026-07-10 7:38 ` Graf (AWS), Alexander
2026-07-10 8:03 ` Markus Armbruster
0 siblings, 1 reply; 9+ messages in thread
From: Graf (AWS), Alexander @ 2026-07-10 7:38 UTC (permalink / raw)
To: Markus Armbruster
Cc: BALATON Zoltan, qemu-devel@nongnu.org, Aditya Gupta,
Alexandre Iooss, Alexey Kardashevskiy, Alistair Francis,
Alistair Francis, Antony Pavlov, Artyom Tarasenko,
Bernhard Beschow, Bibo Mao, Brian Cain, Chao Liu,
Christian Borntraeger, Clément Chigot, Cédric Le Goater,
Dorjoy Chowdhury, Edgar E. Iglesias, Eric Farman, Farhan Ali,
Felipe Balbi, Francisco Iglesias, Frederic Konrad, Gaurav Sharma,
Gautam Gala, Glenn Miles, Halil Pasic, Hao Wu, Harsh Prateek Bora,
Helge Deller, Hendrik Brueckner, Hervé Poussineau,
Huacai Chen, Jan Kiszka, Jared Rossi, Joel Stanley,
Laurent Vivier, Manos Pitsidianakis, Mark Cave-Ayland,
Matthew Rosato, Max Filippov, Michael Rolnik, Michael S. Tsirkin,
Nicholas Piggin, Niek Linnenbank, Palmer Dabbelt, Paolo Bonzini,
Peter Maydell, Philippe Mathieu-Daudé, Pierrick Bouvier,
Ran Wang, Richard Henderson, Sai Pavan Boddu, Samuel Tardieu,
Sergio Lopez, Song Gao, Stafford Horne, Subbaraya Sundeep,
Thomas Huth, Tyrone Ting, qemu-arm@nongnu.org,
qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org
On 10.07.26 08:25, Markus Armbruster wrote:
> "Graf (AWS), Alexander" <graf@amazon.de> writes:
>
>> Hi Markus,
> [...]
>
>> I'm also curious on whether there is anything that makes sysbus device
>> spawns both easy (as they are today) and at the same time fully QOM
>> parent compliant.
>>
>> I had a quick look at the vmapple machine and most of the offenders are
>> sysbus devices I spawn via qdev_new(). Would you want all of these to
>> get their parent declared via object_property_add_child()? If that's the
>> case, why don't we introduce a new qdev_new_child() which does that
>> automatically?
> We do have such convenience functions at the QOM layer: object_new() and
> object_property_add_child() etc., are basic building blocks, and
> object_new_with_props() etc. combine them in useful ways.
>
> We don't have such convenience functions at the qdev layer. Can't see
> why we couldn't add them.
>
> Number of orphaned device types I see by bus_type:
>
> 69 busless
> 15 ISA
> 33 PCI
> 11 SSI
> 209 System
> 2 apple-desktop-bus
> 23 i2c-bus
> 2 sd-bus
> 1 spapr-vio-bus
> 2 usb-bus
>
> Again, not a problem with the device types, but the code that creates
> and realizes them.
>
> Bus types commonly provide a layer above qdev for that. Perhaps these
> layers could also use convenience functions to more easily deal with
> setting the QOM parent.
I think the crux of the problem is that we ended up inheriting creation
APIs that didn't necessarily express a clear parent/child relationship,
so we end up orphaning these type of objects in the QOM tree. So the
*real* answer IMHO is to rebuild all these APIs into something that
enforces that. This way we also won't have new offenders sneaking in.
I won't be able to spend the weeks it requires to do this by hand, but I
can have a stab at it with AI - which is likely much more reliable at
getting this done correctly than me too :). I can post it as RFC and
then we decide whether we want to take it or leave it.
Alex
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Call to clean up QOM onboard devices lacking a parent
2026-07-10 7:38 ` Graf (AWS), Alexander
@ 2026-07-10 8:03 ` Markus Armbruster
0 siblings, 0 replies; 9+ messages in thread
From: Markus Armbruster @ 2026-07-10 8:03 UTC (permalink / raw)
To: Graf (AWS), Alexander
Cc: BALATON Zoltan, qemu-devel@nongnu.org, Aditya Gupta,
Alexandre Iooss, Alexey Kardashevskiy, Alistair Francis,
Alistair Francis, Antony Pavlov, Artyom Tarasenko,
Bernhard Beschow, Bibo Mao, Brian Cain, Chao Liu,
Christian Borntraeger, Clément Chigot, Cédric Le Goater,
Dorjoy Chowdhury, Edgar E. Iglesias, Eric Farman, Farhan Ali,
Felipe Balbi, Francisco Iglesias, Frederic Konrad, Gaurav Sharma,
Gautam Gala, Glenn Miles, Halil Pasic, Hao Wu, Harsh Prateek Bora,
Helge Deller, Hendrik Brueckner, Hervé Poussineau,
Huacai Chen, Jan Kiszka, Jared Rossi, Joel Stanley,
Laurent Vivier, Manos Pitsidianakis, Mark Cave-Ayland,
Matthew Rosato, Max Filippov, Michael Rolnik, Michael S. Tsirkin,
Nicholas Piggin, Niek Linnenbank, Palmer Dabbelt, Paolo Bonzini,
Peter Maydell, Philippe Mathieu-Daudé, Pierrick Bouvier,
Ran Wang, Richard Henderson, Sai Pavan Boddu, Samuel Tardieu,
Sergio Lopez, Song Gao, Stafford Horne, Subbaraya Sundeep,
Thomas Huth, Tyrone Ting, qemu-arm@nongnu.org,
qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org
"Graf (AWS), Alexander" <graf@amazon.de> writes:
> On 10.07.26 08:25, Markus Armbruster wrote:
>> "Graf (AWS), Alexander" <graf@amazon.de> writes:
>>
>>> Hi Markus,
>> [...]
>>
>>> I'm also curious on whether there is anything that makes sysbus device
>>> spawns both easy (as they are today) and at the same time fully QOM
>>> parent compliant.
>>>
>>> I had a quick look at the vmapple machine and most of the offenders are
>>> sysbus devices I spawn via qdev_new(). Would you want all of these to
>>> get their parent declared via object_property_add_child()? If that's the
>>> case, why don't we introduce a new qdev_new_child() which does that
>>> automatically?
>>
>> We do have such convenience functions at the QOM layer: object_new() and
>> object_property_add_child() etc., are basic building blocks, and
>> object_new_with_props() etc. combine them in useful ways.
>>
>> We don't have such convenience functions at the qdev layer. Can't see
>> why we couldn't add them.
>>
>> Number of orphaned device types I see by bus_type:
>>
>> 69 busless
>> 15 ISA
>> 33 PCI
>> 11 SSI
>> 209 System
>> 2 apple-desktop-bus
>> 23 i2c-bus
>> 2 sd-bus
>> 1 spapr-vio-bus
>> 2 usb-bus
>>
>> Again, not a problem with the device types, but the code that creates
>> and realizes them.
>>
>> Bus types commonly provide a layer above qdev for that. Perhaps these
>> layers could also use convenience functions to more easily deal with
>> setting the QOM parent.
>
>
> I think the crux of the problem is that we ended up inheriting creation
> APIs that didn't necessarily express a clear parent/child relationship,
> so we end up orphaning these type of objects in the QOM tree. So the
> *real* answer IMHO is to rebuild all these APIs into something that
> enforces that. This way we also won't have new offenders sneaking in.
The appended trivial patch will keep new offenders out. Drawback: it
breaks almost everything due to existing offenders ;)
Kidding aside, the code it deletes was a mistake. We likely added it
for quicker initial conversions. The technical debt's compound interest
has been piling up ever since.
> I won't be able to spend the weeks it requires to do this by hand, but I
> can have a stab at it with AI - which is likely much more reliable at
> getting this done correctly than me too :). I can post it as RFC and
> then we decide whether we want to take it or leave it.
The part that requires actual thought is the hardware modeling: what's
part of what.
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index e2aab3d1fc..058f89fa55 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -493,15 +493,6 @@ static void device_set_realized(Object *obj, bool value, Error **errp)
goto fail;
}
- if (!obj->parent) {
- gchar *name = g_strdup_printf("device[%d]", unattached_count++);
-
- object_property_add_child(machine_get_container("unattached"),
- name, obj);
- unattached_parent = true;
- g_free(name);
- }
-
hotplug_ctrl = qdev_get_hotplug_handler(dev);
if (hotplug_ctrl) {
hotplug_handler_pre_plug(hotplug_ctrl, dev, &local_err);
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Call to clean up QOM onboard devices lacking a parent
2026-07-10 7:05 ` Markus Armbruster
@ 2026-07-10 12:13 ` BALATON Zoltan
2026-07-13 6:43 ` Markus Armbruster
0 siblings, 1 reply; 9+ messages in thread
From: BALATON Zoltan @ 2026-07-10 12:13 UTC (permalink / raw)
To: Markus Armbruster
Cc: qemu-devel, Aditya Gupta, Alexander Graf, Alexandre Iooss,
Alexey Kardashevskiy, Alistair Francis, Alistair Francis,
Antony Pavlov, Artyom Tarasenko, Bernhard Beschow, Bibo Mao,
Brian Cain, Chao Liu, Christian Borntraeger, Clément Chigot,
Cédric Le Goater, Dorjoy Chowdhury, Edgar E. Iglesias,
Eric Farman, Farhan Ali, Felipe Balbi, Francisco Iglesias,
Frederic Konrad, Gaurav Sharma, Gautam Gala, Glenn Miles,
Halil Pasic, Hao Wu, Harsh Prateek Bora, Helge Deller,
Hendrik Brueckner, Hervé Poussineau, Huacai Chen, Jan Kiszka,
Jared Rossi, Joel Stanley, Laurent Vivier, Manos Pitsidianakis,
Mark Cave-Ayland, Matthew Rosato, Max Filippov, Michael Rolnik,
Michael S. Tsirkin, Nicholas Piggin, Niek Linnenbank,
Palmer Dabbelt, Paolo Bonzini, Peter Maydell,
Philippe Mathieu-Daudé, Pierrick Bouvier, Ran Wang,
Richard Henderson, Sai Pavan Boddu, Samuel Tardieu, Sergio Lopez,
Song Gao, Stafford Horne, Subbaraya Sundeep, Thomas Huth,
Tyrone Ting, qemu-arm, qemu-ppc, qemu-riscv, qemu-s390x
On Fri, 10 Jul 2026, Markus Armbruster wrote:
> BALATON Zoltan <balaton@eik.bme.hu> writes:
>
>> On Thu, 9 Jul 2026, Markus Armbruster wrote:
>>> A QOM object must be the child of exactly one parent. This defines the
>>> QOM composition tree. The link from parent to child is a property of
>>> the parent, and therefore has a name that is unique within its parent.
>>> An object's canonical QOM path is these names on the path from root to
>>> object in the QOM composition tree separated by '/'.
>>>
>>> For devices:
>>>
>>> * If a device is plugged in with -device / device_add, and it has an ID,
>>> we make it a child of /machine/peripheral/ with name ID. If it
>>> doesn't have an ID, we make it a child of /machine/peripheral-anon/
>>> with name device[N], where N counts up from zero. The canonical QOM
>>> path /machine/peripheral/ID is stable. The canonical QOM path
>>> /machine/peripheral-anon/device[N] isn't: it depends on the number of
>>> devices already there.
>>>
>>> * If a device is part of another device, it should be its child. The
>>> child's canonical QOM path is the parent's plus '/CHILD-NAME'. Stable
>>> as long as the parent's path and the child name are.
>>>
>>> * "Should" because we have a lot of code that fails to pick the parent.
>>> When such a device gets realized, we make it a child of
>>> /machine/unattached/ orphanage with name device[N], where N counts up
>>> from zero. The canonical QOM path /machine/unattached/device[N]
>>> depends on the number of children already in the orphanage, which
>>> makes it unstable.
>>>
>>> Letting code get away with not picking a parent was a mistake. I
>>> guess it "saved" us some thinking about what's part of what when
>>> converting existing devices to QOM. In other words, it enabled sloppy
>>> hardware modeling. We've been "saving" thinking ever since.
>>>
>>> I want /machine/unattached/ to be empty. If an onboard device isn't
>>> part of another device, put it into /machine/ with a sensible name.
>>
>> The last time this came up I've asked a few questions but did not get an answer:
>>
>> 1. What's the use of the QOM composition tree? I never needed it and apart from being able to admire it in info qom-tree I don't know if it's used for anything. For a long time I did not even know about info qom-tree because I only needed info qtree and info mtree and rarely if ever need to look at the qom-tree. If it has no real use I'm happy to not think about it.
>>
>> 2. What is a QOM parent? There were proposals to parent devices to their bus if they have any, that's what qtree shows anyway. If it's something else it should be better defined somewhere.
>>
>> Without getting answers for these questions I don't think I'm able to fix the machines I maintain.
>
> Unfortunately, I don't have the time to teach a class on QOM basics
> today. The text you quoted explains what QOM parent and canonical QOM
> path are, albeit briefly. It also explains how to pick the QOM parent
> properly, what happens when you neglect to pick one, and why that's
> undesirable. I'm going to elaborate a bit.
I read that text but understood it describes what is done now and missed
the part where it says how to pick a parent.
> A fully constructed QOM object is part of the QOM composition tree.
> This is a fundamental property of QOM's design.
>
> A QOM object can be composed of sub-objects. Its sub-objects are its
> children in the composition tree. That's why it's named *composition*
> tree.
OK so this is clear for a SoC or a multifunction device where we mostly do
that now, for example hw/isa/vt82c686.c has object_initialize_child for
its parts (which is the only reason we need an init method and could do
without it otherwise). For PPC460EX we don't model the SoC as this is old
code that was cleaned up a bit but never completed to convert everything
so the machine still creates the SoC parts and wires them as a lot of
older machines did. I intended to improve the PCIe emulation on sam460ex
and clean up that part during that but haven't got to it yet. I guess
other devices like isa have the same problem that they predate even QOM so
was not fully converted yet.
What should own sysbus devices? The machine? Or is it the bus which owns
the devices connected to it? Another problem is that machines usually use
convenience functions to create devices such as sysbus_create_simple and
pci_create_simple so if these devices need to be attached to the machine
then these convenience functions should take care of that not the board
code. It's rare that a device does object_new or object_initialize to get
a device and it would be inconvenient to then cast the result to object
and parent it somewhere where the functions that created the device could
do this.
> Canonical QOM paths are visible at external interfaces both as input and
> as output. A few quick examples:
>
> * QMP command query-cpus-fast reports a CPU's canonical QOM path. For
> some machines, we get something like "/machine/unattached/device[0]".
> Fine as long as the client treats it as an opaque handle. For other
> machines, we get something like "/machine/soc/cpu", which is clearly
> better.
As you say does not matter what is it called if it's just a handle.
> * Error messages use canonical QOM paths to identify devices. With
> properly modeled hardware, these paths are actually helpful for
> humans. Something like "/machine/unattached/device[7]" not so much.
Never seen such error message. Usually errors also say what device it is
from so usually straightforward to know where it comes from.
> * QMP command device-sync-config accepts a QOM path argument. With
> properly modeled hardware, you can use a stable canonical QOM path.
> But when the device is in the /machine/unattached orphanage, its
> canonical QOM path is unstable. A client has to first search the
> orphanage to find today's path.
Never needed to use device-sync-config. It's not even documented at
https://www.qemu.org/docs/master/system/monitor.html#qemu-monitor so I
have no idea what this command does. Found some info here:
https://www.qemu.org/docs/master/devel/qdev-api.html but I don't know
about any device implementing that so it's probably a rare thing.
> Further questions?
Basically the question was why should I think about this if things work
now and nobody complained about it so it looked like it just bothers you
that there are some unparented objects that could be put in some other
category, but it's not a real issue for any common problem other than
esthetics. I'm OK with solving that within QOM or qdev or somewhere where
I don't have to think about it when writing board code. Imposing it on the
board code looks like additional complexity and yet another thing to
confuse new people trying to create a machine so unless there's a good
reason to require that I'd do without it.
Where are stable QOM paths needed? If you can't predict them and still
need to query it first then it likely does not matter what is the path as
it's just used to query and refer to a device as a handle so in that case
we may just forget the path hierarchy and make it flat and that would also
solve your issue with unparented devices.
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Call to clean up QOM onboard devices lacking a parent
2026-07-10 12:13 ` BALATON Zoltan
@ 2026-07-13 6:43 ` Markus Armbruster
0 siblings, 0 replies; 9+ messages in thread
From: Markus Armbruster @ 2026-07-13 6:43 UTC (permalink / raw)
To: BALATON Zoltan
Cc: qemu-devel, Aditya Gupta, Alexander Graf, Alexandre Iooss,
Alexey Kardashevskiy, Alistair Francis, Alistair Francis,
Antony Pavlov, Artyom Tarasenko, Bernhard Beschow, Bibo Mao,
Brian Cain, Chao Liu, Christian Borntraeger, Clément Chigot,
Cédric Le Goater, Dorjoy Chowdhury, Edgar E. Iglesias,
Eric Farman, Farhan Ali, Felipe Balbi, Francisco Iglesias,
Frederic Konrad, Gaurav Sharma, Gautam Gala, Glenn Miles,
Halil Pasic, Hao Wu, Harsh Prateek Bora, Helge Deller,
Hendrik Brueckner, Hervé Poussineau, Huacai Chen, Jan Kiszka,
Jared Rossi, Joel Stanley, Laurent Vivier, Manos Pitsidianakis,
Mark Cave-Ayland, Matthew Rosato, Max Filippov, Michael Rolnik,
Michael S. Tsirkin, Nicholas Piggin, Niek Linnenbank,
Palmer Dabbelt, Paolo Bonzini, Peter Maydell,
Philippe Mathieu-Daudé, Pierrick Bouvier, Ran Wang,
Richard Henderson, Sai Pavan Boddu, Samuel Tardieu, Sergio Lopez,
Song Gao, Stafford Horne, Subbaraya Sundeep, Thomas Huth,
Tyrone Ting, qemu-arm, qemu-ppc, qemu-riscv, qemu-s390x
BALATON Zoltan <balaton@eik.bme.hu> writes:
> On Fri, 10 Jul 2026, Markus Armbruster wrote:
>> BALATON Zoltan <balaton@eik.bme.hu> writes:
>>
>>> On Thu, 9 Jul 2026, Markus Armbruster wrote:
>>>> A QOM object must be the child of exactly one parent. This defines the
>>>> QOM composition tree. The link from parent to child is a property of
>>>> the parent, and therefore has a name that is unique within its parent.
>>>> An object's canonical QOM path is these names on the path from root to
>>>> object in the QOM composition tree separated by '/'.
>>>>
>>>> For devices:
>>>>
>>>> * If a device is plugged in with -device / device_add, and it has an ID,
>>>> we make it a child of /machine/peripheral/ with name ID. If it
>>>> doesn't have an ID, we make it a child of /machine/peripheral-anon/
>>>> with name device[N], where N counts up from zero. The canonical QOM
>>>> path /machine/peripheral/ID is stable. The canonical QOM path
>>>> /machine/peripheral-anon/device[N] isn't: it depends on the number of
>>>> devices already there.
>>>>
>>>> * If a device is part of another device, it should be its child. The
>>>> child's canonical QOM path is the parent's plus '/CHILD-NAME'. Stable
>>>> as long as the parent's path and the child name are.
>>>>
>>>> * "Should" because we have a lot of code that fails to pick the parent.
>>>> When such a device gets realized, we make it a child of
>>>> /machine/unattached/ orphanage with name device[N], where N counts up
>>>> from zero. The canonical QOM path /machine/unattached/device[N]
>>>> depends on the number of children already in the orphanage, which
>>>> makes it unstable.
>>>>
>>>> Letting code get away with not picking a parent was a mistake. I
>>>> guess it "saved" us some thinking about what's part of what when
>>>> converting existing devices to QOM. In other words, it enabled sloppy
>>>> hardware modeling. We've been "saving" thinking ever since.
>>>>
>>>> I want /machine/unattached/ to be empty. If an onboard device isn't
>>>> part of another device, put it into /machine/ with a sensible name.
>>>
>>> The last time this came up I've asked a few questions but did not get an answer:
>>>
>>> 1. What's the use of the QOM composition tree? I never needed it and apart from being able to admire it in info qom-tree I don't know if it's used for anything. For a long time I did not even know about info qom-tree because I only needed info qtree and info mtree and rarely if ever need to look at the qom-tree. If it has no real use I'm happy to not think about it.
>>>
>>> 2. What is a QOM parent? There were proposals to parent devices to their bus if they have any, that's what qtree shows anyway. If it's something else it should be better defined somewhere.
>>>
>>> Without getting answers for these questions I don't think I'm able to fix the machines I maintain.
>>
>> Unfortunately, I don't have the time to teach a class on QOM basics
>> today. The text you quoted explains what QOM parent and canonical QOM
>> path are, albeit briefly. It also explains how to pick the QOM parent
>> properly, what happens when you neglect to pick one, and why that's
>> undesirable. I'm going to elaborate a bit.
>
> I read that text but understood it describes what is done now and missed the part where it says how to pick a parent.
>
>> A fully constructed QOM object is part of the QOM composition tree.
>> This is a fundamental property of QOM's design.
>>
>> A QOM object can be composed of sub-objects. Its sub-objects are its
>> children in the composition tree. That's why it's named *composition*
>> tree.
>
> OK so this is clear for a SoC or a multifunction device where we mostly do that now, for example hw/isa/vt82c686.c has object_initialize_child for its parts (which is the only reason we need an init method and could do without it otherwise). For PPC460EX we don't model the SoC as this is old code that was cleaned up a bit but never completed to convert everything so the machine still creates the SoC parts and wires them as a lot of older machines did. I intended to improve the PCIe emulation on sam460ex and clean up that part during that but haven't got to it yet. I guess other devices like isa have the same problem that they predate even QOM so was not fully converted yet.
Yes, many of the early conversions were superficial.
Once problematic code exists, it gets imitated. We shouldn't blame the
victims.
> What should own sysbus devices? The machine? Or is it the bus which owns the devices connected to it?
If the sysbus device is part of another device, it should be below it in
the composition tree. Whether to connect it directly or via its bus is
arguably a matter of taste. Would be nice if we could agree on a
convention there.
If it's not part of another device (say a chip soldered onto the
mainboard), then put it into /machine with a sensible name.
> Another problem is that machines usually use convenience functions to create devices such as sysbus_create_simple and pci_create_simple so if these devices need to be attached to the machine then these convenience functions should take care of that not the board code. It's rare that a device does object_new or object_initialize to get a device and it would be inconvenient to then cast the result to object and parent it somewhere where the functions that created the device could do this.
Alex Graf just posted RFC patches "qom: Make composition-tree parenting
mandatory". I haven't hat a chance to examine them, but patch titles
suggest the series takes care of that.
>> Canonical QOM paths are visible at external interfaces both as input and
>> as output. A few quick examples:
>>
>> * QMP command query-cpus-fast reports a CPU's canonical QOM path. For
>> some machines, we get something like "/machine/unattached/device[0]".
>> Fine as long as the client treats it as an opaque handle. For other
>> machines, we get something like "/machine/soc/cpu", which is clearly
>> better.
>
> As you say does not matter what is it called if it's just a handle.
True! Still, nice names help humans with debugging and such. We should
go for them whenever practical.
>> * Error messages use canonical QOM paths to identify devices. With
>> properly modeled hardware, these paths are actually helpful for
>> humans. Something like "/machine/unattached/device[7]" not so much.
>
> Never seen such error message. Usually errors also say what device it is from so usually straightforward to know where it comes from.
Such error messages definitely exist. Random pick,
hw/net/can/flexcan.c:
error_setg(errp, "%s: flexcan_connect_to_bus failed",
dev->canonical_path);
Many trace points and log entries show canonical QOM paths, too.
>> * QMP command device-sync-config accepts a QOM path argument. With
>> properly modeled hardware, you can use a stable canonical QOM path.
>> But when the device is in the /machine/unattached orphanage, its
>> canonical QOM path is unstable. A client has to first search the
>> orphanage to find today's path.
>
> Never needed to use device-sync-config. It's not even documented at https://www.qemu.org/docs/master/system/monitor.html#qemu-monitor so I have no idea what this command does. Found some info here:
> https://www.qemu.org/docs/master/devel/qdev-api.html but I don't know about any device implementing that so it's probably a rare thing.
To learn what a QMP command does, start with the "QEMU QMP Reference
Manual". All commands are documented there, or else QEMU fails to
build. Can't enforce the documentation to be *good*, though. So if you
find something that's bad, post a patch or file a bug.
If my point was "device-sync-config needs this", an argument "who cares
for device-sync-config" could perhaps be made. It is not. My point is
that canonical QOM paths are part of external interfaces *by design*.
device-sync-config is merely the first example I found for use of QOM
paths in QMP input.
>> Further questions?
>
> Basically the question was why should I think about this if things work now and nobody complained about it so it looked like it just bothers you that there are some unparented objects that could be put in some other category, but it's not a real issue for any common problem other than esthetics. I'm OK with solving that within QOM or qdev or somewhere where I don't have to think about it when writing board code. Imposing it on the board code looks like additional complexity and yet another thing to confuse new people trying to create a machine so unless there's a good reason to require that I'd do without it.
>
> Where are stable QOM paths needed?
Once again: they are part of external interfaces.
> If you can't predict them and still need to query it first then it likely does not matter what is the path as it's just used to query and refer to a device as a handle so in that case we may just forget the path hierarchy and make it flat and that would also solve your issue with unparented devices.
That's not how QOM works.
You are welcome to propose a redesign of QOM.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-07-13 6:43 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-09 14:59 Call to clean up QOM onboard devices lacking a parent Markus Armbruster
2026-07-09 16:02 ` BALATON Zoltan
2026-07-09 16:45 ` Graf (AWS), Alexander
2026-07-10 6:25 ` Markus Armbruster
2026-07-10 7:38 ` Graf (AWS), Alexander
2026-07-10 8:03 ` Markus Armbruster
2026-07-10 7:05 ` Markus Armbruster
2026-07-10 12:13 ` BALATON Zoltan
2026-07-13 6:43 ` Markus Armbruster
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.