RFC Introduce canonical device hierarchy string
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest5 patches 75 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | qdev: Create qdev_get_dev_path()hw/ hw/ hw/ | +64 | 51 replies | |
| 2/5 | savevm: Add DeviceState paramaudio/ block-migration.c exec.c +85 more | +159 | 0 replies | |
| 3/5 | savevm: Make use of the new DeviceState paramsavevm.c | +76 | 0 replies | |
| 4/5 | eepro100: Add a dev field to eeprom new/free functionshw/ hw/ hw/ | +8 | 0 replies | |
| 5/5 | virtio-net: Incorporate a DeviceState pointer and let savevm track instanceshw/ | +4 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/5] Introduce canonical device hierarchy string
This is a follow-up to my ramblock overhaul RFC series. In trying to come up with a useful name to give to a ramblock, we seemed to be leaning towards something that represents the existing qdev hierarchy rather than creating an arbitrary new namespace. I had some pointers that I should use the savevm name/instance in the interim, but that has a number of issues (private to savevm, typically setup too late, inconsistent).
So, I decided to look at what should the savevm string be, with hopes that if we could figure that out, we can then stuff the resulting string into both the savevm list and the ramblocks. This is a stab at doing that.
My premise with this attempt is that we walk the hierarchy and use the names to create the base of the path. As we get to the device, particularly to the parent bus of the device, we need to start looking at properties to ensure uniqueness. However, we don't want to use all the properties or else any properties added or removed from a device will cause migration failures. For now, the only properties I've tagged as path properties are PCI bus addresses and MAC addresses. It turns out the MAC isn't needed in most cases since they're typically PCI based, but I left it in in case someone figures out how to make multiple instances of ne2k_isa work (or non-PCI based NICs on other archs). In any case, these seem like they should be stable properties for a device.
I've compiled all the archs, but I've only actually run x86_64-system. For a well populated VM, here's what got used as id strings in the savevm_handlers list:
"timer"
"slirp"
"slirp"
"slirp"
"slirp"
"slirp"
"block"
"ram"
"cpu_common"
"cpu"
"apic"
"fw_cfg"
"i8259"
"i8259"
"ioapic"
"PCIBUS"
"/main-system-bus/pci.0,addr=00.0/i440FX/I440FX" "/main-system-bus/pci.0,addr=01.0/PIIX3/PIIX3" "/main-system-bus/pci.0,addr=02.0/cirrus-vga/cirrus_vga" "/main-system-bus/pci.0/isa.0/mc146818rtc/mc146818rtc"
"i8254"
"hpet"
"/main-system-bus/pci.0/isa.0/isa-serial/serial"
"ps2kbd"
"ps2mouse"
"/main-system-bus/pci.0/isa.0/i8042/pckbd"
"vmmouse"
"dma"
"dma"
"/main-system-bus/pci.0/isa.0/isa-fdc/fdc" "/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56/eeprom" "/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56/i82551" "/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57/virtio-net" "/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58/e1000" "/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59/rtl8139" "/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a/pcnet" "/main-system-bus/pci.0,addr=01.1/piix3-ide/ide"
"i2c_bus"
"/main-system-bus/pci.0,addr=01.3/PIIX4_PM/piix4_pm" "/main-system-bus/pci.0,addr=08.0/lsi53c895a/lsiscsi" "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci/virtio-blk"
Let me know what you think. Thanks,
Alex
---
Alex Williamson (5):
virtio-net: Incorporate a DeviceState pointer and let savevm track instances
eepro100: Add a dev field to eeprom new/free functions
savevm: Make use of the new DeviceState param
savevm: Add DeviceState param
qdev: Create qdev_get_dev_path()
audio/audio.c | 2 - block-migration.c | 2 - exec.c | 4 +- hw/adb.c | 4 +- hw/ads7846.c | 2 - hw/apic.c | 2 - hw/arm_gic.c | 2 - hw/arm_timer.c | 4 +- hw/armv7m_nvic.c | 2 - hw/cirrus_vga.c | 2 - hw/cuda.c | 2 - hw/dma.c | 4 +- hw/eepro100.c | 8 ++-- hw/eeprom93xx.c | 8 ++-- hw/eeprom93xx.h | 4 +- hw/fw_cfg.c | 2 - hw/g364fb.c | 2 - hw/grackle_pci.c | 4 +- hw/gt64xxx.c | 3 + hw/heathrow_pic.c | 2 - hw/hpet.c | 2 - hw/hw.h | 18 +++++--- hw/i2c.c | 2 - hw/i8254.c | 2 - hw/i8259.c | 2 - hw/ide/cmd646.c | 2 - hw/ide/isa.c | 2 - hw/ide/macio.c | 2 - hw/ide/microdrive.c | 2 - hw/ide/mmio.c | 2 - hw/ide/piix.c | 2 - hw/ioapic.c | 2 - hw/m48t59.c | 2 - hw/mac_dbdma.c | 2 - hw/mac_nvram.c | 2 - hw/max111x.c | 3 + hw/mipsnet.c | 4 +- hw/mst_fpga.c | 2 - hw/nand.c | 2 - hw/openpic.c | 5 +- hw/pci.c | 2 - hw/pckbd.c | 2 - hw/piix4.c | 2 - hw/pl011.c | 2 - hw/pl022.c | 2 - hw/pl061.c | 2 - hw/ppc4xx_pci.c | 4 +- hw/ppce500_pci.c | 4 +- hw/ps2.c | 4 +- hw/pxa2xx.c | 24 +++++------ hw/pxa2xx_dma.c | 2 - hw/pxa2xx_gpio.c | 2 - hw/pxa2xx_keypad.c | 2 - hw/pxa2xx_lcd.c | 2 - hw/pxa2xx_mmci.c | 2 - hw/pxa2xx_pic.c | 2 - hw/pxa2xx_timer.c | 2 - hw/qdev-properties.c | 2 + hw/qdev.c | 61 +++++++++++++++++++++++++++- hw/qdev.h | 5 ++ hw/rc4030.c | 2 - hw/serial.c | 4 +- hw/spitz.c | 9 ++-- hw/ssd0323.c | 3 + hw/ssi-sd.c | 2 - hw/stellaris.c | 11 +++-- hw/stellaris_enet.c | 4 +- hw/stellaris_input.c | 2 - hw/syborg_fb.c | 2 - hw/syborg_interrupt.c | 2 - hw/syborg_keyboard.c | 2 - hw/syborg_pointer.c | 2 - hw/syborg_rtc.c | 3 + hw/syborg_serial.c | 2 - hw/syborg_timer.c | 2 - hw/tsc2005.c | 2 - hw/tsc210x.c | 4 +- hw/unin_pci.c | 6 ++- hw/vga-isa-mm.c | 2 - hw/vga-isa.c | 2 - hw/virtio-balloon.c | 3 + hw/virtio-blk.c | 2 - hw/virtio-net.c | 7 ++- hw/virtio-serial-bus.c | 2 - hw/vmmouse.c | 2 - hw/vmware_vga.c | 2 - hw/zaurus.c | 2 - qemu-timer.c | 2 - savevm.c | 106 +++++++++++++++++++++++++++++++++++++++++------- slirp/slirp.c | 5 +- vl.c | 2 - 91 files changed, 307 insertions(+), 153 deletions(-)