* [RFC PATCH 0/5] Introduce canonical device hierarchy string
@ 2010-06-14 5:51 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, avi, anthony, paul, kraxel, chrisw, alex.williamson
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(-)
--
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string
@ 2010-06-14 5:51 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: chrisw, kvm, paul, alex.williamson, kraxel, avi
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(-)
--
^ permalink raw reply [flat|nested] 160+ messages in thread
* [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
@ 2010-06-14 5:51 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, avi, anthony, paul, kraxel, chrisw, alex.williamson
qdev_get_dev_path() is intended to be the canonical utility for creating
a string representing the qdev hierarchy of a device. The path consists
of bus and device names as well as identified properties of the immediate
parent bus and device. This results in strings like:
"/main-system-bus/pci.0,addr=00.0/i440FX"
"/main-system-bus/pci.0,addr=01.0/PIIX3"
"/main-system-bus/pci.0,addr=02.0/cirrus-vga"
"/main-system-bus/pci.0/isa.0/mc146818rtc"
"/main-system-bus/pci.0/isa.0/isa-serial"
"/main-system-bus/pci.0/isa.0/i8042"
"/main-system-bus/pci.0/isa.0/isa-fdc"
"/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56"
"/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57"
"/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58"
"/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59"
"/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a"
"/main-system-bus/pci.0,addr=01.1/piix3-ide"
"/main-system-bus/pci.0,addr=01.3/PIIX4_PM"
"/main-system-bus/pci.0,addr=08.0/lsi53c895a"
"/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
There are two primary targets for these strings. The first is vmsave, where
we currently use a device provided string plus instance number to track
SaveStateEntries. This fails when we introduce device hotplug, particularly
in a case were we have gaps in the instance numbers that cannot easily be
reproduced on a migration target. The second is for naming RAMBlocks. For
these, we would like a string that matches the vmstate string.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
hw/qdev-properties.c | 2 ++
hw/qdev.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
hw/qdev.h | 5 ++++
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 9ffdba7..e30df88 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -453,6 +453,7 @@ PropertyInfo qdev_prop_macaddr = {
.name = "macaddr",
.type = PROP_TYPE_MACADDR,
.size = sizeof(MACAddr),
+ .flags = PROP_FLAG_PATH,
.parse = parse_mac,
.print = print_mac,
};
@@ -496,6 +497,7 @@ PropertyInfo qdev_prop_pci_devfn = {
.name = "pci-devfn",
.type = PROP_TYPE_UINT32,
.size = sizeof(uint32_t),
+ .flags = PROP_FLAG_PATH,
.parse = parse_pci_devfn,
.print = print_pci_devfn,
};
diff --git a/hw/qdev.c b/hw/qdev.c
index 36f29ea..dea44fe 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -120,6 +120,63 @@ DeviceState *qdev_create(BusState *bus, const char *name)
return qdev_create_from_info(bus, info);
}
+static int qdev_strprint_parent_path(DeviceState *dev, char *buf, size_t len)
+{
+ int offset = 0;
+
+ if (dev->parent_bus && dev->parent_bus->parent)
+ offset = qdev_strprint_parent_path(dev->parent_bus->parent, buf, len);
+
+ offset += snprintf(buf + offset, len - offset,
+ "/%s", dev->parent_bus->name);
+ return offset;
+}
+
+static int qdev_strprint_path_props(DeviceState *dev, Property *props,
+ char *buf, size_t len)
+{
+ int offset = 0;
+ char pbuf[64];
+
+ if (!props)
+ return 0;
+
+ while (props->name) {
+ if (props->info->flags & PROP_FLAG_PATH) {
+ if (props->info->print) {
+ props->info->print(dev, props, pbuf, sizeof(pbuf));
+ offset += snprintf(buf + offset, len - offset, ",%s=%s",
+ props->name, pbuf);
+ }
+ }
+ props++;
+ }
+ return offset;
+}
+
+char *qdev_get_dev_path(DeviceState *dev)
+{
+ char buf[256] = "";
+ int offset;
+
+ if (!dev)
+ return NULL;
+
+ offset = qdev_strprint_parent_path(dev, buf, sizeof(buf));
+
+ offset += qdev_strprint_path_props(dev, dev->parent_bus->info->props,
+ buf + offset, sizeof(buf) - offset);
+
+ offset += snprintf(buf + offset, sizeof(buf) - offset, "/%s",
+ dev->info->name);
+ if (dev->id)
+ offset += snprintf(buf + offset, sizeof(buf) - offset, "-%s", dev->id);
+
+ offset += qdev_strprint_path_props(dev, dev->info->props,
+ buf + offset, sizeof(buf) - offset);
+ return qemu_strdup(buf);
+}
+
static void qdev_print_devinfo(DeviceInfo *info)
{
error_printf("name \"%s\", bus %s",
diff --git a/hw/qdev.h b/hw/qdev.h
index a44060e..2702384 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -96,6 +96,7 @@ struct PropertyInfo {
const char *name;
size_t size;
enum PropertyType type;
+ int flags;
int (*parse)(DeviceState *dev, Property *prop, const char *str);
int (*print)(DeviceState *dev, Property *prop, char *dest, size_t len);
};
@@ -201,6 +202,8 @@ extern PropertyInfo qdev_prop_netdev;
extern PropertyInfo qdev_prop_vlan;
extern PropertyInfo qdev_prop_pci_devfn;
+#define PROP_FLAG_PATH (1<<0)
+
#define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
.name = (_name), \
.info = &(_prop), \
@@ -280,6 +283,8 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
void qdev_prop_register_global_list(GlobalProperty *props);
void qdev_prop_set_globals(DeviceState *dev);
+char *qdev_get_dev_path(DeviceState *dev);
+
/* This is a nasty hack to allow passing a NULL bus to qdev_create. */
extern struct BusInfo system_bus_info;
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 5:51 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: chrisw, kvm, paul, alex.williamson, kraxel, avi
qdev_get_dev_path() is intended to be the canonical utility for creating
a string representing the qdev hierarchy of a device. The path consists
of bus and device names as well as identified properties of the immediate
parent bus and device. This results in strings like:
"/main-system-bus/pci.0,addr=00.0/i440FX"
"/main-system-bus/pci.0,addr=01.0/PIIX3"
"/main-system-bus/pci.0,addr=02.0/cirrus-vga"
"/main-system-bus/pci.0/isa.0/mc146818rtc"
"/main-system-bus/pci.0/isa.0/isa-serial"
"/main-system-bus/pci.0/isa.0/i8042"
"/main-system-bus/pci.0/isa.0/isa-fdc"
"/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56"
"/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57"
"/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58"
"/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59"
"/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a"
"/main-system-bus/pci.0,addr=01.1/piix3-ide"
"/main-system-bus/pci.0,addr=01.3/PIIX4_PM"
"/main-system-bus/pci.0,addr=08.0/lsi53c895a"
"/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
There are two primary targets for these strings. The first is vmsave, where
we currently use a device provided string plus instance number to track
SaveStateEntries. This fails when we introduce device hotplug, particularly
in a case were we have gaps in the instance numbers that cannot easily be
reproduced on a migration target. The second is for naming RAMBlocks. For
these, we would like a string that matches the vmstate string.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
hw/qdev-properties.c | 2 ++
hw/qdev.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
hw/qdev.h | 5 ++++
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 9ffdba7..e30df88 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -453,6 +453,7 @@ PropertyInfo qdev_prop_macaddr = {
.name = "macaddr",
.type = PROP_TYPE_MACADDR,
.size = sizeof(MACAddr),
+ .flags = PROP_FLAG_PATH,
.parse = parse_mac,
.print = print_mac,
};
@@ -496,6 +497,7 @@ PropertyInfo qdev_prop_pci_devfn = {
.name = "pci-devfn",
.type = PROP_TYPE_UINT32,
.size = sizeof(uint32_t),
+ .flags = PROP_FLAG_PATH,
.parse = parse_pci_devfn,
.print = print_pci_devfn,
};
diff --git a/hw/qdev.c b/hw/qdev.c
index 36f29ea..dea44fe 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -120,6 +120,63 @@ DeviceState *qdev_create(BusState *bus, const char *name)
return qdev_create_from_info(bus, info);
}
+static int qdev_strprint_parent_path(DeviceState *dev, char *buf, size_t len)
+{
+ int offset = 0;
+
+ if (dev->parent_bus && dev->parent_bus->parent)
+ offset = qdev_strprint_parent_path(dev->parent_bus->parent, buf, len);
+
+ offset += snprintf(buf + offset, len - offset,
+ "/%s", dev->parent_bus->name);
+ return offset;
+}
+
+static int qdev_strprint_path_props(DeviceState *dev, Property *props,
+ char *buf, size_t len)
+{
+ int offset = 0;
+ char pbuf[64];
+
+ if (!props)
+ return 0;
+
+ while (props->name) {
+ if (props->info->flags & PROP_FLAG_PATH) {
+ if (props->info->print) {
+ props->info->print(dev, props, pbuf, sizeof(pbuf));
+ offset += snprintf(buf + offset, len - offset, ",%s=%s",
+ props->name, pbuf);
+ }
+ }
+ props++;
+ }
+ return offset;
+}
+
+char *qdev_get_dev_path(DeviceState *dev)
+{
+ char buf[256] = "";
+ int offset;
+
+ if (!dev)
+ return NULL;
+
+ offset = qdev_strprint_parent_path(dev, buf, sizeof(buf));
+
+ offset += qdev_strprint_path_props(dev, dev->parent_bus->info->props,
+ buf + offset, sizeof(buf) - offset);
+
+ offset += snprintf(buf + offset, sizeof(buf) - offset, "/%s",
+ dev->info->name);
+ if (dev->id)
+ offset += snprintf(buf + offset, sizeof(buf) - offset, "-%s", dev->id);
+
+ offset += qdev_strprint_path_props(dev, dev->info->props,
+ buf + offset, sizeof(buf) - offset);
+ return qemu_strdup(buf);
+}
+
static void qdev_print_devinfo(DeviceInfo *info)
{
error_printf("name \"%s\", bus %s",
diff --git a/hw/qdev.h b/hw/qdev.h
index a44060e..2702384 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -96,6 +96,7 @@ struct PropertyInfo {
const char *name;
size_t size;
enum PropertyType type;
+ int flags;
int (*parse)(DeviceState *dev, Property *prop, const char *str);
int (*print)(DeviceState *dev, Property *prop, char *dest, size_t len);
};
@@ -201,6 +202,8 @@ extern PropertyInfo qdev_prop_netdev;
extern PropertyInfo qdev_prop_vlan;
extern PropertyInfo qdev_prop_pci_devfn;
+#define PROP_FLAG_PATH (1<<0)
+
#define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
.name = (_name), \
.info = &(_prop), \
@@ -280,6 +283,8 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
void qdev_prop_register_global_list(GlobalProperty *props);
void qdev_prop_set_globals(DeviceState *dev);
+char *qdev_get_dev_path(DeviceState *dev);
+
/* This is a nasty hack to allow passing a NULL bus to qdev_create. */
extern struct BusInfo system_bus_info;
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [RFC PATCH 2/5] savevm: Add DeviceState param
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
@ 2010-06-14 5:51 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, avi, anthony, paul, kraxel, chrisw, alex.williamson
We want to be able to extract a qdev device hierarchy path to match
savevm data between source and destination for a migration. This adds
a DeviceState param to callers and callees so we can make that happen.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
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 | 4 ++--
hw/eeprom93xx.c | 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.c | 4 ++--
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 | 4 ++--
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 | 23 ++++++++++++++---------
slirp/slirp.c | 5 +++--
vl.c | 2 +-
88 files changed, 159 insertions(+), 139 deletions(-)
diff --git a/audio/audio.c b/audio/audio.c
index dbf0b96..ad51077 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1901,7 +1901,7 @@ static void audio_init (void)
}
QLIST_INIT (&s->card_head);
- vmstate_register (0, &vmstate_audio, s);
+ vmstate_register (NULL, 0, &vmstate_audio, s);
}
void AUD_register_card (const char *name, QEMUSoundCard *card)
diff --git a/block-migration.c b/block-migration.c
index 7d04d6d..5964291 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -638,6 +638,6 @@ void blk_mig_init(void)
QSIMPLEQ_INIT(&block_mig_state.bmds_list);
QSIMPLEQ_INIT(&block_mig_state.blk_list);
- register_savevm_live("block", 0, 1, block_set_params, block_save_live,
+ register_savevm_live(NULL, "block", 0, 1, block_set_params, block_save_live,
NULL, block_load, &block_mig_state);
}
diff --git a/exec.c b/exec.c
index 7f64384..b56b827 100644
--- a/exec.c
+++ b/exec.c
@@ -641,8 +641,8 @@ void cpu_exec_init(CPUState *env)
cpu_list_unlock();
#endif
#if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY)
- vmstate_register(cpu_index, &vmstate_cpu_common, env);
- register_savevm("cpu", cpu_index, CPU_SAVE_VERSION,
+ vmstate_register(NULL, cpu_index, &vmstate_cpu_common, env);
+ register_savevm(NULL, "cpu", cpu_index, CPU_SAVE_VERSION,
cpu_save, cpu_load, env);
#endif
}
diff --git a/hw/adb.c b/hw/adb.c
index 4fb7a62..99b30f6 100644
--- a/hw/adb.c
+++ b/hw/adb.c
@@ -305,7 +305,7 @@ void adb_kbd_init(ADBBusState *bus)
d = adb_register_device(bus, ADB_KEYBOARD, adb_kbd_request,
adb_kbd_reset, s);
qemu_add_kbd_event_handler(adb_kbd_put_keycode, d);
- register_savevm("adb_kbd", -1, 1, adb_kbd_save,
+ register_savevm(NULL, "adb_kbd", -1, 1, adb_kbd_save,
adb_kbd_load, s);
}
@@ -475,6 +475,6 @@ void adb_mouse_init(ADBBusState *bus)
d = adb_register_device(bus, ADB_MOUSE, adb_mouse_request,
adb_mouse_reset, s);
qemu_add_mouse_event_handler(adb_mouse_event, d, 0, "QEMU ADB Mouse");
- register_savevm("adb_mouse", -1, 1, adb_mouse_save,
+ register_savevm(NULL, "adb_mouse", -1, 1, adb_mouse_save,
adb_mouse_load, s);
}
diff --git a/hw/ads7846.c b/hw/ads7846.c
index 184b3dd..b3bbeaf 100644
--- a/hw/ads7846.c
+++ b/hw/ads7846.c
@@ -151,7 +151,7 @@ static int ads7846_init(SSISlave *dev)
ads7846_int_update(s);
- register_savevm("ads7846", -1, 0, ads7846_save, ads7846_load, s);
+ register_savevm(NULL, "ads7846", -1, 0, ads7846_save, ads7846_load, s);
return 0;
}
diff --git a/hw/apic.c b/hw/apic.c
index 7fbd79b..5c0268d 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -1011,7 +1011,7 @@ int apic_init(CPUState *env)
}
s->timer = qemu_new_timer(vm_clock, apic_timer, s);
- vmstate_register(s->idx, &vmstate_apic, s);
+ vmstate_register(NULL, s->idx, &vmstate_apic, s);
qemu_register_reset(apic_reset, s);
local_apics[s->idx] = s;
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index c4afc6a..8286a28 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -744,5 +744,5 @@ static void gic_init(gic_state *s)
s->iomemtype = cpu_register_io_memory(gic_dist_readfn,
gic_dist_writefn, s);
gic_reset(s);
- register_savevm("arm_gic", -1, 1, gic_save, gic_load, s);
+ register_savevm(NULL, "arm_gic", -1, 1, gic_save, gic_load, s);
}
diff --git a/hw/arm_timer.c b/hw/arm_timer.c
index 9073ffc..f009e9e 100644
--- a/hw/arm_timer.c
+++ b/hw/arm_timer.c
@@ -174,7 +174,7 @@ static arm_timer_state *arm_timer_init(uint32_t freq)
bh = qemu_bh_new(arm_timer_tick, s);
s->timer = ptimer_init(bh);
- register_savevm("arm_timer", -1, 1, arm_timer_save, arm_timer_load, s);
+ register_savevm(NULL, "arm_timer", -1, 1, arm_timer_save, arm_timer_load, s);
return s;
}
@@ -271,7 +271,7 @@ static int sp804_init(SysBusDevice *dev)
iomemtype = cpu_register_io_memory(sp804_readfn,
sp804_writefn, s);
sysbus_init_mmio(dev, 0x1000, iomemtype);
- register_savevm("sp804", -1, 1, sp804_save, sp804_load, s);
+ register_savevm(&dev->qdev, "sp804", -1, 1, sp804_save, sp804_load, s);
return 0;
}
diff --git a/hw/armv7m_nvic.c b/hw/armv7m_nvic.c
index 9f09ef4..6c7ce01 100644
--- a/hw/armv7m_nvic.c
+++ b/hw/armv7m_nvic.c
@@ -397,7 +397,7 @@ static int armv7m_nvic_init(SysBusDevice *dev)
gic_init(&s->gic);
cpu_register_physical_memory(0xe000e000, 0x1000, s->gic.iomemtype);
s->systick.timer = qemu_new_timer(vm_clock, systick_timer_tick, s);
- register_savevm("armv7m_nvic", -1, 1, nvic_save, nvic_load, s);
+ register_savevm(&dev->qdev, "armv7m_nvic", -1, 1, nvic_save, nvic_load, s);
return 0;
}
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index ba48289..bbd4b08 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3128,7 +3128,7 @@ void isa_cirrus_vga_init(void)
s->vga.ds = graphic_console_init(s->vga.update, s->vga.invalidate,
s->vga.screen_dump, s->vga.text_update,
&s->vga);
- vmstate_register(0, &vmstate_cirrus_vga, s);
+ vmstate_register(NULL, 0, &vmstate_cirrus_vga, s);
rom_add_vga(VGABIOS_CIRRUS_FILENAME);
/* XXX ISA-LFB support */
}
diff --git a/hw/cuda.c b/hw/cuda.c
index 50950d9..3f238b6 100644
--- a/hw/cuda.c
+++ b/hw/cuda.c
@@ -763,6 +763,6 @@ void cuda_init (int *cuda_mem_index, qemu_irq irq)
s->adb_poll_timer = qemu_new_timer(vm_clock, cuda_adb_poll, s);
*cuda_mem_index = cpu_register_io_memory(cuda_read, cuda_write, s);
- register_savevm("cuda", -1, 1, cuda_save, cuda_load, s);
+ register_savevm(NULL, "cuda", -1, 1, cuda_save, cuda_load, s);
qemu_register_reset(cuda_reset, s);
}
diff --git a/hw/dma.c b/hw/dma.c
index 5b21521..8a7302a 100644
--- a/hw/dma.c
+++ b/hw/dma.c
@@ -548,8 +548,8 @@ void DMA_init(int high_page_enable, qemu_irq *cpu_request_exit)
high_page_enable ? 0x480 : -1, cpu_request_exit);
dma_init2(&dma_controllers[1], 0xc0, 1, 0x88,
high_page_enable ? 0x488 : -1, cpu_request_exit);
- vmstate_register (0, &vmstate_dma, &dma_controllers[0]);
- vmstate_register (1, &vmstate_dma, &dma_controllers[1]);
+ vmstate_register (NULL, 0, &vmstate_dma, &dma_controllers[0]);
+ vmstate_register (NULL, 1, &vmstate_dma, &dma_controllers[1]);
dma_bh = qemu_bh_new(DMA_run_bh, NULL);
}
diff --git a/hw/eepro100.c b/hw/eepro100.c
index a74d834..92cfea7 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1835,7 +1835,7 @@ static int pci_nic_uninit(PCIDevice *pci_dev)
EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
cpu_unregister_io_memory(s->mmio_index);
- vmstate_unregister(s->vmstate, s);
+ vmstate_unregister(&pci_dev->qdev, s->vmstate, s);
eeprom93xx_free(s->eeprom);
qemu_del_vlan_client(&s->nic->nc);
return 0;
@@ -1894,7 +1894,7 @@ static int e100_nic_init(PCIDevice *pci_dev)
s->vmstate = qemu_malloc(sizeof(vmstate_eepro100));
memcpy(s->vmstate, &vmstate_eepro100, sizeof(vmstate_eepro100));
s->vmstate->name = s->nic->nc.model;
- vmstate_register(-1, s->vmstate, s);
+ vmstate_register(&pci_dev->qdev, -1, s->vmstate, s);
return 0;
}
diff --git a/hw/eeprom93xx.c b/hw/eeprom93xx.c
index 30a3534..6ba546f 100644
--- a/hw/eeprom93xx.c
+++ b/hw/eeprom93xx.c
@@ -316,7 +316,7 @@ eeprom_t *eeprom93xx_new(uint16_t nwords)
/* Output DO is tristate, read results in 1. */
eeprom->eedo = 1;
logout("eeprom = 0x%p, nwords = %u\n", eeprom, nwords);
- vmstate_register(0, &vmstate_eeprom, eeprom);
+ vmstate_register(NULL, 0, &vmstate_eeprom, eeprom);
return eeprom;
}
@@ -324,7 +324,7 @@ void eeprom93xx_free(eeprom_t *eeprom)
{
/* Destroy EEPROM. */
logout("eeprom = 0x%p\n", eeprom);
- vmstate_unregister(&vmstate_eeprom, eeprom);
+ vmstate_unregister(NULL, &vmstate_eeprom, eeprom);
qemu_free(eeprom);
}
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 22ebb50..ca8c538 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -352,7 +352,7 @@ FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
fw_cfg_add_i16(s, FW_CFG_MAX_CPUS, (uint16_t)max_cpus);
fw_cfg_add_i16(s, FW_CFG_BOOT_MENU, (uint16_t)boot_menu);
- vmstate_register(-1, &vmstate_fw_cfg, s);
+ vmstate_register(NULL, -1, &vmstate_fw_cfg, s);
qemu_register_reset(fw_cfg_reset, s);
return s;
diff --git a/hw/g364fb.c b/hw/g364fb.c
index d1d2c12..beafd70 100644
--- a/hw/g364fb.c
+++ b/hw/g364fb.c
@@ -598,7 +598,7 @@ int g364fb_mm_init(target_phys_addr_t vram_base,
s->irq = irq;
qemu_register_reset(g364fb_reset, s);
- register_savevm("g364fb", 0, 1, g364fb_save, g364fb_load, s);
+ register_savevm(NULL, "g364fb", 0, 1, g364fb_save, g364fb_load, s);
g364fb_reset(s);
s->ds = graphic_console_init(g364fb_update_display,
diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index aa0c51b..0cf29dc 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -113,8 +113,8 @@ static int pci_grackle_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
- register_savevm("grackle", 0, 1, pci_grackle_save, pci_grackle_load,
- &s->host_state);
+ register_savevm(&dev->qdev, "grackle", 0, 1, pci_grackle_save,
+ pci_grackle_load, &s->host_state);
qemu_register_reset(pci_grackle_reset, &s->host_state);
return 0;
}
diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c
index 7691e1d..313c080 100644
--- a/hw/gt64xxx.c
+++ b/hw/gt64xxx.c
@@ -1146,7 +1146,8 @@ PCIBus *pci_gt64120_init(qemu_irq *pic)
gt64120_reset(s);
- register_savevm("GT64120 PCI Bus", 0, 1, gt64120_save, gt64120_load, d);
+ register_savevm(&d->qdev, "GT64120 PCI Bus", 0, 1,
+ gt64120_save, gt64120_load, d);
return s->pci->bus;
}
diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
index 5e27021..cd86121 100644
--- a/hw/heathrow_pic.c
+++ b/hw/heathrow_pic.c
@@ -224,7 +224,7 @@ qemu_irq *heathrow_pic_init(int *pmem_index,
s->irqs = irqs[0];
*pmem_index = cpu_register_io_memory(pic_read, pic_write, s);
- register_savevm("heathrow_pic", -1, 1, heathrow_pic_save,
+ register_savevm(NULL, "heathrow_pic", -1, 1, heathrow_pic_save,
heathrow_pic_load, s);
qemu_register_reset(heathrow_pic_reset, s);
return qemu_allocate_irqs(heathrow_pic_set_irq, s, 64);
diff --git a/hw/hpet.c b/hw/hpet.c
index 8729fb2..b2a48bb 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -577,7 +577,7 @@ void hpet_init(qemu_irq *irq) {
HPETTimer *timer = &s->timer[i];
timer->qemu_timer = qemu_new_timer(vm_clock, hpet_timer, timer);
}
- vmstate_register(-1, &vmstate_hpet, s);
+ vmstate_register(NULL, -1, &vmstate_hpet, s);
qemu_register_reset(hpet_reset, s);
/* HPET Area */
iomemtype = cpu_register_io_memory(hpet_ram_read,
diff --git a/hw/hw.h b/hw/hw.h
index fc2d184..f7b2406 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -246,14 +246,16 @@ typedef int SaveLiveStateHandler(Monitor *mon, QEMUFile *f, int stage,
void *opaque);
typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id);
-int register_savevm(const char *idstr,
+int register_savevm(DeviceState *dev,
+ const char *idstr,
int instance_id,
int version_id,
SaveStateHandler *save_state,
LoadStateHandler *load_state,
void *opaque);
-int register_savevm_live(const char *idstr,
+int register_savevm_live(DeviceState *dev,
+ const char *idstr,
int instance_id,
int version_id,
SaveSetParamsHandler *set_params,
@@ -262,7 +264,7 @@ int register_savevm_live(const char *idstr,
LoadStateHandler *load_state,
void *opaque);
-void unregister_savevm(const char *idstr, void *opaque);
+void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque);
typedef void QEMUResetHandler(void *opaque);
@@ -756,11 +758,13 @@ extern int vmstate_load_state(QEMUFile *f, const VMStateDescription *vmsd,
void *opaque, int version_id);
extern void vmstate_save_state(QEMUFile *f, const VMStateDescription *vmsd,
void *opaque);
-extern int vmstate_register(int instance_id, const VMStateDescription *vmsd,
- void *base);
-extern int vmstate_register_with_alias_id(int instance_id,
+extern int vmstate_register(DeviceState *dev, int instance_id,
+ const VMStateDescription *vmsd, void *base);
+extern int vmstate_register_with_alias_id(DeviceState *dev,
+ int instance_id,
const VMStateDescription *vmsd,
void *base, int alias_id,
int required_for_version);
-void vmstate_unregister(const VMStateDescription *vmsd, void *opaque);
+void vmstate_unregister(DeviceState *dev, const VMStateDescription *vmsd,
+ void *opaque);
#endif
diff --git a/hw/i2c.c b/hw/i2c.c
index bee8e88..f80d12d 100644
--- a/hw/i2c.c
+++ b/hw/i2c.c
@@ -62,7 +62,7 @@ i2c_bus *i2c_init_bus(DeviceState *parent, const char *name)
i2c_bus *bus;
bus = FROM_QBUS(i2c_bus, qbus_create(&i2c_bus_info, parent, name));
- vmstate_register(-1, &vmstate_i2c_bus, bus);
+ vmstate_register(NULL, -1, &vmstate_i2c_bus, bus);
return bus;
}
diff --git a/hw/i8254.c b/hw/i8254.c
index faaa884..06b225c 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
@@ -508,7 +508,7 @@ PITState *pit_init(int base, qemu_irq irq)
s->irq_timer = qemu_new_timer(vm_clock, pit_irq_timer, s);
s->irq = irq;
- vmstate_register(base, &vmstate_pit, pit);
+ vmstate_register(NULL, base, &vmstate_pit, pit);
qemu_register_reset(pit_reset, pit);
register_ioport_write(base, 4, 1, pit_ioport_write, pit);
register_ioport_read(base, 3, 1, pit_ioport_read, pit);
diff --git a/hw/i8259.c b/hw/i8259.c
index a995280..a8dbee6 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -483,7 +483,7 @@ static void pic_init1(int io_addr, int elcr_addr, PicState *s)
register_ioport_write(elcr_addr, 1, 1, elcr_ioport_write, s);
register_ioport_read(elcr_addr, 1, 1, elcr_ioport_read, s);
}
- vmstate_register(io_addr, &vmstate_pic, s);
+ vmstate_register(NULL, io_addr, &vmstate_pic, s);
qemu_register_reset(pic_reset, s);
}
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index cdcc9bf..aff8655 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -263,7 +263,7 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
ide_init2(&d->bus[0], NULL, NULL, irq[0]);
ide_init2(&d->bus[1], NULL, NULL, irq[1]);
- vmstate_register(0, &vmstate_ide_pci, d);
+ vmstate_register(&dev->qdev, 0, &vmstate_ide_pci, d);
qemu_register_reset(cmd646_reset, d);
return 0;
}
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index dff7c79..f1d220b 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -71,7 +71,7 @@ static int isa_ide_initfn(ISADevice *dev)
ide_init_ioport(&s->bus, s->iobase, s->iobase2);
isa_init_irq(dev, &s->irq, s->isairq);
ide_init2(&s->bus, NULL, NULL, s->irq);
- vmstate_register(0, &vmstate_ide_isa, s);
+ vmstate_register(&dev->qdev, 0, &vmstate_ide_isa, s);
return 0;
};
diff --git a/hw/ide/macio.c b/hw/ide/macio.c
index 639f3f6..2574942 100644
--- a/hw/ide/macio.c
+++ b/hw/ide/macio.c
@@ -321,7 +321,7 @@ int pmac_ide_init (DriveInfo **hd_table, qemu_irq irq,
pmac_ide_memory = cpu_register_io_memory(pmac_ide_read,
pmac_ide_write, d);
- vmstate_register(0, &vmstate_pmac, d);
+ vmstate_register(NULL, 0, &vmstate_pmac, d);
qemu_register_reset(pmac_ide_reset, d);
return pmac_ide_memory;
diff --git a/hw/ide/microdrive.c b/hw/ide/microdrive.c
index bfdb8c8..30c8aa4 100644
--- a/hw/ide/microdrive.c
+++ b/hw/ide/microdrive.c
@@ -544,7 +544,7 @@ PCMCIACardState *dscm1xxxx_init(DriveInfo *bdrv)
md->bus.ifs[0].mdata_size = METADATA_SIZE;
md->bus.ifs[0].mdata_storage = (uint8_t *) qemu_mallocz(METADATA_SIZE);
- vmstate_register(-1, &vmstate_microdrive, md);
+ vmstate_register(NULL, -1, &vmstate_microdrive, md);
return &md->card;
}
diff --git a/hw/ide/mmio.c b/hw/ide/mmio.c
index cca883f..5909f21 100644
--- a/hw/ide/mmio.c
+++ b/hw/ide/mmio.c
@@ -133,7 +133,7 @@ void mmio_ide_init (target_phys_addr_t membase, target_phys_addr_t membase2,
mem2 = cpu_register_io_memory(mmio_ide_status, mmio_ide_cmd, s);
cpu_register_physical_memory(membase, 16 << shift, mem1);
cpu_register_physical_memory(membase2, 2 << shift, mem2);
- vmstate_register(0, &vmstate_ide_mmio, s);
+ vmstate_register(NULL, 0, &vmstate_ide_mmio, s);
qemu_register_reset(mmio_ide_reset, s);
}
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 4fa3851..431a9ea 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -128,7 +128,7 @@ static int pci_piix_ide_initfn(PCIIDEState *d)
pci_register_bar(&d->dev, 4, 0x10, PCI_BASE_ADDRESS_SPACE_IO, bmdma_map);
- vmstate_register(0, &vmstate_ide_pci, d);
+ vmstate_register(&d->dev.qdev, 0, &vmstate_ide_pci, d);
ide_bus_new(&d->bus[0], &d->dev.qdev);
ide_bus_new(&d->bus[1], &d->dev.qdev);
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 335da6e..2670113 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -244,7 +244,7 @@ qemu_irq *ioapic_init(void)
ioapic_mem_write, s);
cpu_register_physical_memory(0xfec00000, 0x1000, io_memory);
- vmstate_register(0, &vmstate_ioapic, s);
+ vmstate_register(NULL, 0, &vmstate_ioapic, s);
qemu_register_reset(ioapic_reset, s);
irq = qemu_allocate_irqs(ioapic_set_irq, s, IOAPIC_NUM_PINS);
diff --git a/hw/m48t59.c b/hw/m48t59.c
index c3d7b3a..c7492a6 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -694,7 +694,7 @@ static void m48t59_init_common(M48t59State *s)
}
qemu_get_timedate(&s->alarm, 0);
- register_savevm("m48t59", -1, 1, m48t59_save, m48t59_load, s);
+ register_savevm(NULL, "m48t59", -1, 1, m48t59_save, m48t59_load, s);
}
static int m48t59_init_isa1(ISADevice *dev)
diff --git a/hw/mac_dbdma.c b/hw/mac_dbdma.c
index e2697d3..03d2d16 100644
--- a/hw/mac_dbdma.c
+++ b/hw/mac_dbdma.c
@@ -845,7 +845,7 @@ void* DBDMA_init (int *dbdma_mem_index)
s = qemu_mallocz(sizeof(DBDMA_channel) * DBDMA_CHANNELS);
*dbdma_mem_index = cpu_register_io_memory(dbdma_read, dbdma_write, s);
- register_savevm("dbdma", -1, 1, dbdma_save, dbdma_load, s);
+ register_savevm(NULL, "dbdma", -1, 1, dbdma_save, dbdma_load, s);
qemu_register_reset(dbdma_reset, s);
dbdma_bh = qemu_bh_new(DBDMA_run_bh, s);
diff --git a/hw/mac_nvram.c b/hw/mac_nvram.c
index f28db6b..a834935 100644
--- a/hw/mac_nvram.c
+++ b/hw/mac_nvram.c
@@ -140,7 +140,7 @@ MacIONVRAMState *macio_nvram_init (int *mem_index, target_phys_addr_t size,
s->mem_index = cpu_register_io_memory(nvram_read, nvram_write, s);
*mem_index = s->mem_index;
- register_savevm("macio_nvram", -1, 1, macio_nvram_save, macio_nvram_load,
+ register_savevm(NULL, "macio_nvram", -1, 1, macio_nvram_save, macio_nvram_load,
s);
qemu_register_reset(macio_nvram_reset, s);
diff --git a/hw/max111x.c b/hw/max111x.c
index bd656bb..2844665 100644
--- a/hw/max111x.c
+++ b/hw/max111x.c
@@ -143,7 +143,8 @@ static int max111x_init(SSISlave *dev, int inputs)
s->input[7] = 0x80;
s->com = 0;
- register_savevm("max111x", -1, 0, max111x_save, max111x_load, s);
+ register_savevm(&dev->qdev, "max111x", -1, 0,
+ max111x_save, max111x_load, s);
return 0;
}
diff --git a/hw/mipsnet.c b/hw/mipsnet.c
index a066f63..a95b3ce 100644
--- a/hw/mipsnet.c
+++ b/hw/mipsnet.c
@@ -239,7 +239,7 @@ static void mipsnet_cleanup(VLANClientState *nc)
{
MIPSnetState *s = DO_UPCAST(NICState, nc, nc)->opaque;
- unregister_savevm("mipsnet", s);
+ unregister_savevm(NULL, "mipsnet", s);
isa_unassign_ioport(s->io_base, 36);
@@ -284,5 +284,5 @@ void mipsnet_init (int base, qemu_irq irq, NICInfo *nd)
}
mipsnet_reset(s);
- register_savevm("mipsnet", 0, 0, mipsnet_save, mipsnet_load, s);
+ register_savevm(NULL, "mipsnet", 0, 0, mipsnet_save, mipsnet_load, s);
}
diff --git a/hw/mst_fpga.c b/hw/mst_fpga.c
index 1b6cb77..53c3610 100644
--- a/hw/mst_fpga.c
+++ b/hw/mst_fpga.c
@@ -234,6 +234,6 @@ qemu_irq *mst_irq_init(PXA2xxState *cpu, uint32_t base, int irq)
iomemtype = cpu_register_io_memory(mst_fpga_readfn,
mst_fpga_writefn, s);
cpu_register_physical_memory(base, 0x00100000, iomemtype);
- register_savevm("mainstone_fpga", 0, 0, mst_fpga_save, mst_fpga_load, s);
+ register_savevm(NULL, "mainstone_fpga", 0, 0, mst_fpga_save, mst_fpga_load, s);
return qi;
}
diff --git a/hw/nand.c b/hw/nand.c
index 40d5a6a..bc0ee98 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -503,7 +503,7 @@ NANDFlashState *nand_init(int manf_id, int chip_id)
is used. */
s->ioaddr = s->io;
- register_savevm("nand", -1, 0, nand_save, nand_load, s);
+ register_savevm(NULL, "nand", -1, 0, nand_save, nand_load, s);
return s;
}
diff --git a/hw/openpic.c b/hw/openpic.c
index ac21993..2b4cb00 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -1234,7 +1234,8 @@ qemu_irq *openpic_init (PCIBus *bus, int *pmem_index, int nb_cpus,
opp->irq_out = irq_out;
opp->need_swap = 1;
- register_savevm("openpic", 0, 2, openpic_save, openpic_load, opp);
+ register_savevm(&opp->pci_dev.qdev, "openpic", 0, 2,
+ openpic_save, openpic_load, opp);
qemu_register_reset(openpic_reset, opp);
opp->irq_raise = openpic_irq_raise;
@@ -1692,7 +1693,7 @@ qemu_irq *mpic_init (target_phys_addr_t base, int nb_cpus,
mpp->irq_raise = mpic_irq_raise;
mpp->reset = mpic_reset;
- register_savevm("mpic", 0, 2, openpic_save, openpic_load, mpp);
+ register_savevm(NULL, "mpic", 0, 2, openpic_save, openpic_load, mpp);
qemu_register_reset(mpic_reset, mpp);
return qemu_allocate_irqs(openpic_set_irq, mpp, mpp->max_irq);
diff --git a/hw/pci.c b/hw/pci.c
index cbbd1dd..e81cb30 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -230,7 +230,7 @@ void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent,
QLIST_INIT(&bus->child);
pci_host_bus_register(0, bus); /* for now only pci domain 0 is supported */
- vmstate_register(-1, &vmstate_pcibus, bus);
+ vmstate_register(NULL, -1, &vmstate_pcibus, bus);
qemu_register_reset(pci_bus_reset, bus);
}
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 3812284..0533b1d 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -418,7 +418,7 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
s->irq_mouse = mouse_irq;
s->mask = mask;
- vmstate_register(0, &vmstate_kbd, s);
+ vmstate_register(NULL, 0, &vmstate_kbd, s);
s_io_memory = cpu_register_io_memory(kbd_mm_read, kbd_mm_write, s);
cpu_register_physical_memory(base, size, s_io_memory);
diff --git a/hw/piix4.c b/hw/piix4.c
index f75951b..6f08c5a 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -87,7 +87,7 @@ static int piix4_initfn(PCIDevice *d)
uint8_t *pci_conf;
isa_bus_new(&d->qdev);
- register_savevm("PIIX4", 0, 2, piix_save, piix_load, d);
+ register_savevm(&d->qdev, "PIIX4", 0, 2, piix_save, piix_load, d);
pci_conf = d->config;
pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_INTEL);
diff --git a/hw/pl011.c b/hw/pl011.c
index 81de91e..02cf84a 100644
--- a/hw/pl011.c
+++ b/hw/pl011.c
@@ -306,7 +306,7 @@ static int pl011_init(SysBusDevice *dev, const unsigned char *id)
qemu_chr_add_handlers(s->chr, pl011_can_receive, pl011_receive,
pl011_event, s);
}
- register_savevm("pl011_uart", -1, 1, pl011_save, pl011_load, s);
+ register_savevm(&dev->qdev, "pl011_uart", -1, 1, pl011_save, pl011_load, s);
return 0;
}
diff --git a/hw/pl022.c b/hw/pl022.c
index c2e2dda..d7862bc 100644
--- a/hw/pl022.c
+++ b/hw/pl022.c
@@ -299,7 +299,7 @@ static int pl022_init(SysBusDevice *dev)
sysbus_init_irq(dev, &s->irq);
s->ssi = ssi_create_bus(&dev->qdev, "ssi");
pl022_reset(s);
- register_savevm("pl022_ssp", -1, 1, pl022_save, pl022_load, s);
+ register_savevm(&dev->qdev, "pl022_ssp", -1, 1, pl022_save, pl022_load, s);
return 0;
}
diff --git a/hw/pl061.c b/hw/pl061.c
index 7b1b636..e4505f5 100644
--- a/hw/pl061.c
+++ b/hw/pl061.c
@@ -303,7 +303,7 @@ static int pl061_init(SysBusDevice *dev)
qdev_init_gpio_in(&dev->qdev, pl061_set_irq, 8);
qdev_init_gpio_out(&dev->qdev, s->out, 8);
pl061_reset(s);
- register_savevm("pl061_gpio", -1, 1, pl061_save, pl061_load, s);
+ register_savevm(&dev->qdev, "pl061_gpio", -1, 1, pl061_save, pl061_load, s);
return 0;
}
diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c
index c9e3279..6e437e7 100644
--- a/hw/ppc4xx_pci.c
+++ b/hw/ppc4xx_pci.c
@@ -392,8 +392,8 @@ PCIBus *ppc4xx_pci_init(CPUState *env, qemu_irq pci_irqs[4],
qemu_register_reset(ppc4xx_pci_reset, controller);
/* XXX load/save code not tested. */
- register_savevm("ppc4xx_pci", ppc4xx_pci_id++, 1,
- ppc4xx_pci_save, ppc4xx_pci_load, controller);
+ register_savevm(&controller->pci_dev->qdev, "ppc4xx_pci", ppc4xx_pci_id++,
+ 1, ppc4xx_pci_save, ppc4xx_pci_load, controller);
return controller->pci_state.bus;
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index 336d284..5358f82 100644
--- a/hw/ppce500_pci.c
+++ b/hw/ppce500_pci.c
@@ -310,8 +310,8 @@ PCIBus *ppce500_pci_init(qemu_irq pci_irqs[4], target_phys_addr_t registers)
PCIE500_REG_SIZE, index);
/* XXX load/save code not tested. */
- register_savevm("ppce500_pci", ppce500_pci_id++, 1,
- ppce500_pci_save, ppce500_pci_load, controller);
+ register_savevm(&d->qdev, "ppce500_pci", ppce500_pci_id++,
+ 1, ppce500_pci_save, ppce500_pci_load, controller);
return controller->pci_state.bus;
diff --git a/hw/ps2.c b/hw/ps2.c
index f0b206a..762bb00 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -595,7 +595,7 @@ void *ps2_kbd_init(void (*update_irq)(void *, int), void *update_arg)
s->common.update_irq = update_irq;
s->common.update_arg = update_arg;
s->scancode_set = 2;
- vmstate_register(0, &vmstate_ps2_keyboard, s);
+ vmstate_register(NULL, 0, &vmstate_ps2_keyboard, s);
qemu_add_kbd_event_handler(ps2_put_keycode, s);
qemu_register_reset(ps2_kbd_reset, s);
return s;
@@ -607,7 +607,7 @@ void *ps2_mouse_init(void (*update_irq)(void *, int), void *update_arg)
s->common.update_irq = update_irq;
s->common.update_arg = update_arg;
- vmstate_register(0, &vmstate_ps2_mouse, s);
+ vmstate_register(NULL, 0, &vmstate_ps2_mouse, s);
qemu_add_mouse_event_handler(ps2_mouse_event, s, 0, "QEMU PS/2 Mouse");
qemu_register_reset(ps2_mouse_reset, s);
return s;
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
index 9095386..2ea363c 100644
--- a/hw/pxa2xx.c
+++ b/hw/pxa2xx.c
@@ -860,7 +860,7 @@ static int pxa2xx_ssp_init(SysBusDevice *dev)
iomemtype = cpu_register_io_memory(pxa2xx_ssp_readfn,
pxa2xx_ssp_writefn, s);
sysbus_init_mmio(dev, 0x1000, iomemtype);
- register_savevm("pxa2xx_ssp", -1, 0,
+ register_savevm(&dev->qdev, "pxa2xx_ssp", -1, 0,
pxa2xx_ssp_save, pxa2xx_ssp_load, s);
s->bus = ssi_create_bus(&dev->qdev, "ssi");
@@ -1515,7 +1515,7 @@ PXA2xxI2CState *pxa2xx_i2c_init(target_phys_addr_t base,
cpu_register_physical_memory(base & ~region_size,
region_size + 1, iomemtype);
- vmstate_register(base, &vmstate_pxa2xx_i2c, s);
+ vmstate_register(NULL, base, &vmstate_pxa2xx_i2c, s);
return s;
}
@@ -1751,7 +1751,7 @@ static PXA2xxI2SState *pxa2xx_i2s_init(target_phys_addr_t base,
pxa2xx_i2s_writefn, s);
cpu_register_physical_memory(base, 0x100000, iomemtype);
- register_savevm("pxa2xx_i2s", base, 0,
+ register_savevm(NULL, "pxa2xx_i2s", base, 0,
pxa2xx_i2s_save, pxa2xx_i2s_load, s);
return s;
@@ -2014,7 +2014,7 @@ static PXA2xxFIrState *pxa2xx_fir_init(target_phys_addr_t base,
qemu_chr_add_handlers(chr, pxa2xx_fir_is_empty,
pxa2xx_fir_rx, pxa2xx_fir_event, s);
- register_savevm("pxa2xx_fir", 0, 0, pxa2xx_fir_save, pxa2xx_fir_load, s);
+ register_savevm(NULL, "pxa2xx_fir", 0, 0, pxa2xx_fir_save, pxa2xx_fir_load, s);
return s;
}
@@ -2099,7 +2099,7 @@ PXA2xxState *pxa270_init(unsigned int sdram_size, const char *revision)
iomemtype = cpu_register_io_memory(pxa2xx_cm_readfn,
pxa2xx_cm_writefn, s);
cpu_register_physical_memory(s->cm_base, 0x1000, iomemtype);
- register_savevm("pxa2xx_cm", 0, 0, pxa2xx_cm_save, pxa2xx_cm_load, s);
+ register_savevm(NULL, "pxa2xx_cm", 0, 0, pxa2xx_cm_save, pxa2xx_cm_load, s);
cpu_arm_set_cp_io(s->env, 14, pxa2xx_cp14_read, pxa2xx_cp14_write, s);
@@ -2110,13 +2110,13 @@ PXA2xxState *pxa270_init(unsigned int sdram_size, const char *revision)
iomemtype = cpu_register_io_memory(pxa2xx_mm_readfn,
pxa2xx_mm_writefn, s);
cpu_register_physical_memory(s->mm_base, 0x1000, iomemtype);
- register_savevm("pxa2xx_mm", 0, 0, pxa2xx_mm_save, pxa2xx_mm_load, s);
+ register_savevm(NULL, "pxa2xx_mm", 0, 0, pxa2xx_mm_save, pxa2xx_mm_load, s);
s->pm_base = 0x40f00000;
iomemtype = cpu_register_io_memory(pxa2xx_pm_readfn,
pxa2xx_pm_writefn, s);
cpu_register_physical_memory(s->pm_base, 0x100, iomemtype);
- register_savevm("pxa2xx_pm", 0, 0, pxa2xx_pm_save, pxa2xx_pm_load, s);
+ register_savevm(NULL, "pxa2xx_pm", 0, 0, pxa2xx_pm_save, pxa2xx_pm_load, s);
for (i = 0; pxa27x_ssp[i].io_base; i ++);
s->ssp = (SSIBus **)qemu_mallocz(sizeof(SSIBus *) * i);
@@ -2140,7 +2140,7 @@ PXA2xxState *pxa270_init(unsigned int sdram_size, const char *revision)
pxa2xx_rtc_writefn, s);
cpu_register_physical_memory(s->rtc_base, 0x1000, iomemtype);
pxa2xx_rtc_init(s);
- register_savevm("pxa2xx_rtc", 0, 0, pxa2xx_rtc_save, pxa2xx_rtc_load, s);
+ register_savevm(NULL, "pxa2xx_rtc", 0, 0, pxa2xx_rtc_save, pxa2xx_rtc_load, s);
s->i2c[0] = pxa2xx_i2c_init(0x40301600, s->pic[PXA2XX_PIC_I2C], 0xffff);
s->i2c[1] = pxa2xx_i2c_init(0x40f00100, s->pic[PXA2XX_PIC_PWRI2C], 0xff);
@@ -2219,7 +2219,7 @@ PXA2xxState *pxa255_init(unsigned int sdram_size)
iomemtype = cpu_register_io_memory(pxa2xx_cm_readfn,
pxa2xx_cm_writefn, s);
cpu_register_physical_memory(s->cm_base, 0x1000, iomemtype);
- register_savevm("pxa2xx_cm", 0, 0, pxa2xx_cm_save, pxa2xx_cm_load, s);
+ register_savevm(NULL, "pxa2xx_cm", 0, 0, pxa2xx_cm_save, pxa2xx_cm_load, s);
cpu_arm_set_cp_io(s->env, 14, pxa2xx_cp14_read, pxa2xx_cp14_write, s);
@@ -2230,13 +2230,13 @@ PXA2xxState *pxa255_init(unsigned int sdram_size)
iomemtype = cpu_register_io_memory(pxa2xx_mm_readfn,
pxa2xx_mm_writefn, s);
cpu_register_physical_memory(s->mm_base, 0x1000, iomemtype);
- register_savevm("pxa2xx_mm", 0, 0, pxa2xx_mm_save, pxa2xx_mm_load, s);
+ register_savevm(NULL, "pxa2xx_mm", 0, 0, pxa2xx_mm_save, pxa2xx_mm_load, s);
s->pm_base = 0x40f00000;
iomemtype = cpu_register_io_memory(pxa2xx_pm_readfn,
pxa2xx_pm_writefn, s);
cpu_register_physical_memory(s->pm_base, 0x100, iomemtype);
- register_savevm("pxa2xx_pm", 0, 0, pxa2xx_pm_save, pxa2xx_pm_load, s);
+ register_savevm(NULL, "pxa2xx_pm", 0, 0, pxa2xx_pm_save, pxa2xx_pm_load, s);
for (i = 0; pxa255_ssp[i].io_base; i ++);
s->ssp = (SSIBus **)qemu_mallocz(sizeof(SSIBus *) * i);
@@ -2260,7 +2260,7 @@ PXA2xxState *pxa255_init(unsigned int sdram_size)
pxa2xx_rtc_writefn, s);
cpu_register_physical_memory(s->rtc_base, 0x1000, iomemtype);
pxa2xx_rtc_init(s);
- register_savevm("pxa2xx_rtc", 0, 0, pxa2xx_rtc_save, pxa2xx_rtc_load, s);
+ register_savevm(NULL, "pxa2xx_rtc", 0, 0, pxa2xx_rtc_save, pxa2xx_rtc_load, s);
s->i2c[0] = pxa2xx_i2c_init(0x40301600, s->pic[PXA2XX_PIC_I2C], 0xffff);
s->i2c[1] = pxa2xx_i2c_init(0x40f00100, s->pic[PXA2XX_PIC_PWRI2C], 0xff);
diff --git a/hw/pxa2xx_dma.c b/hw/pxa2xx_dma.c
index 66c2c30..9c479df 100644
--- a/hw/pxa2xx_dma.c
+++ b/hw/pxa2xx_dma.c
@@ -507,7 +507,7 @@ static PXA2xxDMAState *pxa2xx_dma_init(target_phys_addr_t base,
pxa2xx_dma_writefn, s);
cpu_register_physical_memory(base, 0x00010000, iomemtype);
- register_savevm("pxa2xx_dma", 0, 0, pxa2xx_dma_save, pxa2xx_dma_load, s);
+ register_savevm(NULL, "pxa2xx_dma", 0, 0, pxa2xx_dma_save, pxa2xx_dma_load, s);
return s;
}
diff --git a/hw/pxa2xx_gpio.c b/hw/pxa2xx_gpio.c
index f354f4b..2abcb65 100644
--- a/hw/pxa2xx_gpio.c
+++ b/hw/pxa2xx_gpio.c
@@ -312,7 +312,7 @@ PXA2xxGPIOInfo *pxa2xx_gpio_init(target_phys_addr_t base,
pxa2xx_gpio_writefn, s);
cpu_register_physical_memory(base, 0x00001000, iomemtype);
- register_savevm("pxa2xx_gpio", 0, 0,
+ register_savevm(NULL, "pxa2xx_gpio", 0, 0,
pxa2xx_gpio_save, pxa2xx_gpio_load, s);
return s;
diff --git a/hw/pxa2xx_keypad.c b/hw/pxa2xx_keypad.c
index 060df58..dfa8945 100644
--- a/hw/pxa2xx_keypad.c
+++ b/hw/pxa2xx_keypad.c
@@ -317,7 +317,7 @@ PXA2xxKeyPadState *pxa27x_keypad_init(target_phys_addr_t base,
pxa2xx_keypad_writefn, s);
cpu_register_physical_memory(base, 0x00100000, iomemtype);
- register_savevm("pxa2xx_keypad", 0, 0,
+ register_savevm(NULL, "pxa2xx_keypad", 0, 0,
pxa2xx_keypad_save, pxa2xx_keypad_load, s);
return s;
diff --git a/hw/pxa2xx_lcd.c b/hw/pxa2xx_lcd.c
index 930299a..111a0dc 100644
--- a/hw/pxa2xx_lcd.c
+++ b/hw/pxa2xx_lcd.c
@@ -970,7 +970,7 @@ PXA2xxLCDState *pxa2xx_lcdc_init(target_phys_addr_t base, qemu_irq irq)
exit(1);
}
- register_savevm("pxa2xx_lcdc", 0, 0,
+ register_savevm(NULL, "pxa2xx_lcdc", 0, 0,
pxa2xx_lcdc_save, pxa2xx_lcdc_load, s);
return s;
diff --git a/hw/pxa2xx_mmci.c b/hw/pxa2xx_mmci.c
index a415349..ca98660 100644
--- a/hw/pxa2xx_mmci.c
+++ b/hw/pxa2xx_mmci.c
@@ -534,7 +534,7 @@ PXA2xxMMCIState *pxa2xx_mmci_init(target_phys_addr_t base,
/* Instantiate the actual storage */
s->card = sd_init(bd, 0);
- register_savevm("pxa2xx_mmci", 0, 0,
+ register_savevm(NULL, "pxa2xx_mmci", 0, 0,
pxa2xx_mmci_save, pxa2xx_mmci_load, s);
return s;
diff --git a/hw/pxa2xx_pic.c b/hw/pxa2xx_pic.c
index 0a98342..353d885 100644
--- a/hw/pxa2xx_pic.c
+++ b/hw/pxa2xx_pic.c
@@ -306,7 +306,7 @@ qemu_irq *pxa2xx_pic_init(target_phys_addr_t base, CPUState *env)
/* Enable IC coprocessor access. */
cpu_arm_set_cp_io(env, 6, pxa2xx_pic_cp_read, pxa2xx_pic_cp_write, s);
- register_savevm("pxa2xx_pic", 0, 0, pxa2xx_pic_save, pxa2xx_pic_load, s);
+ register_savevm(NULL, "pxa2xx_pic", 0, 0, pxa2xx_pic_save, pxa2xx_pic_load, s);
return qi;
}
diff --git a/hw/pxa2xx_timer.c b/hw/pxa2xx_timer.c
index d992cc3..0f0ffd3 100644
--- a/hw/pxa2xx_timer.c
+++ b/hw/pxa2xx_timer.c
@@ -455,7 +455,7 @@ static pxa2xx_timer_info *pxa2xx_timer_init(target_phys_addr_t base,
pxa2xx_timer_writefn, s);
cpu_register_physical_memory(base, 0x00001000, iomemtype);
- register_savevm("pxa2xx_timer", 0, 0,
+ register_savevm(NULL, "pxa2xx_timer", 0, 0,
pxa2xx_timer_save, pxa2xx_timer_load, s);
return s;
diff --git a/hw/qdev.c b/hw/qdev.c
index dea44fe..a81c1e2 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -337,7 +337,7 @@ int qdev_init(DeviceState *dev)
}
qemu_register_reset(qdev_reset, dev);
if (dev->info->vmsd) {
- vmstate_register_with_alias_id(-1, dev->info->vmsd, dev,
+ vmstate_register_with_alias_id(dev, -1, dev->info->vmsd, dev,
dev->instance_id_alias,
dev->alias_required_for_version);
}
@@ -398,7 +398,7 @@ void qdev_free(DeviceState *dev)
qbus_free(bus);
}
if (dev->info->vmsd)
- vmstate_unregister(dev->info->vmsd, dev);
+ vmstate_unregister(dev, dev->info->vmsd, dev);
if (dev->info->exit)
dev->info->exit(dev);
if (dev->opts)
diff --git a/hw/rc4030.c b/hw/rc4030.c
index 2a8233a..2231373 100644
--- a/hw/rc4030.c
+++ b/hw/rc4030.c
@@ -813,7 +813,7 @@ void *rc4030_init(qemu_irq timer, qemu_irq jazz_bus,
s->jazz_bus_irq = jazz_bus;
qemu_register_reset(rc4030_reset, s);
- register_savevm("rc4030", 0, 2, rc4030_save, rc4030_load, s);
+ register_savevm(NULL, "rc4030", 0, 2, rc4030_save, rc4030_load, s);
rc4030_reset(s);
s_chipset = cpu_register_io_memory(rc4030_read, rc4030_write, s);
diff --git a/hw/serial.c b/hw/serial.c
index 9102edb..09e3489 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -812,7 +812,7 @@ SerialState *serial_init(int base, qemu_irq irq, int baudbase,
s->chr = chr;
serial_init_core(s);
- vmstate_register(base, &vmstate_serial, s);
+ vmstate_register(NULL, base, &vmstate_serial, s);
register_ioport_write(base, 8, 1, serial_ioport_write, s);
register_ioport_read(base, 8, 1, serial_ioport_read, s);
@@ -947,7 +947,7 @@ SerialState *serial_mm_init (target_phys_addr_t base, int it_shift,
s->chr = chr;
serial_init_core(s);
- vmstate_register(base, &vmstate_serial, s);
+ vmstate_register(NULL, base, &vmstate_serial, s);
if (ioregister) {
if (be) {
diff --git a/hw/spitz.c b/hw/spitz.c
index 4f82e24..943933f 100644
--- a/hw/spitz.c
+++ b/hw/spitz.c
@@ -178,7 +178,7 @@ static void sl_flash_register(PXA2xxState *cpu, int size)
sl_writefn, s);
cpu_register_physical_memory(FLASH_BASE, 0x40, iomemtype);
- register_savevm("sl_flash", 0, 0, sl_save, sl_load, s);
+ register_savevm(NULL, "sl_flash", 0, 0, sl_save, sl_load, s);
}
/* Spitz Keyboard */
@@ -508,7 +508,7 @@ static void spitz_keyboard_register(PXA2xxState *cpu)
spitz_keyboard_pre_map(s);
qemu_add_kbd_event_handler((QEMUPutKBDEvent *) spitz_keyboard_handler, s);
- register_savevm("spitz_keyboard", 0, 0,
+ register_savevm(NULL, "spitz_keyboard", 0, 0,
spitz_keyboard_save, spitz_keyboard_load, s);
}
@@ -613,7 +613,7 @@ static int spitz_lcdtg_init(SSISlave *dev)
s->bl_power = 0;
s->bl_intensity = 0x20;
- register_savevm("spitz-lcdtg", -1, 1,
+ register_savevm(&dev->qdev, "spitz-lcdtg", -1, 1,
spitz_lcdtg_save, spitz_lcdtg_load, s);
return 0;
}
@@ -708,7 +708,8 @@ static int corgi_ssp_init(SSISlave *dev)
s->bus[1] = ssi_create_bus(&dev->qdev, "ssi1");
s->bus[2] = ssi_create_bus(&dev->qdev, "ssi2");
- register_savevm("spitz_ssp", -1, 1, spitz_ssp_save, spitz_ssp_load, s);
+ register_savevm(&dev->qdev, "spitz_ssp", -1, 1,
+ spitz_ssp_save, spitz_ssp_load, s);
return 0;
}
diff --git a/hw/ssd0323.c b/hw/ssd0323.c
index b632825..8643961 100644
--- a/hw/ssd0323.c
+++ b/hw/ssd0323.c
@@ -335,7 +335,8 @@ static int ssd0323_init(SSISlave *dev)
qdev_init_gpio_in(&dev->qdev, ssd0323_cd, 1);
- register_savevm("ssd0323_oled", -1, 1, ssd0323_save, ssd0323_load, s);
+ register_savevm(&dev->qdev, "ssd0323_oled", -1, 1,
+ ssd0323_save, ssd0323_load, s);
return 0;
}
diff --git a/hw/ssi-sd.c b/hw/ssi-sd.c
index 5e74e5d..b0fed58 100644
--- a/hw/ssi-sd.c
+++ b/hw/ssi-sd.c
@@ -237,7 +237,7 @@ static int ssi_sd_init(SSISlave *dev)
s->mode = SSI_SD_CMD;
bs = qdev_init_bdrv(&dev->qdev, IF_SD);
s->sd = sd_init(bs, 1);
- register_savevm("ssi_sd", -1, 1, ssi_sd_save, ssi_sd_load, s);
+ register_savevm(&dev->qdev, "ssi_sd", -1, 1, ssi_sd_save, ssi_sd_load, s);
return 0;
}
diff --git a/hw/stellaris.c b/hw/stellaris.c
index 5755f8a..ccad134 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -354,7 +354,8 @@ static int stellaris_gptm_init(SysBusDevice *dev)
s->opaque[0] = s->opaque[1] = s;
s->timer[0] = qemu_new_timer(vm_clock, gptm_tick, &s->opaque[0]);
s->timer[1] = qemu_new_timer(vm_clock, gptm_tick, &s->opaque[1]);
- register_savevm("stellaris_gptm", -1, 1, gptm_save, gptm_load, s);
+ register_savevm(&dev->qdev, "stellaris_gptm", -1, 1,
+ gptm_save, gptm_load, s);
return 0;
}
@@ -673,7 +674,7 @@ static int stellaris_sys_init(uint32_t base, qemu_irq irq,
ssys_writefn, s);
cpu_register_physical_memory(base, 0x00001000, iomemtype);
ssys_reset(s);
- register_savevm("stellaris_sys", -1, 1, ssys_save, ssys_load, s);
+ register_savevm(NULL, "stellaris_sys", -1, 1, ssys_save, ssys_load, s);
return 0;
}
@@ -887,7 +888,7 @@ static int stellaris_i2c_init(SysBusDevice * dev)
sysbus_init_mmio(dev, 0x1000, iomemtype);
/* ??? For now we only implement the master interface. */
stellaris_i2c_reset(s);
- register_savevm("stellaris_i2c", -1, 1,
+ register_savevm(&dev->qdev, "stellaris_i2c", -1, 1,
stellaris_i2c_save, stellaris_i2c_load, s);
return 0;
}
@@ -1196,7 +1197,7 @@ static int stellaris_adc_init(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, iomemtype);
stellaris_adc_reset(s);
qdev_init_gpio_in(&dev->qdev, stellaris_adc_trigger, 1);
- register_savevm("stellaris_adc", -1, 1,
+ register_savevm(&dev->qdev, "stellaris_adc", -1, 1,
stellaris_adc_save, stellaris_adc_load, s);
return 0;
}
@@ -1256,7 +1257,7 @@ static int stellaris_ssi_bus_init(SSISlave *dev)
s->bus[1] = ssi_create_bus(&dev->qdev, "ssi1");
qdev_init_gpio_in(&dev->qdev, stellaris_ssi_bus_select, 1);
- register_savevm("stellaris_ssi_bus", -1, 1,
+ register_savevm(&dev->qdev, "stellaris_ssi_bus", -1, 1,
stellaris_ssi_bus_save, stellaris_ssi_bus_load, s);
return 0;
}
diff --git a/hw/stellaris_enet.c b/hw/stellaris_enet.c
index d1d755e..330a9d6 100644
--- a/hw/stellaris_enet.c
+++ b/hw/stellaris_enet.c
@@ -389,7 +389,7 @@ static void stellaris_enet_cleanup(VLANClientState *nc)
{
stellaris_enet_state *s = DO_UPCAST(NICState, nc, nc)->opaque;
- unregister_savevm("stellaris_enet", s);
+ unregister_savevm(&s->busdev.qdev, "stellaris_enet", s);
cpu_unregister_io_memory(s->mmio_index);
@@ -419,7 +419,7 @@ static int stellaris_enet_init(SysBusDevice *dev)
qemu_format_nic_info_str(&s->nic->nc, s->conf.macaddr.a);
stellaris_enet_reset(s);
- register_savevm("stellaris_enet", -1, 1,
+ register_savevm(&s->busdev.qdev, "stellaris_enet", -1, 1,
stellaris_enet_save, stellaris_enet_load, s);
return 0;
}
diff --git a/hw/stellaris_input.c b/hw/stellaris_input.c
index 33395a4..16aae96 100644
--- a/hw/stellaris_input.c
+++ b/hw/stellaris_input.c
@@ -86,6 +86,6 @@ void stellaris_gamepad_init(int n, qemu_irq *irq, const int *keycode)
}
s->num_buttons = n;
qemu_add_kbd_event_handler(stellaris_gamepad_put_key, s);
- register_savevm("stellaris_gamepad", -1, 1,
+ register_savevm(NULL, "stellaris_gamepad", -1, 1,
stellaris_gamepad_save, stellaris_gamepad_load, s);
}
diff --git a/hw/syborg_fb.c b/hw/syborg_fb.c
index 7be04a3..ed57203 100644
--- a/hw/syborg_fb.c
+++ b/hw/syborg_fb.c
@@ -526,7 +526,7 @@ static int syborg_fb_init(SysBusDevice *dev)
if (!s->rows)
s->rows = ds_get_height(s->ds);
- register_savevm("syborg_framebuffer", -1, 1,
+ register_savevm(&dev->qdev, "syborg_framebuffer", -1, 1,
syborg_fb_save, syborg_fb_load, s);
return 0;
}
diff --git a/hw/syborg_interrupt.c b/hw/syborg_interrupt.c
index f3a1767..cd10416 100644
--- a/hw/syborg_interrupt.c
+++ b/hw/syborg_interrupt.c
@@ -214,7 +214,7 @@ static int syborg_int_init(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, iomemtype);
s->flags = qemu_mallocz(s->num_irqs * sizeof(syborg_int_flags));
- register_savevm("syborg_int", -1, 1, syborg_int_save, syborg_int_load, s);
+ register_savevm(&dev->qdev, "syborg_int", -1, 1, syborg_int_save, syborg_int_load, s);
return 0;
}
diff --git a/hw/syborg_keyboard.c b/hw/syborg_keyboard.c
index 4a562f8..7709100 100644
--- a/hw/syborg_keyboard.c
+++ b/hw/syborg_keyboard.c
@@ -220,7 +220,7 @@ static int syborg_keyboard_init(SysBusDevice *dev)
qemu_add_kbd_event_handler(syborg_keyboard_event, s);
- register_savevm("syborg_keyboard", -1, 1,
+ register_savevm(&dev->qdev, "syborg_keyboard", -1, 1,
syborg_keyboard_save, syborg_keyboard_load, s);
return 0;
}
diff --git a/hw/syborg_pointer.c b/hw/syborg_pointer.c
index 563d730..69b8d96 100644
--- a/hw/syborg_pointer.c
+++ b/hw/syborg_pointer.c
@@ -218,7 +218,7 @@ static int syborg_pointer_init(SysBusDevice *dev)
qemu_add_mouse_event_handler(syborg_pointer_event, s, s->absolute,
"Syborg Pointer");
- register_savevm("syborg_pointer", -1, 1,
+ register_savevm(&dev->qdev, "syborg_pointer", -1, 1,
syborg_pointer_save, syborg_pointer_load, s);
return 0;
}
diff --git a/hw/syborg_rtc.c b/hw/syborg_rtc.c
index b066213..78d5edb 100644
--- a/hw/syborg_rtc.c
+++ b/hw/syborg_rtc.c
@@ -136,7 +136,8 @@ static int syborg_rtc_init(SysBusDevice *dev)
qemu_get_timedate(&tm, 0);
s->offset = (uint64_t)mktime(&tm) * 1000000000;
- register_savevm("syborg_rtc", -1, 1, syborg_rtc_save, syborg_rtc_load, s);
+ register_savevm(&dev->qdev, "syborg_rtc", -1, 1,
+ syborg_rtc_save, syborg_rtc_load, s);
return 0;
}
diff --git a/hw/syborg_serial.c b/hw/syborg_serial.c
index cac00ea..8c42956 100644
--- a/hw/syborg_serial.c
+++ b/hw/syborg_serial.c
@@ -335,7 +335,7 @@ static int syborg_serial_init(SysBusDevice *dev)
}
s->read_fifo = qemu_mallocz(s->fifo_size * sizeof(s->read_fifo[0]));
- register_savevm("syborg_serial", -1, 1,
+ register_savevm(&dev->qdev, "syborg_serial", -1, 1,
syborg_serial_save, syborg_serial_load, s);
return 0;
}
diff --git a/hw/syborg_timer.c b/hw/syborg_timer.c
index 3e4a447..95e07d7 100644
--- a/hw/syborg_timer.c
+++ b/hw/syborg_timer.c
@@ -221,7 +221,7 @@ static int syborg_timer_init(SysBusDevice *dev)
bh = qemu_bh_new(syborg_timer_tick, s);
s->timer = ptimer_init(bh);
ptimer_set_freq(s->timer, s->freq);
- register_savevm("syborg_timer", -1, 1,
+ register_savevm(&dev->qdev, "syborg_timer", -1, 1,
syborg_timer_save, syborg_timer_load, s);
return 0;
}
diff --git a/hw/tsc2005.c b/hw/tsc2005.c
index b75cc86..a55853c 100644
--- a/hw/tsc2005.c
+++ b/hw/tsc2005.c
@@ -548,7 +548,7 @@ void *tsc2005_init(qemu_irq pintdav)
"QEMU TSC2005-driven Touchscreen");
qemu_register_reset((void *) tsc2005_reset, s);
- register_savevm("tsc2005", -1, 0, tsc2005_save, tsc2005_load, s);
+ register_savevm(NULL, "tsc2005", -1, 0, tsc2005_save, tsc2005_load, s);
return s;
}
diff --git a/hw/tsc210x.c b/hw/tsc210x.c
index e851ca1..fca73f1 100644
--- a/hw/tsc210x.c
+++ b/hw/tsc210x.c
@@ -1143,7 +1143,7 @@ uWireSlave *tsc2102_init(qemu_irq pint)
AUD_register_card(s->name, &s->card);
qemu_register_reset((void *) tsc210x_reset, s);
- register_savevm(s->name, -1, 0,
+ register_savevm(NULL, s->name, -1, 0,
tsc210x_save, tsc210x_load, s);
return &s->chip;
@@ -1194,7 +1194,7 @@ uWireSlave *tsc2301_init(qemu_irq penirq, qemu_irq kbirq, qemu_irq dav)
AUD_register_card(s->name, &s->card);
qemu_register_reset((void *) tsc210x_reset, s);
- register_savevm(s->name, -1, 0, tsc210x_save, tsc210x_load, s);
+ register_savevm(NULL, s->name, -1, 0, tsc210x_save, tsc210x_load, s);
return &s->chip;
}
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index f0a773d..362fb77 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -158,7 +158,8 @@ static int pci_unin_main_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
- register_savevm("uninorth", 0, 1, pci_unin_save, pci_unin_load, &s->host_state);
+ register_savevm(&dev->qdev, "uninorth", 0, 1,
+ pci_unin_save, pci_unin_load, &s->host_state);
qemu_register_reset(pci_unin_reset, &s->host_state);
return 0;
}
@@ -178,7 +179,8 @@ static int pci_u3_agp_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
- register_savevm("uninorth", 0, 1, pci_unin_save, pci_unin_load, &s->host_state);
+ register_savevm(&dev->qdev, "uninorth", 0, 1,
+ pci_unin_save, pci_unin_load, &s->host_state);
qemu_register_reset(pci_unin_reset, &s->host_state);
return 0;
diff --git a/hw/vga-isa-mm.c b/hw/vga-isa-mm.c
index 8e31e36..680b557 100644
--- a/hw/vga-isa-mm.c
+++ b/hw/vga-isa-mm.c
@@ -100,7 +100,7 @@ static void vga_mm_init(ISAVGAMMState *s, target_phys_addr_t vram_base,
s_ioport_ctrl = cpu_register_io_memory(vga_mm_read_ctrl, vga_mm_write_ctrl, s);
vga_io_memory = cpu_register_io_memory(vga_mem_read, vga_mem_write, s);
- vmstate_register(0, &vmstate_vga_common, s);
+ vmstate_register(NULL, 0, &vmstate_vga_common, s);
cpu_register_physical_memory(ctrl_base, 0x100000, s_ioport_ctrl);
s->vga.bank_offset = 0;
diff --git a/hw/vga-isa.c b/hw/vga-isa.c
index 7937144..3046054 100644
--- a/hw/vga-isa.c
+++ b/hw/vga-isa.c
@@ -37,7 +37,7 @@ int isa_vga_init(void)
vga_common_init(s, VGA_RAM_SIZE);
vga_init(s);
- vmstate_register(0, &vmstate_vga_common, s);
+ vmstate_register(NULL, 0, &vmstate_vga_common, s);
s->ds = graphic_console_init(s->update, s->invalidate,
s->screen_dump, s->text_update, s);
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index 152af80..9fe3886 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -270,7 +270,8 @@ VirtIODevice *virtio_balloon_init(DeviceState *dev)
reset_stats(s);
qemu_add_balloon_handler(virtio_balloon_to_target, s);
- register_savevm("virtio-balloon", -1, 1, virtio_balloon_save, virtio_balloon_load, s);
+ register_savevm(dev, "virtio-balloon", -1, 1,
+ virtio_balloon_save, virtio_balloon_load, s);
return &s->vdev;
}
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 5d7f1a2..5f523fc 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -511,7 +511,7 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf)
s->vq = virtio_add_queue(&s->vdev, 128, virtio_blk_handle_output);
qemu_add_vm_change_state_handler(virtio_blk_dma_restart_cb, s);
- register_savevm("virtio-blk", virtio_blk_id++, 2,
+ register_savevm(dev, "virtio-blk", virtio_blk_id++, 2,
virtio_blk_save, virtio_blk_load, s);
return &s->vdev;
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 06ba481..e9768e0 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -923,7 +923,7 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf)
n->vlans = qemu_mallocz(MAX_VLAN >> 3);
- register_savevm("virtio-net", virtio_net_id++, VIRTIO_NET_VM_VERSION,
+ register_savevm(NULL, "virtio-net", virtio_net_id++, VIRTIO_NET_VM_VERSION,
virtio_net_save, virtio_net_load, n);
n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change, n);
@@ -941,7 +941,7 @@ void virtio_net_exit(VirtIODevice *vdev)
qemu_purge_queued_packets(&n->nic->nc);
- unregister_savevm("virtio-net", n);
+ unregister_savevm(NULL, "virtio-net", n);
qemu_free(n->mac_table.macs);
qemu_free(n->vlans);
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 7f9d28f..b5ab3bb 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -790,7 +790,7 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t max_nr_ports)
* Register for the savevm section with the virtio-console name
* to preserve backward compat
*/
- register_savevm("virtio-console", -1, 2, virtio_serial_save,
+ register_savevm(dev, "virtio-console", -1, 2, virtio_serial_save,
virtio_serial_load, vser);
return vdev;
diff --git a/hw/vmmouse.c b/hw/vmmouse.c
index afebad9..f359304 100644
--- a/hw/vmmouse.c
+++ b/hw/vmmouse.c
@@ -274,7 +274,7 @@ void *vmmouse_init(void *m)
vmport_register(VMMOUSE_STATUS, vmmouse_ioport_read, s);
vmport_register(VMMOUSE_COMMAND, vmmouse_ioport_read, s);
vmport_register(VMMOUSE_DATA, vmmouse_ioport_read, s);
- vmstate_register(0, &vmstate_vmmouse, s);
+ vmstate_register(NULL, 0, &vmstate_vmmouse, s);
return s;
}
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index bf2a699..359e5d8 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -1169,7 +1169,7 @@ static void vmsvga_init(struct vmsvga_state_s *s, int vga_ram_size)
vga_common_init(&s->vga, vga_ram_size);
vga_init(&s->vga);
- vmstate_register(0, &vmstate_vga_common, &s->vga);
+ vmstate_register(NULL, 0, &vmstate_vga_common, &s->vga);
vga_init_vbe(&s->vga);
diff --git a/hw/zaurus.c b/hw/zaurus.c
index db6ba75..dd999d7 100644
--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -230,7 +230,7 @@ ScoopInfo *scoop_init(PXA2xxState *cpu,
iomemtype = cpu_register_io_memory(scoop_readfn,
scoop_writefn, s);
cpu_register_physical_memory(target_base, 0x1000, iomemtype);
- register_savevm("scoop", instance, 1, scoop_save, scoop_load, s);
+ register_savevm(NULL, "scoop", instance, 1, scoop_save, scoop_load, s);
return s;
}
diff --git a/qemu-timer.c b/qemu-timer.c
index bdc8206..bc5f207 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -662,7 +662,7 @@ static const VMStateDescription vmstate_timers = {
void configure_icount(const char *option)
{
- vmstate_register(0, &vmstate_timers, &timers_state);
+ vmstate_register(NULL, 0, &vmstate_timers, &timers_state);
if (!option)
return;
diff --git a/savevm.c b/savevm.c
index af92ba2..81d544f 100644
--- a/savevm.c
+++ b/savevm.c
@@ -72,6 +72,7 @@
#include "qemu-common.h"
#include "hw/hw.h"
+#include "hw/qdev.h"
#include "net.h"
#include "monitor.h"
#include "sysemu.h"
@@ -1026,7 +1027,8 @@ static int calculate_new_instance_id(const char *idstr)
of the system, so instance_id should be removed/replaced.
Meanwhile pass -1 as instance_id if you do not already have a clearly
distinguishing id for all instances of your device class. */
-int register_savevm_live(const char *idstr,
+int register_savevm_live(DeviceState *dev,
+ const char *idstr,
int instance_id,
int version_id,
SaveSetParamsHandler *set_params,
@@ -1058,18 +1060,19 @@ int register_savevm_live(const char *idstr,
return 0;
}
-int register_savevm(const char *idstr,
+int register_savevm(DeviceState *dev,
+ const char *idstr,
int instance_id,
int version_id,
SaveStateHandler *save_state,
LoadStateHandler *load_state,
void *opaque)
{
- return register_savevm_live(idstr, instance_id, version_id,
+ return register_savevm_live(dev, idstr, instance_id, version_id,
NULL, NULL, save_state, load_state, opaque);
}
-void unregister_savevm(const char *idstr, void *opaque)
+void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque)
{
SaveStateEntry *se, *new_se;
@@ -1081,7 +1084,7 @@ void unregister_savevm(const char *idstr, void *opaque)
}
}
-int vmstate_register_with_alias_id(int instance_id,
+int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
const VMStateDescription *vmsd,
void *opaque, int alias_id,
int required_for_version)
@@ -1112,13 +1115,15 @@ int vmstate_register_with_alias_id(int instance_id,
return 0;
}
-int vmstate_register(int instance_id, const VMStateDescription *vmsd,
- void *opaque)
+int vmstate_register(DeviceState *dev, int instance_id,
+ const VMStateDescription *vmsd, void *opaque)
{
- return vmstate_register_with_alias_id(instance_id, vmsd, opaque, -1, 0);
+ return vmstate_register_with_alias_id(dev, instance_id, vmsd,
+ opaque, -1, 0);
}
-void vmstate_unregister(const VMStateDescription *vmsd, void *opaque)
+void vmstate_unregister(DeviceState *dev, const VMStateDescription *vmsd,
+ void *opaque)
{
SaveStateEntry *se, *new_se;
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 3c785cd..82fd9b4 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -232,7 +232,8 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
slirp->opaque = opaque;
- register_savevm("slirp", 0, 3, slirp_state_save, slirp_state_load, slirp);
+ register_savevm(NULL, "slirp", 0, 3,
+ slirp_state_save, slirp_state_load, slirp);
QTAILQ_INSERT_TAIL(&slirp_instances, slirp, entry);
@@ -243,7 +244,7 @@ void slirp_cleanup(Slirp *slirp)
{
QTAILQ_REMOVE(&slirp_instances, slirp, entry);
- unregister_savevm("slirp", slirp);
+ unregister_savevm(NULL, "slirp", slirp);
qemu_free(slirp->tftp_prefix);
qemu_free(slirp->bootp_filename);
diff --git a/vl.c b/vl.c
index 3d7ce52..405d8ba 100644
--- a/vl.c
+++ b/vl.c
@@ -3644,7 +3644,7 @@ int main(int argc, char **argv, char **envp)
if (qemu_opts_foreach(&qemu_drive_opts, drive_init_func, machine, 1) != 0)
exit(1);
- register_savevm_live("ram", 0, 3, NULL, ram_save_live, NULL,
+ register_savevm_live(NULL, "ram", 0, 3, NULL, ram_save_live, NULL,
ram_load, NULL);
if (nb_numa_nodes > 0) {
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [Qemu-devel] [RFC PATCH 2/5] savevm: Add DeviceState param
@ 2010-06-14 5:51 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: chrisw, kvm, paul, alex.williamson, kraxel, avi
We want to be able to extract a qdev device hierarchy path to match
savevm data between source and destination for a migration. This adds
a DeviceState param to callers and callees so we can make that happen.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
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 | 4 ++--
hw/eeprom93xx.c | 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.c | 4 ++--
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 | 4 ++--
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 | 23 ++++++++++++++---------
slirp/slirp.c | 5 +++--
vl.c | 2 +-
88 files changed, 159 insertions(+), 139 deletions(-)
diff --git a/audio/audio.c b/audio/audio.c
index dbf0b96..ad51077 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1901,7 +1901,7 @@ static void audio_init (void)
}
QLIST_INIT (&s->card_head);
- vmstate_register (0, &vmstate_audio, s);
+ vmstate_register (NULL, 0, &vmstate_audio, s);
}
void AUD_register_card (const char *name, QEMUSoundCard *card)
diff --git a/block-migration.c b/block-migration.c
index 7d04d6d..5964291 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -638,6 +638,6 @@ void blk_mig_init(void)
QSIMPLEQ_INIT(&block_mig_state.bmds_list);
QSIMPLEQ_INIT(&block_mig_state.blk_list);
- register_savevm_live("block", 0, 1, block_set_params, block_save_live,
+ register_savevm_live(NULL, "block", 0, 1, block_set_params, block_save_live,
NULL, block_load, &block_mig_state);
}
diff --git a/exec.c b/exec.c
index 7f64384..b56b827 100644
--- a/exec.c
+++ b/exec.c
@@ -641,8 +641,8 @@ void cpu_exec_init(CPUState *env)
cpu_list_unlock();
#endif
#if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY)
- vmstate_register(cpu_index, &vmstate_cpu_common, env);
- register_savevm("cpu", cpu_index, CPU_SAVE_VERSION,
+ vmstate_register(NULL, cpu_index, &vmstate_cpu_common, env);
+ register_savevm(NULL, "cpu", cpu_index, CPU_SAVE_VERSION,
cpu_save, cpu_load, env);
#endif
}
diff --git a/hw/adb.c b/hw/adb.c
index 4fb7a62..99b30f6 100644
--- a/hw/adb.c
+++ b/hw/adb.c
@@ -305,7 +305,7 @@ void adb_kbd_init(ADBBusState *bus)
d = adb_register_device(bus, ADB_KEYBOARD, adb_kbd_request,
adb_kbd_reset, s);
qemu_add_kbd_event_handler(adb_kbd_put_keycode, d);
- register_savevm("adb_kbd", -1, 1, adb_kbd_save,
+ register_savevm(NULL, "adb_kbd", -1, 1, adb_kbd_save,
adb_kbd_load, s);
}
@@ -475,6 +475,6 @@ void adb_mouse_init(ADBBusState *bus)
d = adb_register_device(bus, ADB_MOUSE, adb_mouse_request,
adb_mouse_reset, s);
qemu_add_mouse_event_handler(adb_mouse_event, d, 0, "QEMU ADB Mouse");
- register_savevm("adb_mouse", -1, 1, adb_mouse_save,
+ register_savevm(NULL, "adb_mouse", -1, 1, adb_mouse_save,
adb_mouse_load, s);
}
diff --git a/hw/ads7846.c b/hw/ads7846.c
index 184b3dd..b3bbeaf 100644
--- a/hw/ads7846.c
+++ b/hw/ads7846.c
@@ -151,7 +151,7 @@ static int ads7846_init(SSISlave *dev)
ads7846_int_update(s);
- register_savevm("ads7846", -1, 0, ads7846_save, ads7846_load, s);
+ register_savevm(NULL, "ads7846", -1, 0, ads7846_save, ads7846_load, s);
return 0;
}
diff --git a/hw/apic.c b/hw/apic.c
index 7fbd79b..5c0268d 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -1011,7 +1011,7 @@ int apic_init(CPUState *env)
}
s->timer = qemu_new_timer(vm_clock, apic_timer, s);
- vmstate_register(s->idx, &vmstate_apic, s);
+ vmstate_register(NULL, s->idx, &vmstate_apic, s);
qemu_register_reset(apic_reset, s);
local_apics[s->idx] = s;
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index c4afc6a..8286a28 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -744,5 +744,5 @@ static void gic_init(gic_state *s)
s->iomemtype = cpu_register_io_memory(gic_dist_readfn,
gic_dist_writefn, s);
gic_reset(s);
- register_savevm("arm_gic", -1, 1, gic_save, gic_load, s);
+ register_savevm(NULL, "arm_gic", -1, 1, gic_save, gic_load, s);
}
diff --git a/hw/arm_timer.c b/hw/arm_timer.c
index 9073ffc..f009e9e 100644
--- a/hw/arm_timer.c
+++ b/hw/arm_timer.c
@@ -174,7 +174,7 @@ static arm_timer_state *arm_timer_init(uint32_t freq)
bh = qemu_bh_new(arm_timer_tick, s);
s->timer = ptimer_init(bh);
- register_savevm("arm_timer", -1, 1, arm_timer_save, arm_timer_load, s);
+ register_savevm(NULL, "arm_timer", -1, 1, arm_timer_save, arm_timer_load, s);
return s;
}
@@ -271,7 +271,7 @@ static int sp804_init(SysBusDevice *dev)
iomemtype = cpu_register_io_memory(sp804_readfn,
sp804_writefn, s);
sysbus_init_mmio(dev, 0x1000, iomemtype);
- register_savevm("sp804", -1, 1, sp804_save, sp804_load, s);
+ register_savevm(&dev->qdev, "sp804", -1, 1, sp804_save, sp804_load, s);
return 0;
}
diff --git a/hw/armv7m_nvic.c b/hw/armv7m_nvic.c
index 9f09ef4..6c7ce01 100644
--- a/hw/armv7m_nvic.c
+++ b/hw/armv7m_nvic.c
@@ -397,7 +397,7 @@ static int armv7m_nvic_init(SysBusDevice *dev)
gic_init(&s->gic);
cpu_register_physical_memory(0xe000e000, 0x1000, s->gic.iomemtype);
s->systick.timer = qemu_new_timer(vm_clock, systick_timer_tick, s);
- register_savevm("armv7m_nvic", -1, 1, nvic_save, nvic_load, s);
+ register_savevm(&dev->qdev, "armv7m_nvic", -1, 1, nvic_save, nvic_load, s);
return 0;
}
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index ba48289..bbd4b08 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3128,7 +3128,7 @@ void isa_cirrus_vga_init(void)
s->vga.ds = graphic_console_init(s->vga.update, s->vga.invalidate,
s->vga.screen_dump, s->vga.text_update,
&s->vga);
- vmstate_register(0, &vmstate_cirrus_vga, s);
+ vmstate_register(NULL, 0, &vmstate_cirrus_vga, s);
rom_add_vga(VGABIOS_CIRRUS_FILENAME);
/* XXX ISA-LFB support */
}
diff --git a/hw/cuda.c b/hw/cuda.c
index 50950d9..3f238b6 100644
--- a/hw/cuda.c
+++ b/hw/cuda.c
@@ -763,6 +763,6 @@ void cuda_init (int *cuda_mem_index, qemu_irq irq)
s->adb_poll_timer = qemu_new_timer(vm_clock, cuda_adb_poll, s);
*cuda_mem_index = cpu_register_io_memory(cuda_read, cuda_write, s);
- register_savevm("cuda", -1, 1, cuda_save, cuda_load, s);
+ register_savevm(NULL, "cuda", -1, 1, cuda_save, cuda_load, s);
qemu_register_reset(cuda_reset, s);
}
diff --git a/hw/dma.c b/hw/dma.c
index 5b21521..8a7302a 100644
--- a/hw/dma.c
+++ b/hw/dma.c
@@ -548,8 +548,8 @@ void DMA_init(int high_page_enable, qemu_irq *cpu_request_exit)
high_page_enable ? 0x480 : -1, cpu_request_exit);
dma_init2(&dma_controllers[1], 0xc0, 1, 0x88,
high_page_enable ? 0x488 : -1, cpu_request_exit);
- vmstate_register (0, &vmstate_dma, &dma_controllers[0]);
- vmstate_register (1, &vmstate_dma, &dma_controllers[1]);
+ vmstate_register (NULL, 0, &vmstate_dma, &dma_controllers[0]);
+ vmstate_register (NULL, 1, &vmstate_dma, &dma_controllers[1]);
dma_bh = qemu_bh_new(DMA_run_bh, NULL);
}
diff --git a/hw/eepro100.c b/hw/eepro100.c
index a74d834..92cfea7 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1835,7 +1835,7 @@ static int pci_nic_uninit(PCIDevice *pci_dev)
EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
cpu_unregister_io_memory(s->mmio_index);
- vmstate_unregister(s->vmstate, s);
+ vmstate_unregister(&pci_dev->qdev, s->vmstate, s);
eeprom93xx_free(s->eeprom);
qemu_del_vlan_client(&s->nic->nc);
return 0;
@@ -1894,7 +1894,7 @@ static int e100_nic_init(PCIDevice *pci_dev)
s->vmstate = qemu_malloc(sizeof(vmstate_eepro100));
memcpy(s->vmstate, &vmstate_eepro100, sizeof(vmstate_eepro100));
s->vmstate->name = s->nic->nc.model;
- vmstate_register(-1, s->vmstate, s);
+ vmstate_register(&pci_dev->qdev, -1, s->vmstate, s);
return 0;
}
diff --git a/hw/eeprom93xx.c b/hw/eeprom93xx.c
index 30a3534..6ba546f 100644
--- a/hw/eeprom93xx.c
+++ b/hw/eeprom93xx.c
@@ -316,7 +316,7 @@ eeprom_t *eeprom93xx_new(uint16_t nwords)
/* Output DO is tristate, read results in 1. */
eeprom->eedo = 1;
logout("eeprom = 0x%p, nwords = %u\n", eeprom, nwords);
- vmstate_register(0, &vmstate_eeprom, eeprom);
+ vmstate_register(NULL, 0, &vmstate_eeprom, eeprom);
return eeprom;
}
@@ -324,7 +324,7 @@ void eeprom93xx_free(eeprom_t *eeprom)
{
/* Destroy EEPROM. */
logout("eeprom = 0x%p\n", eeprom);
- vmstate_unregister(&vmstate_eeprom, eeprom);
+ vmstate_unregister(NULL, &vmstate_eeprom, eeprom);
qemu_free(eeprom);
}
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 22ebb50..ca8c538 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -352,7 +352,7 @@ FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
fw_cfg_add_i16(s, FW_CFG_MAX_CPUS, (uint16_t)max_cpus);
fw_cfg_add_i16(s, FW_CFG_BOOT_MENU, (uint16_t)boot_menu);
- vmstate_register(-1, &vmstate_fw_cfg, s);
+ vmstate_register(NULL, -1, &vmstate_fw_cfg, s);
qemu_register_reset(fw_cfg_reset, s);
return s;
diff --git a/hw/g364fb.c b/hw/g364fb.c
index d1d2c12..beafd70 100644
--- a/hw/g364fb.c
+++ b/hw/g364fb.c
@@ -598,7 +598,7 @@ int g364fb_mm_init(target_phys_addr_t vram_base,
s->irq = irq;
qemu_register_reset(g364fb_reset, s);
- register_savevm("g364fb", 0, 1, g364fb_save, g364fb_load, s);
+ register_savevm(NULL, "g364fb", 0, 1, g364fb_save, g364fb_load, s);
g364fb_reset(s);
s->ds = graphic_console_init(g364fb_update_display,
diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index aa0c51b..0cf29dc 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -113,8 +113,8 @@ static int pci_grackle_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
- register_savevm("grackle", 0, 1, pci_grackle_save, pci_grackle_load,
- &s->host_state);
+ register_savevm(&dev->qdev, "grackle", 0, 1, pci_grackle_save,
+ pci_grackle_load, &s->host_state);
qemu_register_reset(pci_grackle_reset, &s->host_state);
return 0;
}
diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c
index 7691e1d..313c080 100644
--- a/hw/gt64xxx.c
+++ b/hw/gt64xxx.c
@@ -1146,7 +1146,8 @@ PCIBus *pci_gt64120_init(qemu_irq *pic)
gt64120_reset(s);
- register_savevm("GT64120 PCI Bus", 0, 1, gt64120_save, gt64120_load, d);
+ register_savevm(&d->qdev, "GT64120 PCI Bus", 0, 1,
+ gt64120_save, gt64120_load, d);
return s->pci->bus;
}
diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
index 5e27021..cd86121 100644
--- a/hw/heathrow_pic.c
+++ b/hw/heathrow_pic.c
@@ -224,7 +224,7 @@ qemu_irq *heathrow_pic_init(int *pmem_index,
s->irqs = irqs[0];
*pmem_index = cpu_register_io_memory(pic_read, pic_write, s);
- register_savevm("heathrow_pic", -1, 1, heathrow_pic_save,
+ register_savevm(NULL, "heathrow_pic", -1, 1, heathrow_pic_save,
heathrow_pic_load, s);
qemu_register_reset(heathrow_pic_reset, s);
return qemu_allocate_irqs(heathrow_pic_set_irq, s, 64);
diff --git a/hw/hpet.c b/hw/hpet.c
index 8729fb2..b2a48bb 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -577,7 +577,7 @@ void hpet_init(qemu_irq *irq) {
HPETTimer *timer = &s->timer[i];
timer->qemu_timer = qemu_new_timer(vm_clock, hpet_timer, timer);
}
- vmstate_register(-1, &vmstate_hpet, s);
+ vmstate_register(NULL, -1, &vmstate_hpet, s);
qemu_register_reset(hpet_reset, s);
/* HPET Area */
iomemtype = cpu_register_io_memory(hpet_ram_read,
diff --git a/hw/hw.h b/hw/hw.h
index fc2d184..f7b2406 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -246,14 +246,16 @@ typedef int SaveLiveStateHandler(Monitor *mon, QEMUFile *f, int stage,
void *opaque);
typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id);
-int register_savevm(const char *idstr,
+int register_savevm(DeviceState *dev,
+ const char *idstr,
int instance_id,
int version_id,
SaveStateHandler *save_state,
LoadStateHandler *load_state,
void *opaque);
-int register_savevm_live(const char *idstr,
+int register_savevm_live(DeviceState *dev,
+ const char *idstr,
int instance_id,
int version_id,
SaveSetParamsHandler *set_params,
@@ -262,7 +264,7 @@ int register_savevm_live(const char *idstr,
LoadStateHandler *load_state,
void *opaque);
-void unregister_savevm(const char *idstr, void *opaque);
+void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque);
typedef void QEMUResetHandler(void *opaque);
@@ -756,11 +758,13 @@ extern int vmstate_load_state(QEMUFile *f, const VMStateDescription *vmsd,
void *opaque, int version_id);
extern void vmstate_save_state(QEMUFile *f, const VMStateDescription *vmsd,
void *opaque);
-extern int vmstate_register(int instance_id, const VMStateDescription *vmsd,
- void *base);
-extern int vmstate_register_with_alias_id(int instance_id,
+extern int vmstate_register(DeviceState *dev, int instance_id,
+ const VMStateDescription *vmsd, void *base);
+extern int vmstate_register_with_alias_id(DeviceState *dev,
+ int instance_id,
const VMStateDescription *vmsd,
void *base, int alias_id,
int required_for_version);
-void vmstate_unregister(const VMStateDescription *vmsd, void *opaque);
+void vmstate_unregister(DeviceState *dev, const VMStateDescription *vmsd,
+ void *opaque);
#endif
diff --git a/hw/i2c.c b/hw/i2c.c
index bee8e88..f80d12d 100644
--- a/hw/i2c.c
+++ b/hw/i2c.c
@@ -62,7 +62,7 @@ i2c_bus *i2c_init_bus(DeviceState *parent, const char *name)
i2c_bus *bus;
bus = FROM_QBUS(i2c_bus, qbus_create(&i2c_bus_info, parent, name));
- vmstate_register(-1, &vmstate_i2c_bus, bus);
+ vmstate_register(NULL, -1, &vmstate_i2c_bus, bus);
return bus;
}
diff --git a/hw/i8254.c b/hw/i8254.c
index faaa884..06b225c 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
@@ -508,7 +508,7 @@ PITState *pit_init(int base, qemu_irq irq)
s->irq_timer = qemu_new_timer(vm_clock, pit_irq_timer, s);
s->irq = irq;
- vmstate_register(base, &vmstate_pit, pit);
+ vmstate_register(NULL, base, &vmstate_pit, pit);
qemu_register_reset(pit_reset, pit);
register_ioport_write(base, 4, 1, pit_ioport_write, pit);
register_ioport_read(base, 3, 1, pit_ioport_read, pit);
diff --git a/hw/i8259.c b/hw/i8259.c
index a995280..a8dbee6 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -483,7 +483,7 @@ static void pic_init1(int io_addr, int elcr_addr, PicState *s)
register_ioport_write(elcr_addr, 1, 1, elcr_ioport_write, s);
register_ioport_read(elcr_addr, 1, 1, elcr_ioport_read, s);
}
- vmstate_register(io_addr, &vmstate_pic, s);
+ vmstate_register(NULL, io_addr, &vmstate_pic, s);
qemu_register_reset(pic_reset, s);
}
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index cdcc9bf..aff8655 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -263,7 +263,7 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
ide_init2(&d->bus[0], NULL, NULL, irq[0]);
ide_init2(&d->bus[1], NULL, NULL, irq[1]);
- vmstate_register(0, &vmstate_ide_pci, d);
+ vmstate_register(&dev->qdev, 0, &vmstate_ide_pci, d);
qemu_register_reset(cmd646_reset, d);
return 0;
}
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index dff7c79..f1d220b 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -71,7 +71,7 @@ static int isa_ide_initfn(ISADevice *dev)
ide_init_ioport(&s->bus, s->iobase, s->iobase2);
isa_init_irq(dev, &s->irq, s->isairq);
ide_init2(&s->bus, NULL, NULL, s->irq);
- vmstate_register(0, &vmstate_ide_isa, s);
+ vmstate_register(&dev->qdev, 0, &vmstate_ide_isa, s);
return 0;
};
diff --git a/hw/ide/macio.c b/hw/ide/macio.c
index 639f3f6..2574942 100644
--- a/hw/ide/macio.c
+++ b/hw/ide/macio.c
@@ -321,7 +321,7 @@ int pmac_ide_init (DriveInfo **hd_table, qemu_irq irq,
pmac_ide_memory = cpu_register_io_memory(pmac_ide_read,
pmac_ide_write, d);
- vmstate_register(0, &vmstate_pmac, d);
+ vmstate_register(NULL, 0, &vmstate_pmac, d);
qemu_register_reset(pmac_ide_reset, d);
return pmac_ide_memory;
diff --git a/hw/ide/microdrive.c b/hw/ide/microdrive.c
index bfdb8c8..30c8aa4 100644
--- a/hw/ide/microdrive.c
+++ b/hw/ide/microdrive.c
@@ -544,7 +544,7 @@ PCMCIACardState *dscm1xxxx_init(DriveInfo *bdrv)
md->bus.ifs[0].mdata_size = METADATA_SIZE;
md->bus.ifs[0].mdata_storage = (uint8_t *) qemu_mallocz(METADATA_SIZE);
- vmstate_register(-1, &vmstate_microdrive, md);
+ vmstate_register(NULL, -1, &vmstate_microdrive, md);
return &md->card;
}
diff --git a/hw/ide/mmio.c b/hw/ide/mmio.c
index cca883f..5909f21 100644
--- a/hw/ide/mmio.c
+++ b/hw/ide/mmio.c
@@ -133,7 +133,7 @@ void mmio_ide_init (target_phys_addr_t membase, target_phys_addr_t membase2,
mem2 = cpu_register_io_memory(mmio_ide_status, mmio_ide_cmd, s);
cpu_register_physical_memory(membase, 16 << shift, mem1);
cpu_register_physical_memory(membase2, 2 << shift, mem2);
- vmstate_register(0, &vmstate_ide_mmio, s);
+ vmstate_register(NULL, 0, &vmstate_ide_mmio, s);
qemu_register_reset(mmio_ide_reset, s);
}
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 4fa3851..431a9ea 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -128,7 +128,7 @@ static int pci_piix_ide_initfn(PCIIDEState *d)
pci_register_bar(&d->dev, 4, 0x10, PCI_BASE_ADDRESS_SPACE_IO, bmdma_map);
- vmstate_register(0, &vmstate_ide_pci, d);
+ vmstate_register(&d->dev.qdev, 0, &vmstate_ide_pci, d);
ide_bus_new(&d->bus[0], &d->dev.qdev);
ide_bus_new(&d->bus[1], &d->dev.qdev);
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 335da6e..2670113 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -244,7 +244,7 @@ qemu_irq *ioapic_init(void)
ioapic_mem_write, s);
cpu_register_physical_memory(0xfec00000, 0x1000, io_memory);
- vmstate_register(0, &vmstate_ioapic, s);
+ vmstate_register(NULL, 0, &vmstate_ioapic, s);
qemu_register_reset(ioapic_reset, s);
irq = qemu_allocate_irqs(ioapic_set_irq, s, IOAPIC_NUM_PINS);
diff --git a/hw/m48t59.c b/hw/m48t59.c
index c3d7b3a..c7492a6 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -694,7 +694,7 @@ static void m48t59_init_common(M48t59State *s)
}
qemu_get_timedate(&s->alarm, 0);
- register_savevm("m48t59", -1, 1, m48t59_save, m48t59_load, s);
+ register_savevm(NULL, "m48t59", -1, 1, m48t59_save, m48t59_load, s);
}
static int m48t59_init_isa1(ISADevice *dev)
diff --git a/hw/mac_dbdma.c b/hw/mac_dbdma.c
index e2697d3..03d2d16 100644
--- a/hw/mac_dbdma.c
+++ b/hw/mac_dbdma.c
@@ -845,7 +845,7 @@ void* DBDMA_init (int *dbdma_mem_index)
s = qemu_mallocz(sizeof(DBDMA_channel) * DBDMA_CHANNELS);
*dbdma_mem_index = cpu_register_io_memory(dbdma_read, dbdma_write, s);
- register_savevm("dbdma", -1, 1, dbdma_save, dbdma_load, s);
+ register_savevm(NULL, "dbdma", -1, 1, dbdma_save, dbdma_load, s);
qemu_register_reset(dbdma_reset, s);
dbdma_bh = qemu_bh_new(DBDMA_run_bh, s);
diff --git a/hw/mac_nvram.c b/hw/mac_nvram.c
index f28db6b..a834935 100644
--- a/hw/mac_nvram.c
+++ b/hw/mac_nvram.c
@@ -140,7 +140,7 @@ MacIONVRAMState *macio_nvram_init (int *mem_index, target_phys_addr_t size,
s->mem_index = cpu_register_io_memory(nvram_read, nvram_write, s);
*mem_index = s->mem_index;
- register_savevm("macio_nvram", -1, 1, macio_nvram_save, macio_nvram_load,
+ register_savevm(NULL, "macio_nvram", -1, 1, macio_nvram_save, macio_nvram_load,
s);
qemu_register_reset(macio_nvram_reset, s);
diff --git a/hw/max111x.c b/hw/max111x.c
index bd656bb..2844665 100644
--- a/hw/max111x.c
+++ b/hw/max111x.c
@@ -143,7 +143,8 @@ static int max111x_init(SSISlave *dev, int inputs)
s->input[7] = 0x80;
s->com = 0;
- register_savevm("max111x", -1, 0, max111x_save, max111x_load, s);
+ register_savevm(&dev->qdev, "max111x", -1, 0,
+ max111x_save, max111x_load, s);
return 0;
}
diff --git a/hw/mipsnet.c b/hw/mipsnet.c
index a066f63..a95b3ce 100644
--- a/hw/mipsnet.c
+++ b/hw/mipsnet.c
@@ -239,7 +239,7 @@ static void mipsnet_cleanup(VLANClientState *nc)
{
MIPSnetState *s = DO_UPCAST(NICState, nc, nc)->opaque;
- unregister_savevm("mipsnet", s);
+ unregister_savevm(NULL, "mipsnet", s);
isa_unassign_ioport(s->io_base, 36);
@@ -284,5 +284,5 @@ void mipsnet_init (int base, qemu_irq irq, NICInfo *nd)
}
mipsnet_reset(s);
- register_savevm("mipsnet", 0, 0, mipsnet_save, mipsnet_load, s);
+ register_savevm(NULL, "mipsnet", 0, 0, mipsnet_save, mipsnet_load, s);
}
diff --git a/hw/mst_fpga.c b/hw/mst_fpga.c
index 1b6cb77..53c3610 100644
--- a/hw/mst_fpga.c
+++ b/hw/mst_fpga.c
@@ -234,6 +234,6 @@ qemu_irq *mst_irq_init(PXA2xxState *cpu, uint32_t base, int irq)
iomemtype = cpu_register_io_memory(mst_fpga_readfn,
mst_fpga_writefn, s);
cpu_register_physical_memory(base, 0x00100000, iomemtype);
- register_savevm("mainstone_fpga", 0, 0, mst_fpga_save, mst_fpga_load, s);
+ register_savevm(NULL, "mainstone_fpga", 0, 0, mst_fpga_save, mst_fpga_load, s);
return qi;
}
diff --git a/hw/nand.c b/hw/nand.c
index 40d5a6a..bc0ee98 100644
--- a/hw/nand.c
+++ b/hw/nand.c
@@ -503,7 +503,7 @@ NANDFlashState *nand_init(int manf_id, int chip_id)
is used. */
s->ioaddr = s->io;
- register_savevm("nand", -1, 0, nand_save, nand_load, s);
+ register_savevm(NULL, "nand", -1, 0, nand_save, nand_load, s);
return s;
}
diff --git a/hw/openpic.c b/hw/openpic.c
index ac21993..2b4cb00 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -1234,7 +1234,8 @@ qemu_irq *openpic_init (PCIBus *bus, int *pmem_index, int nb_cpus,
opp->irq_out = irq_out;
opp->need_swap = 1;
- register_savevm("openpic", 0, 2, openpic_save, openpic_load, opp);
+ register_savevm(&opp->pci_dev.qdev, "openpic", 0, 2,
+ openpic_save, openpic_load, opp);
qemu_register_reset(openpic_reset, opp);
opp->irq_raise = openpic_irq_raise;
@@ -1692,7 +1693,7 @@ qemu_irq *mpic_init (target_phys_addr_t base, int nb_cpus,
mpp->irq_raise = mpic_irq_raise;
mpp->reset = mpic_reset;
- register_savevm("mpic", 0, 2, openpic_save, openpic_load, mpp);
+ register_savevm(NULL, "mpic", 0, 2, openpic_save, openpic_load, mpp);
qemu_register_reset(mpic_reset, mpp);
return qemu_allocate_irqs(openpic_set_irq, mpp, mpp->max_irq);
diff --git a/hw/pci.c b/hw/pci.c
index cbbd1dd..e81cb30 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -230,7 +230,7 @@ void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent,
QLIST_INIT(&bus->child);
pci_host_bus_register(0, bus); /* for now only pci domain 0 is supported */
- vmstate_register(-1, &vmstate_pcibus, bus);
+ vmstate_register(NULL, -1, &vmstate_pcibus, bus);
qemu_register_reset(pci_bus_reset, bus);
}
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 3812284..0533b1d 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -418,7 +418,7 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
s->irq_mouse = mouse_irq;
s->mask = mask;
- vmstate_register(0, &vmstate_kbd, s);
+ vmstate_register(NULL, 0, &vmstate_kbd, s);
s_io_memory = cpu_register_io_memory(kbd_mm_read, kbd_mm_write, s);
cpu_register_physical_memory(base, size, s_io_memory);
diff --git a/hw/piix4.c b/hw/piix4.c
index f75951b..6f08c5a 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -87,7 +87,7 @@ static int piix4_initfn(PCIDevice *d)
uint8_t *pci_conf;
isa_bus_new(&d->qdev);
- register_savevm("PIIX4", 0, 2, piix_save, piix_load, d);
+ register_savevm(&d->qdev, "PIIX4", 0, 2, piix_save, piix_load, d);
pci_conf = d->config;
pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_INTEL);
diff --git a/hw/pl011.c b/hw/pl011.c
index 81de91e..02cf84a 100644
--- a/hw/pl011.c
+++ b/hw/pl011.c
@@ -306,7 +306,7 @@ static int pl011_init(SysBusDevice *dev, const unsigned char *id)
qemu_chr_add_handlers(s->chr, pl011_can_receive, pl011_receive,
pl011_event, s);
}
- register_savevm("pl011_uart", -1, 1, pl011_save, pl011_load, s);
+ register_savevm(&dev->qdev, "pl011_uart", -1, 1, pl011_save, pl011_load, s);
return 0;
}
diff --git a/hw/pl022.c b/hw/pl022.c
index c2e2dda..d7862bc 100644
--- a/hw/pl022.c
+++ b/hw/pl022.c
@@ -299,7 +299,7 @@ static int pl022_init(SysBusDevice *dev)
sysbus_init_irq(dev, &s->irq);
s->ssi = ssi_create_bus(&dev->qdev, "ssi");
pl022_reset(s);
- register_savevm("pl022_ssp", -1, 1, pl022_save, pl022_load, s);
+ register_savevm(&dev->qdev, "pl022_ssp", -1, 1, pl022_save, pl022_load, s);
return 0;
}
diff --git a/hw/pl061.c b/hw/pl061.c
index 7b1b636..e4505f5 100644
--- a/hw/pl061.c
+++ b/hw/pl061.c
@@ -303,7 +303,7 @@ static int pl061_init(SysBusDevice *dev)
qdev_init_gpio_in(&dev->qdev, pl061_set_irq, 8);
qdev_init_gpio_out(&dev->qdev, s->out, 8);
pl061_reset(s);
- register_savevm("pl061_gpio", -1, 1, pl061_save, pl061_load, s);
+ register_savevm(&dev->qdev, "pl061_gpio", -1, 1, pl061_save, pl061_load, s);
return 0;
}
diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c
index c9e3279..6e437e7 100644
--- a/hw/ppc4xx_pci.c
+++ b/hw/ppc4xx_pci.c
@@ -392,8 +392,8 @@ PCIBus *ppc4xx_pci_init(CPUState *env, qemu_irq pci_irqs[4],
qemu_register_reset(ppc4xx_pci_reset, controller);
/* XXX load/save code not tested. */
- register_savevm("ppc4xx_pci", ppc4xx_pci_id++, 1,
- ppc4xx_pci_save, ppc4xx_pci_load, controller);
+ register_savevm(&controller->pci_dev->qdev, "ppc4xx_pci", ppc4xx_pci_id++,
+ 1, ppc4xx_pci_save, ppc4xx_pci_load, controller);
return controller->pci_state.bus;
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index 336d284..5358f82 100644
--- a/hw/ppce500_pci.c
+++ b/hw/ppce500_pci.c
@@ -310,8 +310,8 @@ PCIBus *ppce500_pci_init(qemu_irq pci_irqs[4], target_phys_addr_t registers)
PCIE500_REG_SIZE, index);
/* XXX load/save code not tested. */
- register_savevm("ppce500_pci", ppce500_pci_id++, 1,
- ppce500_pci_save, ppce500_pci_load, controller);
+ register_savevm(&d->qdev, "ppce500_pci", ppce500_pci_id++,
+ 1, ppce500_pci_save, ppce500_pci_load, controller);
return controller->pci_state.bus;
diff --git a/hw/ps2.c b/hw/ps2.c
index f0b206a..762bb00 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -595,7 +595,7 @@ void *ps2_kbd_init(void (*update_irq)(void *, int), void *update_arg)
s->common.update_irq = update_irq;
s->common.update_arg = update_arg;
s->scancode_set = 2;
- vmstate_register(0, &vmstate_ps2_keyboard, s);
+ vmstate_register(NULL, 0, &vmstate_ps2_keyboard, s);
qemu_add_kbd_event_handler(ps2_put_keycode, s);
qemu_register_reset(ps2_kbd_reset, s);
return s;
@@ -607,7 +607,7 @@ void *ps2_mouse_init(void (*update_irq)(void *, int), void *update_arg)
s->common.update_irq = update_irq;
s->common.update_arg = update_arg;
- vmstate_register(0, &vmstate_ps2_mouse, s);
+ vmstate_register(NULL, 0, &vmstate_ps2_mouse, s);
qemu_add_mouse_event_handler(ps2_mouse_event, s, 0, "QEMU PS/2 Mouse");
qemu_register_reset(ps2_mouse_reset, s);
return s;
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
index 9095386..2ea363c 100644
--- a/hw/pxa2xx.c
+++ b/hw/pxa2xx.c
@@ -860,7 +860,7 @@ static int pxa2xx_ssp_init(SysBusDevice *dev)
iomemtype = cpu_register_io_memory(pxa2xx_ssp_readfn,
pxa2xx_ssp_writefn, s);
sysbus_init_mmio(dev, 0x1000, iomemtype);
- register_savevm("pxa2xx_ssp", -1, 0,
+ register_savevm(&dev->qdev, "pxa2xx_ssp", -1, 0,
pxa2xx_ssp_save, pxa2xx_ssp_load, s);
s->bus = ssi_create_bus(&dev->qdev, "ssi");
@@ -1515,7 +1515,7 @@ PXA2xxI2CState *pxa2xx_i2c_init(target_phys_addr_t base,
cpu_register_physical_memory(base & ~region_size,
region_size + 1, iomemtype);
- vmstate_register(base, &vmstate_pxa2xx_i2c, s);
+ vmstate_register(NULL, base, &vmstate_pxa2xx_i2c, s);
return s;
}
@@ -1751,7 +1751,7 @@ static PXA2xxI2SState *pxa2xx_i2s_init(target_phys_addr_t base,
pxa2xx_i2s_writefn, s);
cpu_register_physical_memory(base, 0x100000, iomemtype);
- register_savevm("pxa2xx_i2s", base, 0,
+ register_savevm(NULL, "pxa2xx_i2s", base, 0,
pxa2xx_i2s_save, pxa2xx_i2s_load, s);
return s;
@@ -2014,7 +2014,7 @@ static PXA2xxFIrState *pxa2xx_fir_init(target_phys_addr_t base,
qemu_chr_add_handlers(chr, pxa2xx_fir_is_empty,
pxa2xx_fir_rx, pxa2xx_fir_event, s);
- register_savevm("pxa2xx_fir", 0, 0, pxa2xx_fir_save, pxa2xx_fir_load, s);
+ register_savevm(NULL, "pxa2xx_fir", 0, 0, pxa2xx_fir_save, pxa2xx_fir_load, s);
return s;
}
@@ -2099,7 +2099,7 @@ PXA2xxState *pxa270_init(unsigned int sdram_size, const char *revision)
iomemtype = cpu_register_io_memory(pxa2xx_cm_readfn,
pxa2xx_cm_writefn, s);
cpu_register_physical_memory(s->cm_base, 0x1000, iomemtype);
- register_savevm("pxa2xx_cm", 0, 0, pxa2xx_cm_save, pxa2xx_cm_load, s);
+ register_savevm(NULL, "pxa2xx_cm", 0, 0, pxa2xx_cm_save, pxa2xx_cm_load, s);
cpu_arm_set_cp_io(s->env, 14, pxa2xx_cp14_read, pxa2xx_cp14_write, s);
@@ -2110,13 +2110,13 @@ PXA2xxState *pxa270_init(unsigned int sdram_size, const char *revision)
iomemtype = cpu_register_io_memory(pxa2xx_mm_readfn,
pxa2xx_mm_writefn, s);
cpu_register_physical_memory(s->mm_base, 0x1000, iomemtype);
- register_savevm("pxa2xx_mm", 0, 0, pxa2xx_mm_save, pxa2xx_mm_load, s);
+ register_savevm(NULL, "pxa2xx_mm", 0, 0, pxa2xx_mm_save, pxa2xx_mm_load, s);
s->pm_base = 0x40f00000;
iomemtype = cpu_register_io_memory(pxa2xx_pm_readfn,
pxa2xx_pm_writefn, s);
cpu_register_physical_memory(s->pm_base, 0x100, iomemtype);
- register_savevm("pxa2xx_pm", 0, 0, pxa2xx_pm_save, pxa2xx_pm_load, s);
+ register_savevm(NULL, "pxa2xx_pm", 0, 0, pxa2xx_pm_save, pxa2xx_pm_load, s);
for (i = 0; pxa27x_ssp[i].io_base; i ++);
s->ssp = (SSIBus **)qemu_mallocz(sizeof(SSIBus *) * i);
@@ -2140,7 +2140,7 @@ PXA2xxState *pxa270_init(unsigned int sdram_size, const char *revision)
pxa2xx_rtc_writefn, s);
cpu_register_physical_memory(s->rtc_base, 0x1000, iomemtype);
pxa2xx_rtc_init(s);
- register_savevm("pxa2xx_rtc", 0, 0, pxa2xx_rtc_save, pxa2xx_rtc_load, s);
+ register_savevm(NULL, "pxa2xx_rtc", 0, 0, pxa2xx_rtc_save, pxa2xx_rtc_load, s);
s->i2c[0] = pxa2xx_i2c_init(0x40301600, s->pic[PXA2XX_PIC_I2C], 0xffff);
s->i2c[1] = pxa2xx_i2c_init(0x40f00100, s->pic[PXA2XX_PIC_PWRI2C], 0xff);
@@ -2219,7 +2219,7 @@ PXA2xxState *pxa255_init(unsigned int sdram_size)
iomemtype = cpu_register_io_memory(pxa2xx_cm_readfn,
pxa2xx_cm_writefn, s);
cpu_register_physical_memory(s->cm_base, 0x1000, iomemtype);
- register_savevm("pxa2xx_cm", 0, 0, pxa2xx_cm_save, pxa2xx_cm_load, s);
+ register_savevm(NULL, "pxa2xx_cm", 0, 0, pxa2xx_cm_save, pxa2xx_cm_load, s);
cpu_arm_set_cp_io(s->env, 14, pxa2xx_cp14_read, pxa2xx_cp14_write, s);
@@ -2230,13 +2230,13 @@ PXA2xxState *pxa255_init(unsigned int sdram_size)
iomemtype = cpu_register_io_memory(pxa2xx_mm_readfn,
pxa2xx_mm_writefn, s);
cpu_register_physical_memory(s->mm_base, 0x1000, iomemtype);
- register_savevm("pxa2xx_mm", 0, 0, pxa2xx_mm_save, pxa2xx_mm_load, s);
+ register_savevm(NULL, "pxa2xx_mm", 0, 0, pxa2xx_mm_save, pxa2xx_mm_load, s);
s->pm_base = 0x40f00000;
iomemtype = cpu_register_io_memory(pxa2xx_pm_readfn,
pxa2xx_pm_writefn, s);
cpu_register_physical_memory(s->pm_base, 0x100, iomemtype);
- register_savevm("pxa2xx_pm", 0, 0, pxa2xx_pm_save, pxa2xx_pm_load, s);
+ register_savevm(NULL, "pxa2xx_pm", 0, 0, pxa2xx_pm_save, pxa2xx_pm_load, s);
for (i = 0; pxa255_ssp[i].io_base; i ++);
s->ssp = (SSIBus **)qemu_mallocz(sizeof(SSIBus *) * i);
@@ -2260,7 +2260,7 @@ PXA2xxState *pxa255_init(unsigned int sdram_size)
pxa2xx_rtc_writefn, s);
cpu_register_physical_memory(s->rtc_base, 0x1000, iomemtype);
pxa2xx_rtc_init(s);
- register_savevm("pxa2xx_rtc", 0, 0, pxa2xx_rtc_save, pxa2xx_rtc_load, s);
+ register_savevm(NULL, "pxa2xx_rtc", 0, 0, pxa2xx_rtc_save, pxa2xx_rtc_load, s);
s->i2c[0] = pxa2xx_i2c_init(0x40301600, s->pic[PXA2XX_PIC_I2C], 0xffff);
s->i2c[1] = pxa2xx_i2c_init(0x40f00100, s->pic[PXA2XX_PIC_PWRI2C], 0xff);
diff --git a/hw/pxa2xx_dma.c b/hw/pxa2xx_dma.c
index 66c2c30..9c479df 100644
--- a/hw/pxa2xx_dma.c
+++ b/hw/pxa2xx_dma.c
@@ -507,7 +507,7 @@ static PXA2xxDMAState *pxa2xx_dma_init(target_phys_addr_t base,
pxa2xx_dma_writefn, s);
cpu_register_physical_memory(base, 0x00010000, iomemtype);
- register_savevm("pxa2xx_dma", 0, 0, pxa2xx_dma_save, pxa2xx_dma_load, s);
+ register_savevm(NULL, "pxa2xx_dma", 0, 0, pxa2xx_dma_save, pxa2xx_dma_load, s);
return s;
}
diff --git a/hw/pxa2xx_gpio.c b/hw/pxa2xx_gpio.c
index f354f4b..2abcb65 100644
--- a/hw/pxa2xx_gpio.c
+++ b/hw/pxa2xx_gpio.c
@@ -312,7 +312,7 @@ PXA2xxGPIOInfo *pxa2xx_gpio_init(target_phys_addr_t base,
pxa2xx_gpio_writefn, s);
cpu_register_physical_memory(base, 0x00001000, iomemtype);
- register_savevm("pxa2xx_gpio", 0, 0,
+ register_savevm(NULL, "pxa2xx_gpio", 0, 0,
pxa2xx_gpio_save, pxa2xx_gpio_load, s);
return s;
diff --git a/hw/pxa2xx_keypad.c b/hw/pxa2xx_keypad.c
index 060df58..dfa8945 100644
--- a/hw/pxa2xx_keypad.c
+++ b/hw/pxa2xx_keypad.c
@@ -317,7 +317,7 @@ PXA2xxKeyPadState *pxa27x_keypad_init(target_phys_addr_t base,
pxa2xx_keypad_writefn, s);
cpu_register_physical_memory(base, 0x00100000, iomemtype);
- register_savevm("pxa2xx_keypad", 0, 0,
+ register_savevm(NULL, "pxa2xx_keypad", 0, 0,
pxa2xx_keypad_save, pxa2xx_keypad_load, s);
return s;
diff --git a/hw/pxa2xx_lcd.c b/hw/pxa2xx_lcd.c
index 930299a..111a0dc 100644
--- a/hw/pxa2xx_lcd.c
+++ b/hw/pxa2xx_lcd.c
@@ -970,7 +970,7 @@ PXA2xxLCDState *pxa2xx_lcdc_init(target_phys_addr_t base, qemu_irq irq)
exit(1);
}
- register_savevm("pxa2xx_lcdc", 0, 0,
+ register_savevm(NULL, "pxa2xx_lcdc", 0, 0,
pxa2xx_lcdc_save, pxa2xx_lcdc_load, s);
return s;
diff --git a/hw/pxa2xx_mmci.c b/hw/pxa2xx_mmci.c
index a415349..ca98660 100644
--- a/hw/pxa2xx_mmci.c
+++ b/hw/pxa2xx_mmci.c
@@ -534,7 +534,7 @@ PXA2xxMMCIState *pxa2xx_mmci_init(target_phys_addr_t base,
/* Instantiate the actual storage */
s->card = sd_init(bd, 0);
- register_savevm("pxa2xx_mmci", 0, 0,
+ register_savevm(NULL, "pxa2xx_mmci", 0, 0,
pxa2xx_mmci_save, pxa2xx_mmci_load, s);
return s;
diff --git a/hw/pxa2xx_pic.c b/hw/pxa2xx_pic.c
index 0a98342..353d885 100644
--- a/hw/pxa2xx_pic.c
+++ b/hw/pxa2xx_pic.c
@@ -306,7 +306,7 @@ qemu_irq *pxa2xx_pic_init(target_phys_addr_t base, CPUState *env)
/* Enable IC coprocessor access. */
cpu_arm_set_cp_io(env, 6, pxa2xx_pic_cp_read, pxa2xx_pic_cp_write, s);
- register_savevm("pxa2xx_pic", 0, 0, pxa2xx_pic_save, pxa2xx_pic_load, s);
+ register_savevm(NULL, "pxa2xx_pic", 0, 0, pxa2xx_pic_save, pxa2xx_pic_load, s);
return qi;
}
diff --git a/hw/pxa2xx_timer.c b/hw/pxa2xx_timer.c
index d992cc3..0f0ffd3 100644
--- a/hw/pxa2xx_timer.c
+++ b/hw/pxa2xx_timer.c
@@ -455,7 +455,7 @@ static pxa2xx_timer_info *pxa2xx_timer_init(target_phys_addr_t base,
pxa2xx_timer_writefn, s);
cpu_register_physical_memory(base, 0x00001000, iomemtype);
- register_savevm("pxa2xx_timer", 0, 0,
+ register_savevm(NULL, "pxa2xx_timer", 0, 0,
pxa2xx_timer_save, pxa2xx_timer_load, s);
return s;
diff --git a/hw/qdev.c b/hw/qdev.c
index dea44fe..a81c1e2 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -337,7 +337,7 @@ int qdev_init(DeviceState *dev)
}
qemu_register_reset(qdev_reset, dev);
if (dev->info->vmsd) {
- vmstate_register_with_alias_id(-1, dev->info->vmsd, dev,
+ vmstate_register_with_alias_id(dev, -1, dev->info->vmsd, dev,
dev->instance_id_alias,
dev->alias_required_for_version);
}
@@ -398,7 +398,7 @@ void qdev_free(DeviceState *dev)
qbus_free(bus);
}
if (dev->info->vmsd)
- vmstate_unregister(dev->info->vmsd, dev);
+ vmstate_unregister(dev, dev->info->vmsd, dev);
if (dev->info->exit)
dev->info->exit(dev);
if (dev->opts)
diff --git a/hw/rc4030.c b/hw/rc4030.c
index 2a8233a..2231373 100644
--- a/hw/rc4030.c
+++ b/hw/rc4030.c
@@ -813,7 +813,7 @@ void *rc4030_init(qemu_irq timer, qemu_irq jazz_bus,
s->jazz_bus_irq = jazz_bus;
qemu_register_reset(rc4030_reset, s);
- register_savevm("rc4030", 0, 2, rc4030_save, rc4030_load, s);
+ register_savevm(NULL, "rc4030", 0, 2, rc4030_save, rc4030_load, s);
rc4030_reset(s);
s_chipset = cpu_register_io_memory(rc4030_read, rc4030_write, s);
diff --git a/hw/serial.c b/hw/serial.c
index 9102edb..09e3489 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -812,7 +812,7 @@ SerialState *serial_init(int base, qemu_irq irq, int baudbase,
s->chr = chr;
serial_init_core(s);
- vmstate_register(base, &vmstate_serial, s);
+ vmstate_register(NULL, base, &vmstate_serial, s);
register_ioport_write(base, 8, 1, serial_ioport_write, s);
register_ioport_read(base, 8, 1, serial_ioport_read, s);
@@ -947,7 +947,7 @@ SerialState *serial_mm_init (target_phys_addr_t base, int it_shift,
s->chr = chr;
serial_init_core(s);
- vmstate_register(base, &vmstate_serial, s);
+ vmstate_register(NULL, base, &vmstate_serial, s);
if (ioregister) {
if (be) {
diff --git a/hw/spitz.c b/hw/spitz.c
index 4f82e24..943933f 100644
--- a/hw/spitz.c
+++ b/hw/spitz.c
@@ -178,7 +178,7 @@ static void sl_flash_register(PXA2xxState *cpu, int size)
sl_writefn, s);
cpu_register_physical_memory(FLASH_BASE, 0x40, iomemtype);
- register_savevm("sl_flash", 0, 0, sl_save, sl_load, s);
+ register_savevm(NULL, "sl_flash", 0, 0, sl_save, sl_load, s);
}
/* Spitz Keyboard */
@@ -508,7 +508,7 @@ static void spitz_keyboard_register(PXA2xxState *cpu)
spitz_keyboard_pre_map(s);
qemu_add_kbd_event_handler((QEMUPutKBDEvent *) spitz_keyboard_handler, s);
- register_savevm("spitz_keyboard", 0, 0,
+ register_savevm(NULL, "spitz_keyboard", 0, 0,
spitz_keyboard_save, spitz_keyboard_load, s);
}
@@ -613,7 +613,7 @@ static int spitz_lcdtg_init(SSISlave *dev)
s->bl_power = 0;
s->bl_intensity = 0x20;
- register_savevm("spitz-lcdtg", -1, 1,
+ register_savevm(&dev->qdev, "spitz-lcdtg", -1, 1,
spitz_lcdtg_save, spitz_lcdtg_load, s);
return 0;
}
@@ -708,7 +708,8 @@ static int corgi_ssp_init(SSISlave *dev)
s->bus[1] = ssi_create_bus(&dev->qdev, "ssi1");
s->bus[2] = ssi_create_bus(&dev->qdev, "ssi2");
- register_savevm("spitz_ssp", -1, 1, spitz_ssp_save, spitz_ssp_load, s);
+ register_savevm(&dev->qdev, "spitz_ssp", -1, 1,
+ spitz_ssp_save, spitz_ssp_load, s);
return 0;
}
diff --git a/hw/ssd0323.c b/hw/ssd0323.c
index b632825..8643961 100644
--- a/hw/ssd0323.c
+++ b/hw/ssd0323.c
@@ -335,7 +335,8 @@ static int ssd0323_init(SSISlave *dev)
qdev_init_gpio_in(&dev->qdev, ssd0323_cd, 1);
- register_savevm("ssd0323_oled", -1, 1, ssd0323_save, ssd0323_load, s);
+ register_savevm(&dev->qdev, "ssd0323_oled", -1, 1,
+ ssd0323_save, ssd0323_load, s);
return 0;
}
diff --git a/hw/ssi-sd.c b/hw/ssi-sd.c
index 5e74e5d..b0fed58 100644
--- a/hw/ssi-sd.c
+++ b/hw/ssi-sd.c
@@ -237,7 +237,7 @@ static int ssi_sd_init(SSISlave *dev)
s->mode = SSI_SD_CMD;
bs = qdev_init_bdrv(&dev->qdev, IF_SD);
s->sd = sd_init(bs, 1);
- register_savevm("ssi_sd", -1, 1, ssi_sd_save, ssi_sd_load, s);
+ register_savevm(&dev->qdev, "ssi_sd", -1, 1, ssi_sd_save, ssi_sd_load, s);
return 0;
}
diff --git a/hw/stellaris.c b/hw/stellaris.c
index 5755f8a..ccad134 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -354,7 +354,8 @@ static int stellaris_gptm_init(SysBusDevice *dev)
s->opaque[0] = s->opaque[1] = s;
s->timer[0] = qemu_new_timer(vm_clock, gptm_tick, &s->opaque[0]);
s->timer[1] = qemu_new_timer(vm_clock, gptm_tick, &s->opaque[1]);
- register_savevm("stellaris_gptm", -1, 1, gptm_save, gptm_load, s);
+ register_savevm(&dev->qdev, "stellaris_gptm", -1, 1,
+ gptm_save, gptm_load, s);
return 0;
}
@@ -673,7 +674,7 @@ static int stellaris_sys_init(uint32_t base, qemu_irq irq,
ssys_writefn, s);
cpu_register_physical_memory(base, 0x00001000, iomemtype);
ssys_reset(s);
- register_savevm("stellaris_sys", -1, 1, ssys_save, ssys_load, s);
+ register_savevm(NULL, "stellaris_sys", -1, 1, ssys_save, ssys_load, s);
return 0;
}
@@ -887,7 +888,7 @@ static int stellaris_i2c_init(SysBusDevice * dev)
sysbus_init_mmio(dev, 0x1000, iomemtype);
/* ??? For now we only implement the master interface. */
stellaris_i2c_reset(s);
- register_savevm("stellaris_i2c", -1, 1,
+ register_savevm(&dev->qdev, "stellaris_i2c", -1, 1,
stellaris_i2c_save, stellaris_i2c_load, s);
return 0;
}
@@ -1196,7 +1197,7 @@ static int stellaris_adc_init(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, iomemtype);
stellaris_adc_reset(s);
qdev_init_gpio_in(&dev->qdev, stellaris_adc_trigger, 1);
- register_savevm("stellaris_adc", -1, 1,
+ register_savevm(&dev->qdev, "stellaris_adc", -1, 1,
stellaris_adc_save, stellaris_adc_load, s);
return 0;
}
@@ -1256,7 +1257,7 @@ static int stellaris_ssi_bus_init(SSISlave *dev)
s->bus[1] = ssi_create_bus(&dev->qdev, "ssi1");
qdev_init_gpio_in(&dev->qdev, stellaris_ssi_bus_select, 1);
- register_savevm("stellaris_ssi_bus", -1, 1,
+ register_savevm(&dev->qdev, "stellaris_ssi_bus", -1, 1,
stellaris_ssi_bus_save, stellaris_ssi_bus_load, s);
return 0;
}
diff --git a/hw/stellaris_enet.c b/hw/stellaris_enet.c
index d1d755e..330a9d6 100644
--- a/hw/stellaris_enet.c
+++ b/hw/stellaris_enet.c
@@ -389,7 +389,7 @@ static void stellaris_enet_cleanup(VLANClientState *nc)
{
stellaris_enet_state *s = DO_UPCAST(NICState, nc, nc)->opaque;
- unregister_savevm("stellaris_enet", s);
+ unregister_savevm(&s->busdev.qdev, "stellaris_enet", s);
cpu_unregister_io_memory(s->mmio_index);
@@ -419,7 +419,7 @@ static int stellaris_enet_init(SysBusDevice *dev)
qemu_format_nic_info_str(&s->nic->nc, s->conf.macaddr.a);
stellaris_enet_reset(s);
- register_savevm("stellaris_enet", -1, 1,
+ register_savevm(&s->busdev.qdev, "stellaris_enet", -1, 1,
stellaris_enet_save, stellaris_enet_load, s);
return 0;
}
diff --git a/hw/stellaris_input.c b/hw/stellaris_input.c
index 33395a4..16aae96 100644
--- a/hw/stellaris_input.c
+++ b/hw/stellaris_input.c
@@ -86,6 +86,6 @@ void stellaris_gamepad_init(int n, qemu_irq *irq, const int *keycode)
}
s->num_buttons = n;
qemu_add_kbd_event_handler(stellaris_gamepad_put_key, s);
- register_savevm("stellaris_gamepad", -1, 1,
+ register_savevm(NULL, "stellaris_gamepad", -1, 1,
stellaris_gamepad_save, stellaris_gamepad_load, s);
}
diff --git a/hw/syborg_fb.c b/hw/syborg_fb.c
index 7be04a3..ed57203 100644
--- a/hw/syborg_fb.c
+++ b/hw/syborg_fb.c
@@ -526,7 +526,7 @@ static int syborg_fb_init(SysBusDevice *dev)
if (!s->rows)
s->rows = ds_get_height(s->ds);
- register_savevm("syborg_framebuffer", -1, 1,
+ register_savevm(&dev->qdev, "syborg_framebuffer", -1, 1,
syborg_fb_save, syborg_fb_load, s);
return 0;
}
diff --git a/hw/syborg_interrupt.c b/hw/syborg_interrupt.c
index f3a1767..cd10416 100644
--- a/hw/syborg_interrupt.c
+++ b/hw/syborg_interrupt.c
@@ -214,7 +214,7 @@ static int syborg_int_init(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, iomemtype);
s->flags = qemu_mallocz(s->num_irqs * sizeof(syborg_int_flags));
- register_savevm("syborg_int", -1, 1, syborg_int_save, syborg_int_load, s);
+ register_savevm(&dev->qdev, "syborg_int", -1, 1, syborg_int_save, syborg_int_load, s);
return 0;
}
diff --git a/hw/syborg_keyboard.c b/hw/syborg_keyboard.c
index 4a562f8..7709100 100644
--- a/hw/syborg_keyboard.c
+++ b/hw/syborg_keyboard.c
@@ -220,7 +220,7 @@ static int syborg_keyboard_init(SysBusDevice *dev)
qemu_add_kbd_event_handler(syborg_keyboard_event, s);
- register_savevm("syborg_keyboard", -1, 1,
+ register_savevm(&dev->qdev, "syborg_keyboard", -1, 1,
syborg_keyboard_save, syborg_keyboard_load, s);
return 0;
}
diff --git a/hw/syborg_pointer.c b/hw/syborg_pointer.c
index 563d730..69b8d96 100644
--- a/hw/syborg_pointer.c
+++ b/hw/syborg_pointer.c
@@ -218,7 +218,7 @@ static int syborg_pointer_init(SysBusDevice *dev)
qemu_add_mouse_event_handler(syborg_pointer_event, s, s->absolute,
"Syborg Pointer");
- register_savevm("syborg_pointer", -1, 1,
+ register_savevm(&dev->qdev, "syborg_pointer", -1, 1,
syborg_pointer_save, syborg_pointer_load, s);
return 0;
}
diff --git a/hw/syborg_rtc.c b/hw/syborg_rtc.c
index b066213..78d5edb 100644
--- a/hw/syborg_rtc.c
+++ b/hw/syborg_rtc.c
@@ -136,7 +136,8 @@ static int syborg_rtc_init(SysBusDevice *dev)
qemu_get_timedate(&tm, 0);
s->offset = (uint64_t)mktime(&tm) * 1000000000;
- register_savevm("syborg_rtc", -1, 1, syborg_rtc_save, syborg_rtc_load, s);
+ register_savevm(&dev->qdev, "syborg_rtc", -1, 1,
+ syborg_rtc_save, syborg_rtc_load, s);
return 0;
}
diff --git a/hw/syborg_serial.c b/hw/syborg_serial.c
index cac00ea..8c42956 100644
--- a/hw/syborg_serial.c
+++ b/hw/syborg_serial.c
@@ -335,7 +335,7 @@ static int syborg_serial_init(SysBusDevice *dev)
}
s->read_fifo = qemu_mallocz(s->fifo_size * sizeof(s->read_fifo[0]));
- register_savevm("syborg_serial", -1, 1,
+ register_savevm(&dev->qdev, "syborg_serial", -1, 1,
syborg_serial_save, syborg_serial_load, s);
return 0;
}
diff --git a/hw/syborg_timer.c b/hw/syborg_timer.c
index 3e4a447..95e07d7 100644
--- a/hw/syborg_timer.c
+++ b/hw/syborg_timer.c
@@ -221,7 +221,7 @@ static int syborg_timer_init(SysBusDevice *dev)
bh = qemu_bh_new(syborg_timer_tick, s);
s->timer = ptimer_init(bh);
ptimer_set_freq(s->timer, s->freq);
- register_savevm("syborg_timer", -1, 1,
+ register_savevm(&dev->qdev, "syborg_timer", -1, 1,
syborg_timer_save, syborg_timer_load, s);
return 0;
}
diff --git a/hw/tsc2005.c b/hw/tsc2005.c
index b75cc86..a55853c 100644
--- a/hw/tsc2005.c
+++ b/hw/tsc2005.c
@@ -548,7 +548,7 @@ void *tsc2005_init(qemu_irq pintdav)
"QEMU TSC2005-driven Touchscreen");
qemu_register_reset((void *) tsc2005_reset, s);
- register_savevm("tsc2005", -1, 0, tsc2005_save, tsc2005_load, s);
+ register_savevm(NULL, "tsc2005", -1, 0, tsc2005_save, tsc2005_load, s);
return s;
}
diff --git a/hw/tsc210x.c b/hw/tsc210x.c
index e851ca1..fca73f1 100644
--- a/hw/tsc210x.c
+++ b/hw/tsc210x.c
@@ -1143,7 +1143,7 @@ uWireSlave *tsc2102_init(qemu_irq pint)
AUD_register_card(s->name, &s->card);
qemu_register_reset((void *) tsc210x_reset, s);
- register_savevm(s->name, -1, 0,
+ register_savevm(NULL, s->name, -1, 0,
tsc210x_save, tsc210x_load, s);
return &s->chip;
@@ -1194,7 +1194,7 @@ uWireSlave *tsc2301_init(qemu_irq penirq, qemu_irq kbirq, qemu_irq dav)
AUD_register_card(s->name, &s->card);
qemu_register_reset((void *) tsc210x_reset, s);
- register_savevm(s->name, -1, 0, tsc210x_save, tsc210x_load, s);
+ register_savevm(NULL, s->name, -1, 0, tsc210x_save, tsc210x_load, s);
return &s->chip;
}
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index f0a773d..362fb77 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -158,7 +158,8 @@ static int pci_unin_main_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
- register_savevm("uninorth", 0, 1, pci_unin_save, pci_unin_load, &s->host_state);
+ register_savevm(&dev->qdev, "uninorth", 0, 1,
+ pci_unin_save, pci_unin_load, &s->host_state);
qemu_register_reset(pci_unin_reset, &s->host_state);
return 0;
}
@@ -178,7 +179,8 @@ static int pci_u3_agp_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
- register_savevm("uninorth", 0, 1, pci_unin_save, pci_unin_load, &s->host_state);
+ register_savevm(&dev->qdev, "uninorth", 0, 1,
+ pci_unin_save, pci_unin_load, &s->host_state);
qemu_register_reset(pci_unin_reset, &s->host_state);
return 0;
diff --git a/hw/vga-isa-mm.c b/hw/vga-isa-mm.c
index 8e31e36..680b557 100644
--- a/hw/vga-isa-mm.c
+++ b/hw/vga-isa-mm.c
@@ -100,7 +100,7 @@ static void vga_mm_init(ISAVGAMMState *s, target_phys_addr_t vram_base,
s_ioport_ctrl = cpu_register_io_memory(vga_mm_read_ctrl, vga_mm_write_ctrl, s);
vga_io_memory = cpu_register_io_memory(vga_mem_read, vga_mem_write, s);
- vmstate_register(0, &vmstate_vga_common, s);
+ vmstate_register(NULL, 0, &vmstate_vga_common, s);
cpu_register_physical_memory(ctrl_base, 0x100000, s_ioport_ctrl);
s->vga.bank_offset = 0;
diff --git a/hw/vga-isa.c b/hw/vga-isa.c
index 7937144..3046054 100644
--- a/hw/vga-isa.c
+++ b/hw/vga-isa.c
@@ -37,7 +37,7 @@ int isa_vga_init(void)
vga_common_init(s, VGA_RAM_SIZE);
vga_init(s);
- vmstate_register(0, &vmstate_vga_common, s);
+ vmstate_register(NULL, 0, &vmstate_vga_common, s);
s->ds = graphic_console_init(s->update, s->invalidate,
s->screen_dump, s->text_update, s);
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index 152af80..9fe3886 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -270,7 +270,8 @@ VirtIODevice *virtio_balloon_init(DeviceState *dev)
reset_stats(s);
qemu_add_balloon_handler(virtio_balloon_to_target, s);
- register_savevm("virtio-balloon", -1, 1, virtio_balloon_save, virtio_balloon_load, s);
+ register_savevm(dev, "virtio-balloon", -1, 1,
+ virtio_balloon_save, virtio_balloon_load, s);
return &s->vdev;
}
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 5d7f1a2..5f523fc 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -511,7 +511,7 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf)
s->vq = virtio_add_queue(&s->vdev, 128, virtio_blk_handle_output);
qemu_add_vm_change_state_handler(virtio_blk_dma_restart_cb, s);
- register_savevm("virtio-blk", virtio_blk_id++, 2,
+ register_savevm(dev, "virtio-blk", virtio_blk_id++, 2,
virtio_blk_save, virtio_blk_load, s);
return &s->vdev;
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 06ba481..e9768e0 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -923,7 +923,7 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf)
n->vlans = qemu_mallocz(MAX_VLAN >> 3);
- register_savevm("virtio-net", virtio_net_id++, VIRTIO_NET_VM_VERSION,
+ register_savevm(NULL, "virtio-net", virtio_net_id++, VIRTIO_NET_VM_VERSION,
virtio_net_save, virtio_net_load, n);
n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change, n);
@@ -941,7 +941,7 @@ void virtio_net_exit(VirtIODevice *vdev)
qemu_purge_queued_packets(&n->nic->nc);
- unregister_savevm("virtio-net", n);
+ unregister_savevm(NULL, "virtio-net", n);
qemu_free(n->mac_table.macs);
qemu_free(n->vlans);
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 7f9d28f..b5ab3bb 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -790,7 +790,7 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t max_nr_ports)
* Register for the savevm section with the virtio-console name
* to preserve backward compat
*/
- register_savevm("virtio-console", -1, 2, virtio_serial_save,
+ register_savevm(dev, "virtio-console", -1, 2, virtio_serial_save,
virtio_serial_load, vser);
return vdev;
diff --git a/hw/vmmouse.c b/hw/vmmouse.c
index afebad9..f359304 100644
--- a/hw/vmmouse.c
+++ b/hw/vmmouse.c
@@ -274,7 +274,7 @@ void *vmmouse_init(void *m)
vmport_register(VMMOUSE_STATUS, vmmouse_ioport_read, s);
vmport_register(VMMOUSE_COMMAND, vmmouse_ioport_read, s);
vmport_register(VMMOUSE_DATA, vmmouse_ioport_read, s);
- vmstate_register(0, &vmstate_vmmouse, s);
+ vmstate_register(NULL, 0, &vmstate_vmmouse, s);
return s;
}
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index bf2a699..359e5d8 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -1169,7 +1169,7 @@ static void vmsvga_init(struct vmsvga_state_s *s, int vga_ram_size)
vga_common_init(&s->vga, vga_ram_size);
vga_init(&s->vga);
- vmstate_register(0, &vmstate_vga_common, &s->vga);
+ vmstate_register(NULL, 0, &vmstate_vga_common, &s->vga);
vga_init_vbe(&s->vga);
diff --git a/hw/zaurus.c b/hw/zaurus.c
index db6ba75..dd999d7 100644
--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -230,7 +230,7 @@ ScoopInfo *scoop_init(PXA2xxState *cpu,
iomemtype = cpu_register_io_memory(scoop_readfn,
scoop_writefn, s);
cpu_register_physical_memory(target_base, 0x1000, iomemtype);
- register_savevm("scoop", instance, 1, scoop_save, scoop_load, s);
+ register_savevm(NULL, "scoop", instance, 1, scoop_save, scoop_load, s);
return s;
}
diff --git a/qemu-timer.c b/qemu-timer.c
index bdc8206..bc5f207 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -662,7 +662,7 @@ static const VMStateDescription vmstate_timers = {
void configure_icount(const char *option)
{
- vmstate_register(0, &vmstate_timers, &timers_state);
+ vmstate_register(NULL, 0, &vmstate_timers, &timers_state);
if (!option)
return;
diff --git a/savevm.c b/savevm.c
index af92ba2..81d544f 100644
--- a/savevm.c
+++ b/savevm.c
@@ -72,6 +72,7 @@
#include "qemu-common.h"
#include "hw/hw.h"
+#include "hw/qdev.h"
#include "net.h"
#include "monitor.h"
#include "sysemu.h"
@@ -1026,7 +1027,8 @@ static int calculate_new_instance_id(const char *idstr)
of the system, so instance_id should be removed/replaced.
Meanwhile pass -1 as instance_id if you do not already have a clearly
distinguishing id for all instances of your device class. */
-int register_savevm_live(const char *idstr,
+int register_savevm_live(DeviceState *dev,
+ const char *idstr,
int instance_id,
int version_id,
SaveSetParamsHandler *set_params,
@@ -1058,18 +1060,19 @@ int register_savevm_live(const char *idstr,
return 0;
}
-int register_savevm(const char *idstr,
+int register_savevm(DeviceState *dev,
+ const char *idstr,
int instance_id,
int version_id,
SaveStateHandler *save_state,
LoadStateHandler *load_state,
void *opaque)
{
- return register_savevm_live(idstr, instance_id, version_id,
+ return register_savevm_live(dev, idstr, instance_id, version_id,
NULL, NULL, save_state, load_state, opaque);
}
-void unregister_savevm(const char *idstr, void *opaque)
+void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque)
{
SaveStateEntry *se, *new_se;
@@ -1081,7 +1084,7 @@ void unregister_savevm(const char *idstr, void *opaque)
}
}
-int vmstate_register_with_alias_id(int instance_id,
+int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
const VMStateDescription *vmsd,
void *opaque, int alias_id,
int required_for_version)
@@ -1112,13 +1115,15 @@ int vmstate_register_with_alias_id(int instance_id,
return 0;
}
-int vmstate_register(int instance_id, const VMStateDescription *vmsd,
- void *opaque)
+int vmstate_register(DeviceState *dev, int instance_id,
+ const VMStateDescription *vmsd, void *opaque)
{
- return vmstate_register_with_alias_id(instance_id, vmsd, opaque, -1, 0);
+ return vmstate_register_with_alias_id(dev, instance_id, vmsd,
+ opaque, -1, 0);
}
-void vmstate_unregister(const VMStateDescription *vmsd, void *opaque)
+void vmstate_unregister(DeviceState *dev, const VMStateDescription *vmsd,
+ void *opaque)
{
SaveStateEntry *se, *new_se;
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 3c785cd..82fd9b4 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -232,7 +232,8 @@ Slirp *slirp_init(int restricted, struct in_addr vnetwork,
slirp->opaque = opaque;
- register_savevm("slirp", 0, 3, slirp_state_save, slirp_state_load, slirp);
+ register_savevm(NULL, "slirp", 0, 3,
+ slirp_state_save, slirp_state_load, slirp);
QTAILQ_INSERT_TAIL(&slirp_instances, slirp, entry);
@@ -243,7 +244,7 @@ void slirp_cleanup(Slirp *slirp)
{
QTAILQ_REMOVE(&slirp_instances, slirp, entry);
- unregister_savevm("slirp", slirp);
+ unregister_savevm(NULL, "slirp", slirp);
qemu_free(slirp->tftp_prefix);
qemu_free(slirp->bootp_filename);
diff --git a/vl.c b/vl.c
index 3d7ce52..405d8ba 100644
--- a/vl.c
+++ b/vl.c
@@ -3644,7 +3644,7 @@ int main(int argc, char **argv, char **envp)
if (qemu_opts_foreach(&qemu_drive_opts, drive_init_func, machine, 1) != 0)
exit(1);
- register_savevm_live("ram", 0, 3, NULL, ram_save_live, NULL,
+ register_savevm_live(NULL, "ram", 0, 3, NULL, ram_save_live, NULL,
ram_load, NULL);
if (nb_numa_nodes > 0) {
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [RFC PATCH 3/5] savevm: Make use of the new DeviceState param
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
@ 2010-06-14 5:51 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, avi, anthony, paul, kraxel, chrisw, alex.williamson
Use the now passed in DeviceState along with qdev_get_dev_path() to
create meaningful id strings for the SaveStateEntry. We append the
driver provided string so we can differentiate multiple savevm
handlers per device:
"/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"
We also introduce compatibility fields so that we can attempt to
import savevm data from an older VM. These should be deprecated and
removed at some point.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
savevm.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 76 insertions(+), 7 deletions(-)
diff --git a/savevm.c b/savevm.c
index 81d544f..4cc542b 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1002,6 +1002,8 @@ typedef struct SaveStateEntry {
LoadStateHandler *load_state;
const VMStateDescription *vmsd;
void *opaque;
+ char compat_idstr[256];
+ int compat_instance_id;
} SaveStateEntry;
@@ -1023,6 +1025,20 @@ static int calculate_new_instance_id(const char *idstr)
return instance_id;
}
+static int calculate_new_compat_instance_id(const char *idstr)
+{
+ SaveStateEntry *se;
+ int instance_id = 0;
+
+ QTAILQ_FOREACH(se, &savevm_handlers, entry) {
+ if (strcmp(idstr, se->compat_idstr) == 0
+ && instance_id <= se->compat_instance_id) {
+ instance_id = se->compat_instance_id + 1;
+ }
+ }
+ return instance_id;
+}
+
/* TODO: Individual devices generally have very little idea about the rest
of the system, so instance_id should be removed/replaced.
Meanwhile pass -1 as instance_id if you do not already have a clearly
@@ -1040,7 +1056,16 @@ int register_savevm_live(DeviceState *dev,
SaveStateEntry *se;
se = qemu_mallocz(sizeof(SaveStateEntry));
- pstrcpy(se->idstr, sizeof(se->idstr), idstr);
+
+ if (dev) {
+ char *path = qdev_get_dev_path(dev);
+ pstrcpy(se->idstr, sizeof(se->idstr), path);
+ pstrcat(se->idstr, sizeof(se->idstr), "/");
+ pstrcat(se->idstr, sizeof(se->idstr), idstr);
+ qemu_free(path);
+ } else {
+ pstrcpy(se->idstr, sizeof(se->idstr), idstr);
+ }
se->version_id = version_id;
se->section_id = global_section_id++;
se->set_params = set_params;
@@ -1050,11 +1075,19 @@ int register_savevm_live(DeviceState *dev,
se->opaque = opaque;
se->vmsd = NULL;
+ pstrcpy(se->compat_idstr, sizeof(se->idstr), idstr);
if (instance_id == -1) {
- se->instance_id = calculate_new_instance_id(idstr);
+ se->instance_id = calculate_new_instance_id(se->idstr);
+ se->compat_instance_id = calculate_new_compat_instance_id(idstr);
} else {
- se->instance_id = instance_id;
+ se->instance_id = se->compat_instance_id = instance_id;
+ }
+
+ if (dev && instance_id == -1 && se->instance_id != 0) {
+ fprintf(stderr, "%s: Failed to create unqiue path \"%s\"\n",
+ __FUNCTION__, se->idstr);
}
+
/* add at the end of list */
QTAILQ_INSERT_TAIL(&savevm_handlers, se, entry);
return 0;
@@ -1075,13 +1108,25 @@ int register_savevm(DeviceState *dev,
void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque)
{
SaveStateEntry *se, *new_se;
+ char *path;
+
+ if (dev) {
+ int len;
+ path = qdev_get_dev_path(dev);
+ len = strlen(path);
+ path = qemu_realloc(path, len + strlen(idstr) + 2);
+ sprintf(path + len, "/%s", idstr);
+ } else {
+ path = qemu_strdup(idstr);
+ }
QTAILQ_FOREACH_SAFE(se, &savevm_handlers, entry, new_se) {
- if (strcmp(se->idstr, idstr) == 0 && se->opaque == opaque) {
+ if (strcmp(se->idstr, path) == 0 && se->opaque == opaque) {
QTAILQ_REMOVE(&savevm_handlers, se, entry);
qemu_free(se);
}
}
+ qemu_free(path);
}
int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
@@ -1095,7 +1140,16 @@ int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
assert(alias_id == -1 || required_for_version >= vmsd->minimum_version_id);
se = qemu_mallocz(sizeof(SaveStateEntry));
- pstrcpy(se->idstr, sizeof(se->idstr), vmsd->name);
+
+ if (dev) {
+ char *path = qdev_get_dev_path(dev);
+ pstrcpy(se->idstr, sizeof(se->idstr), path);
+ pstrcat(se->idstr, sizeof(se->idstr), "/");
+ pstrcat(se->idstr, sizeof(se->idstr), vmsd->name);
+ qemu_free(path);
+ } else {
+ pstrcpy(se->idstr, sizeof(se->idstr), vmsd->name);
+ }
se->version_id = vmsd->version_id;
se->section_id = global_section_id++;
se->save_live_state = NULL;
@@ -1105,11 +1159,19 @@ int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
se->vmsd = vmsd;
se->alias_id = alias_id;
+ pstrcpy(se->compat_idstr, sizeof(se->idstr), vmsd->name);
if (instance_id == -1) {
- se->instance_id = calculate_new_instance_id(vmsd->name);
+ se->instance_id = calculate_new_instance_id(se->idstr);
+ se->compat_instance_id = calculate_new_compat_instance_id(vmsd->name);
} else {
- se->instance_id = instance_id;
+ se->instance_id = se->compat_instance_id = instance_id;
}
+
+ if (dev && instance_id == -1 && se->instance_id != 0) {
+ fprintf(stderr, "%s: Failed to create unqiue path \"%s\"\n",
+ __FUNCTION__, se->idstr);
+ }
+
/* add at the end of list */
QTAILQ_INSERT_TAIL(&savevm_handlers, se, entry);
return 0;
@@ -1456,6 +1518,13 @@ static SaveStateEntry *find_se(const char *idstr, int instance_id)
instance_id == se->alias_id))
return se;
}
+
+ QTAILQ_FOREACH(se, &savevm_handlers, entry) {
+ if (!strcmp(se->compat_idstr, idstr) &&
+ (instance_id == se->compat_instance_id ||
+ instance_id == se->alias_id))
+ return se;
+ }
return NULL;
}
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [Qemu-devel] [RFC PATCH 3/5] savevm: Make use of the new DeviceState param
@ 2010-06-14 5:51 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: chrisw, kvm, paul, alex.williamson, kraxel, avi
Use the now passed in DeviceState along with qdev_get_dev_path() to
create meaningful id strings for the SaveStateEntry. We append the
driver provided string so we can differentiate multiple savevm
handlers per device:
"/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"
We also introduce compatibility fields so that we can attempt to
import savevm data from an older VM. These should be deprecated and
removed at some point.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
savevm.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 76 insertions(+), 7 deletions(-)
diff --git a/savevm.c b/savevm.c
index 81d544f..4cc542b 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1002,6 +1002,8 @@ typedef struct SaveStateEntry {
LoadStateHandler *load_state;
const VMStateDescription *vmsd;
void *opaque;
+ char compat_idstr[256];
+ int compat_instance_id;
} SaveStateEntry;
@@ -1023,6 +1025,20 @@ static int calculate_new_instance_id(const char *idstr)
return instance_id;
}
+static int calculate_new_compat_instance_id(const char *idstr)
+{
+ SaveStateEntry *se;
+ int instance_id = 0;
+
+ QTAILQ_FOREACH(se, &savevm_handlers, entry) {
+ if (strcmp(idstr, se->compat_idstr) == 0
+ && instance_id <= se->compat_instance_id) {
+ instance_id = se->compat_instance_id + 1;
+ }
+ }
+ return instance_id;
+}
+
/* TODO: Individual devices generally have very little idea about the rest
of the system, so instance_id should be removed/replaced.
Meanwhile pass -1 as instance_id if you do not already have a clearly
@@ -1040,7 +1056,16 @@ int register_savevm_live(DeviceState *dev,
SaveStateEntry *se;
se = qemu_mallocz(sizeof(SaveStateEntry));
- pstrcpy(se->idstr, sizeof(se->idstr), idstr);
+
+ if (dev) {
+ char *path = qdev_get_dev_path(dev);
+ pstrcpy(se->idstr, sizeof(se->idstr), path);
+ pstrcat(se->idstr, sizeof(se->idstr), "/");
+ pstrcat(se->idstr, sizeof(se->idstr), idstr);
+ qemu_free(path);
+ } else {
+ pstrcpy(se->idstr, sizeof(se->idstr), idstr);
+ }
se->version_id = version_id;
se->section_id = global_section_id++;
se->set_params = set_params;
@@ -1050,11 +1075,19 @@ int register_savevm_live(DeviceState *dev,
se->opaque = opaque;
se->vmsd = NULL;
+ pstrcpy(se->compat_idstr, sizeof(se->idstr), idstr);
if (instance_id == -1) {
- se->instance_id = calculate_new_instance_id(idstr);
+ se->instance_id = calculate_new_instance_id(se->idstr);
+ se->compat_instance_id = calculate_new_compat_instance_id(idstr);
} else {
- se->instance_id = instance_id;
+ se->instance_id = se->compat_instance_id = instance_id;
+ }
+
+ if (dev && instance_id == -1 && se->instance_id != 0) {
+ fprintf(stderr, "%s: Failed to create unqiue path \"%s\"\n",
+ __FUNCTION__, se->idstr);
}
+
/* add at the end of list */
QTAILQ_INSERT_TAIL(&savevm_handlers, se, entry);
return 0;
@@ -1075,13 +1108,25 @@ int register_savevm(DeviceState *dev,
void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque)
{
SaveStateEntry *se, *new_se;
+ char *path;
+
+ if (dev) {
+ int len;
+ path = qdev_get_dev_path(dev);
+ len = strlen(path);
+ path = qemu_realloc(path, len + strlen(idstr) + 2);
+ sprintf(path + len, "/%s", idstr);
+ } else {
+ path = qemu_strdup(idstr);
+ }
QTAILQ_FOREACH_SAFE(se, &savevm_handlers, entry, new_se) {
- if (strcmp(se->idstr, idstr) == 0 && se->opaque == opaque) {
+ if (strcmp(se->idstr, path) == 0 && se->opaque == opaque) {
QTAILQ_REMOVE(&savevm_handlers, se, entry);
qemu_free(se);
}
}
+ qemu_free(path);
}
int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
@@ -1095,7 +1140,16 @@ int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
assert(alias_id == -1 || required_for_version >= vmsd->minimum_version_id);
se = qemu_mallocz(sizeof(SaveStateEntry));
- pstrcpy(se->idstr, sizeof(se->idstr), vmsd->name);
+
+ if (dev) {
+ char *path = qdev_get_dev_path(dev);
+ pstrcpy(se->idstr, sizeof(se->idstr), path);
+ pstrcat(se->idstr, sizeof(se->idstr), "/");
+ pstrcat(se->idstr, sizeof(se->idstr), vmsd->name);
+ qemu_free(path);
+ } else {
+ pstrcpy(se->idstr, sizeof(se->idstr), vmsd->name);
+ }
se->version_id = vmsd->version_id;
se->section_id = global_section_id++;
se->save_live_state = NULL;
@@ -1105,11 +1159,19 @@ int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
se->vmsd = vmsd;
se->alias_id = alias_id;
+ pstrcpy(se->compat_idstr, sizeof(se->idstr), vmsd->name);
if (instance_id == -1) {
- se->instance_id = calculate_new_instance_id(vmsd->name);
+ se->instance_id = calculate_new_instance_id(se->idstr);
+ se->compat_instance_id = calculate_new_compat_instance_id(vmsd->name);
} else {
- se->instance_id = instance_id;
+ se->instance_id = se->compat_instance_id = instance_id;
}
+
+ if (dev && instance_id == -1 && se->instance_id != 0) {
+ fprintf(stderr, "%s: Failed to create unqiue path \"%s\"\n",
+ __FUNCTION__, se->idstr);
+ }
+
/* add at the end of list */
QTAILQ_INSERT_TAIL(&savevm_handlers, se, entry);
return 0;
@@ -1456,6 +1518,13 @@ static SaveStateEntry *find_se(const char *idstr, int instance_id)
instance_id == se->alias_id))
return se;
}
+
+ QTAILQ_FOREACH(se, &savevm_handlers, entry) {
+ if (!strcmp(se->compat_idstr, idstr) &&
+ (instance_id == se->compat_instance_id ||
+ instance_id == se->alias_id))
+ return se;
+ }
return NULL;
}
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [RFC PATCH 4/5] eepro100: Add a dev field to eeprom new/free functions
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
@ 2010-06-14 5:51 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, avi, anthony, paul, kraxel, chrisw, alex.williamson
This allows us to create a more meaningful savevm string.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
hw/eepro100.c | 4 ++--
hw/eeprom93xx.c | 8 ++++----
hw/eeprom93xx.h | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 92cfea7..c5731cc 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1836,7 +1836,7 @@ static int pci_nic_uninit(PCIDevice *pci_dev)
cpu_unregister_io_memory(s->mmio_index);
vmstate_unregister(&pci_dev->qdev, s->vmstate, s);
- eeprom93xx_free(s->eeprom);
+ eeprom93xx_free(&pci_dev->qdev, s->eeprom);
qemu_del_vlan_client(&s->nic->nc);
return 0;
}
@@ -1863,7 +1863,7 @@ static int e100_nic_init(PCIDevice *pci_dev)
/* Add 64 * 2 EEPROM. i82557 and i82558 support a 64 word EEPROM,
* i82559 and later support 64 or 256 word EEPROM. */
- s->eeprom = eeprom93xx_new(EEPROM_SIZE);
+ s->eeprom = eeprom93xx_new(&pci_dev->qdev, EEPROM_SIZE);
/* Handler for memory-mapped I/O */
s->mmio_index =
diff --git a/hw/eeprom93xx.c b/hw/eeprom93xx.c
index 6ba546f..660b28f 100644
--- a/hw/eeprom93xx.c
+++ b/hw/eeprom93xx.c
@@ -289,7 +289,7 @@ void eeprom93xx_reset(eeprom_t *eeprom)
}
#endif
-eeprom_t *eeprom93xx_new(uint16_t nwords)
+eeprom_t *eeprom93xx_new(DeviceState *dev, uint16_t nwords)
{
/* Add a new EEPROM (with 16, 64 or 256 words). */
eeprom_t *eeprom;
@@ -316,15 +316,15 @@ eeprom_t *eeprom93xx_new(uint16_t nwords)
/* Output DO is tristate, read results in 1. */
eeprom->eedo = 1;
logout("eeprom = 0x%p, nwords = %u\n", eeprom, nwords);
- vmstate_register(NULL, 0, &vmstate_eeprom, eeprom);
+ vmstate_register(dev, 0, &vmstate_eeprom, eeprom);
return eeprom;
}
-void eeprom93xx_free(eeprom_t *eeprom)
+void eeprom93xx_free(DeviceState *dev, eeprom_t *eeprom)
{
/* Destroy EEPROM. */
logout("eeprom = 0x%p\n", eeprom);
- vmstate_unregister(NULL, &vmstate_eeprom, eeprom);
+ vmstate_unregister(dev, &vmstate_eeprom, eeprom);
qemu_free(eeprom);
}
diff --git a/hw/eeprom93xx.h b/hw/eeprom93xx.h
index 47282d3..8ba0e28 100644
--- a/hw/eeprom93xx.h
+++ b/hw/eeprom93xx.h
@@ -23,10 +23,10 @@
typedef struct _eeprom_t eeprom_t;
/* Create a new EEPROM with (nwords * 2) bytes. */
-eeprom_t *eeprom93xx_new(uint16_t nwords);
+eeprom_t *eeprom93xx_new(DeviceState *dev, uint16_t nwords);
/* Destroy an existing EEPROM. */
-void eeprom93xx_free(eeprom_t *eeprom);
+void eeprom93xx_free(DeviceState *dev, eeprom_t *eeprom);
/* Read from the EEPROM. */
uint16_t eeprom93xx_read(eeprom_t *eeprom);
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [Qemu-devel] [RFC PATCH 4/5] eepro100: Add a dev field to eeprom new/free functions
@ 2010-06-14 5:51 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: chrisw, kvm, paul, alex.williamson, kraxel, avi
This allows us to create a more meaningful savevm string.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
hw/eepro100.c | 4 ++--
hw/eeprom93xx.c | 8 ++++----
hw/eeprom93xx.h | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 92cfea7..c5731cc 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1836,7 +1836,7 @@ static int pci_nic_uninit(PCIDevice *pci_dev)
cpu_unregister_io_memory(s->mmio_index);
vmstate_unregister(&pci_dev->qdev, s->vmstate, s);
- eeprom93xx_free(s->eeprom);
+ eeprom93xx_free(&pci_dev->qdev, s->eeprom);
qemu_del_vlan_client(&s->nic->nc);
return 0;
}
@@ -1863,7 +1863,7 @@ static int e100_nic_init(PCIDevice *pci_dev)
/* Add 64 * 2 EEPROM. i82557 and i82558 support a 64 word EEPROM,
* i82559 and later support 64 or 256 word EEPROM. */
- s->eeprom = eeprom93xx_new(EEPROM_SIZE);
+ s->eeprom = eeprom93xx_new(&pci_dev->qdev, EEPROM_SIZE);
/* Handler for memory-mapped I/O */
s->mmio_index =
diff --git a/hw/eeprom93xx.c b/hw/eeprom93xx.c
index 6ba546f..660b28f 100644
--- a/hw/eeprom93xx.c
+++ b/hw/eeprom93xx.c
@@ -289,7 +289,7 @@ void eeprom93xx_reset(eeprom_t *eeprom)
}
#endif
-eeprom_t *eeprom93xx_new(uint16_t nwords)
+eeprom_t *eeprom93xx_new(DeviceState *dev, uint16_t nwords)
{
/* Add a new EEPROM (with 16, 64 or 256 words). */
eeprom_t *eeprom;
@@ -316,15 +316,15 @@ eeprom_t *eeprom93xx_new(uint16_t nwords)
/* Output DO is tristate, read results in 1. */
eeprom->eedo = 1;
logout("eeprom = 0x%p, nwords = %u\n", eeprom, nwords);
- vmstate_register(NULL, 0, &vmstate_eeprom, eeprom);
+ vmstate_register(dev, 0, &vmstate_eeprom, eeprom);
return eeprom;
}
-void eeprom93xx_free(eeprom_t *eeprom)
+void eeprom93xx_free(DeviceState *dev, eeprom_t *eeprom)
{
/* Destroy EEPROM. */
logout("eeprom = 0x%p\n", eeprom);
- vmstate_unregister(NULL, &vmstate_eeprom, eeprom);
+ vmstate_unregister(dev, &vmstate_eeprom, eeprom);
qemu_free(eeprom);
}
diff --git a/hw/eeprom93xx.h b/hw/eeprom93xx.h
index 47282d3..8ba0e28 100644
--- a/hw/eeprom93xx.h
+++ b/hw/eeprom93xx.h
@@ -23,10 +23,10 @@
typedef struct _eeprom_t eeprom_t;
/* Create a new EEPROM with (nwords * 2) bytes. */
-eeprom_t *eeprom93xx_new(uint16_t nwords);
+eeprom_t *eeprom93xx_new(DeviceState *dev, uint16_t nwords);
/* Destroy an existing EEPROM. */
-void eeprom93xx_free(eeprom_t *eeprom);
+void eeprom93xx_free(DeviceState *dev, eeprom_t *eeprom);
/* Read from the EEPROM. */
uint16_t eeprom93xx_read(eeprom_t *eeprom);
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [RFC PATCH 5/5] virtio-net: Incorporate a DeviceState pointer and let savevm track instances
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
@ 2010-06-14 5:51 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, avi, anthony, paul, kraxel, chrisw, alex.williamson
Stuff a pointer to the DeviceState into the VirtIONet structure so that
we can easily remove the vmstate entry later. Also, let vmstate track
the instance number (it should always be zero internally since the
device path should now be unique).
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
hw/virtio-net.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index e9768e0..f41db45 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -60,6 +60,7 @@ typedef struct VirtIONet
uint8_t *macs;
} mac_table;
uint32_t *vlans;
+ DeviceState *qdev;
} VirtIONet;
/* TODO
@@ -890,7 +891,6 @@ static void virtio_net_vmstate_change(void *opaque, int running, int reason)
VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf)
{
VirtIONet *n;
- static int virtio_net_id;
n = (VirtIONet *)virtio_common_init("virtio-net", VIRTIO_ID_NET,
sizeof(struct virtio_net_config),
@@ -923,7 +923,8 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf)
n->vlans = qemu_mallocz(MAX_VLAN >> 3);
- register_savevm(NULL, "virtio-net", virtio_net_id++, VIRTIO_NET_VM_VERSION,
+ n->qdev = dev;
+ register_savevm(dev, "virtio-net", -1, VIRTIO_NET_VM_VERSION,
virtio_net_save, virtio_net_load, n);
n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change, n);
@@ -941,7 +942,7 @@ void virtio_net_exit(VirtIODevice *vdev)
qemu_purge_queued_packets(&n->nic->nc);
- unregister_savevm(NULL, "virtio-net", n);
+ unregister_savevm(n->qdev, "virtio-net", n);
qemu_free(n->mac_table.macs);
qemu_free(n->vlans);
^ permalink raw reply related [flat|nested] 160+ messages in thread
* [Qemu-devel] [RFC PATCH 5/5] virtio-net: Incorporate a DeviceState pointer and let savevm track instances
@ 2010-06-14 5:51 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 5:51 UTC (permalink / raw)
To: qemu-devel; +Cc: chrisw, kvm, paul, alex.williamson, kraxel, avi
Stuff a pointer to the DeviceState into the VirtIONet structure so that
we can easily remove the vmstate entry later. Also, let vmstate track
the instance number (it should always be zero internally since the
device path should now be unique).
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
hw/virtio-net.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index e9768e0..f41db45 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -60,6 +60,7 @@ typedef struct VirtIONet
uint8_t *macs;
} mac_table;
uint32_t *vlans;
+ DeviceState *qdev;
} VirtIONet;
/* TODO
@@ -890,7 +891,6 @@ static void virtio_net_vmstate_change(void *opaque, int running, int reason)
VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf)
{
VirtIONet *n;
- static int virtio_net_id;
n = (VirtIONet *)virtio_common_init("virtio-net", VIRTIO_ID_NET,
sizeof(struct virtio_net_config),
@@ -923,7 +923,8 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf)
n->vlans = qemu_mallocz(MAX_VLAN >> 3);
- register_savevm(NULL, "virtio-net", virtio_net_id++, VIRTIO_NET_VM_VERSION,
+ n->qdev = dev;
+ register_savevm(dev, "virtio-net", -1, VIRTIO_NET_VM_VERSION,
virtio_net_save, virtio_net_load, n);
n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change, n);
@@ -941,7 +942,7 @@ void virtio_net_exit(VirtIODevice *vdev)
qemu_purge_queued_packets(&n->nic->nc);
- unregister_savevm(NULL, "virtio-net", n);
+ unregister_savevm(n->qdev, "virtio-net", n);
qemu_free(n->mac_table.macs);
qemu_free(n->vlans);
^ permalink raw reply related [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
@ 2010-06-14 6:39 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-14 6:39 UTC (permalink / raw)
To: Alex Williamson; +Cc: qemu-devel, chrisw, kvm, paul, kraxel, avi
Alex Williamson <alex.williamson@redhat.com> writes:
> qdev_get_dev_path() is intended to be the canonical utility for creating
> a string representing the qdev hierarchy of a device. The path consists
> of bus and device names as well as identified properties of the immediate
> parent bus and device. This results in strings like:
>
> "/main-system-bus/pci.0,addr=00.0/i440FX"
> "/main-system-bus/pci.0,addr=01.0/PIIX3"
> "/main-system-bus/pci.0,addr=02.0/cirrus-vga"
> "/main-system-bus/pci.0/isa.0/mc146818rtc"
> "/main-system-bus/pci.0/isa.0/isa-serial"
> "/main-system-bus/pci.0/isa.0/i8042"
> "/main-system-bus/pci.0/isa.0/isa-fdc"
> "/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56"
> "/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57"
> "/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58"
> "/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59"
> "/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a"
> "/main-system-bus/pci.0,addr=01.1/piix3-ide"
> "/main-system-bus/pci.0,addr=01.3/PIIX4_PM"
> "/main-system-bus/pci.0,addr=08.0/lsi53c895a"
> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>
> There are two primary targets for these strings. The first is vmsave, where
> we currently use a device provided string plus instance number to track
> SaveStateEntries. This fails when we introduce device hotplug, particularly
> in a case were we have gaps in the instance numbers that cannot easily be
> reproduced on a migration target. The second is for naming RAMBlocks. For
> these, we would like a string that matches the vmstate string.
Could you explain why you add "identified properties of the immediate
parent bus and device"? They make the result ver much *not* a "dev
path" in the qdev sense...
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 6:39 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-14 6:39 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, paul, qemu-devel, avi, kraxel
Alex Williamson <alex.williamson@redhat.com> writes:
> qdev_get_dev_path() is intended to be the canonical utility for creating
> a string representing the qdev hierarchy of a device. The path consists
> of bus and device names as well as identified properties of the immediate
> parent bus and device. This results in strings like:
>
> "/main-system-bus/pci.0,addr=00.0/i440FX"
> "/main-system-bus/pci.0,addr=01.0/PIIX3"
> "/main-system-bus/pci.0,addr=02.0/cirrus-vga"
> "/main-system-bus/pci.0/isa.0/mc146818rtc"
> "/main-system-bus/pci.0/isa.0/isa-serial"
> "/main-system-bus/pci.0/isa.0/i8042"
> "/main-system-bus/pci.0/isa.0/isa-fdc"
> "/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56"
> "/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57"
> "/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58"
> "/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59"
> "/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a"
> "/main-system-bus/pci.0,addr=01.1/piix3-ide"
> "/main-system-bus/pci.0,addr=01.3/PIIX4_PM"
> "/main-system-bus/pci.0,addr=08.0/lsi53c895a"
> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>
> There are two primary targets for these strings. The first is vmsave, where
> we currently use a device provided string plus instance number to track
> SaveStateEntries. This fails when we introduce device hotplug, particularly
> in a case were we have gaps in the instance numbers that cannot easily be
> reproduced on a migration target. The second is for naming RAMBlocks. For
> these, we would like a string that matches the vmstate string.
Could you explain why you add "identified properties of the immediate
parent bus and device"? They make the result ver much *not* a "dev
path" in the qdev sense...
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
@ 2010-06-14 7:02 ` Gerd Hoffmann
-1 siblings, 0 replies; 160+ messages in thread
From: Gerd Hoffmann @ 2010-06-14 7:02 UTC (permalink / raw)
To: Alex Williamson; +Cc: qemu-devel, kvm, avi, anthony, paul, chrisw
Hi,
> 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.
You'll need that for every bus along the way down to the device. Create
a virtual machine with two lsi scsi host adapters, then attach a disk
with scsi id 0 to each. Just the scsi id isn't good enougth to identify
the device. You'll need the lsi pci address too.
> For now, the only properties I've tagged as path
> properties are PCI bus addresses and MAC addresses.
mac address isn't needed here. You need the property which specifies
the bus address. For PCI this obviously is the PCI address. For scsi
the scsi id. For ISA you can use the I/O port base. virtio-serial the
port number, ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
@ 2010-06-14 7:02 ` Gerd Hoffmann
0 siblings, 0 replies; 160+ messages in thread
From: Gerd Hoffmann @ 2010-06-14 7:02 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, qemu-devel, paul, avi
Hi,
> 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.
You'll need that for every bus along the way down to the device. Create
a virtual machine with two lsi scsi host adapters, then attach a disk
with scsi id 0 to each. Just the scsi id isn't good enougth to identify
the device. You'll need the lsi pci address too.
> For now, the only properties I've tagged as path
> properties are PCI bus addresses and MAC addresses.
mac address isn't needed here. You need the property which specifies
the bus address. For PCI this obviously is the PCI address. For scsi
the scsi id. For ISA you can use the I/O port base. virtio-serial the
port number, ...
cheers,
Gerd
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 6:39 ` Markus Armbruster
@ 2010-06-14 12:52 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 12:52 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-devel, chrisw, kvm, paul, kraxel, avi
On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
> > qdev_get_dev_path() is intended to be the canonical utility for creating
> > a string representing the qdev hierarchy of a device. The path consists
> > of bus and device names as well as identified properties of the immediate
> > parent bus and device. This results in strings like:
> >
> > "/main-system-bus/pci.0,addr=00.0/i440FX"
> > "/main-system-bus/pci.0,addr=01.0/PIIX3"
> > "/main-system-bus/pci.0,addr=02.0/cirrus-vga"
> > "/main-system-bus/pci.0/isa.0/mc146818rtc"
> > "/main-system-bus/pci.0/isa.0/isa-serial"
> > "/main-system-bus/pci.0/isa.0/i8042"
> > "/main-system-bus/pci.0/isa.0/isa-fdc"
> > "/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56"
> > "/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57"
> > "/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58"
> > "/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59"
> > "/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a"
> > "/main-system-bus/pci.0,addr=01.1/piix3-ide"
> > "/main-system-bus/pci.0,addr=01.3/PIIX4_PM"
> > "/main-system-bus/pci.0,addr=08.0/lsi53c895a"
> > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >
> > There are two primary targets for these strings. The first is vmsave, where
> > we currently use a device provided string plus instance number to track
> > SaveStateEntries. This fails when we introduce device hotplug, particularly
> > in a case were we have gaps in the instance numbers that cannot easily be
> > reproduced on a migration target. The second is for naming RAMBlocks. For
> > these, we would like a string that matches the vmstate string.
>
> Could you explain why you add "identified properties of the immediate
> parent bus and device"? They make the result ver much *not* a "dev
> path" in the qdev sense...
In order to try to get a unique string. Without looking into device
properties, two e1000s would both be:
/main-system-bus/pci.0/e1000
/main-system-bus/pci.0/e1000
Which is no better than simply "e1000" and would require us to fall back
to instance ids again. The goal here is that anything that makes use of
passing a dev when registering a vmstate gets an instance id of zero.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 12:52 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 12:52 UTC (permalink / raw)
To: Markus Armbruster; +Cc: chrisw, kvm, paul, qemu-devel, avi, kraxel
On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
> > qdev_get_dev_path() is intended to be the canonical utility for creating
> > a string representing the qdev hierarchy of a device. The path consists
> > of bus and device names as well as identified properties of the immediate
> > parent bus and device. This results in strings like:
> >
> > "/main-system-bus/pci.0,addr=00.0/i440FX"
> > "/main-system-bus/pci.0,addr=01.0/PIIX3"
> > "/main-system-bus/pci.0,addr=02.0/cirrus-vga"
> > "/main-system-bus/pci.0/isa.0/mc146818rtc"
> > "/main-system-bus/pci.0/isa.0/isa-serial"
> > "/main-system-bus/pci.0/isa.0/i8042"
> > "/main-system-bus/pci.0/isa.0/isa-fdc"
> > "/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56"
> > "/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57"
> > "/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58"
> > "/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59"
> > "/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a"
> > "/main-system-bus/pci.0,addr=01.1/piix3-ide"
> > "/main-system-bus/pci.0,addr=01.3/PIIX4_PM"
> > "/main-system-bus/pci.0,addr=08.0/lsi53c895a"
> > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >
> > There are two primary targets for these strings. The first is vmsave, where
> > we currently use a device provided string plus instance number to track
> > SaveStateEntries. This fails when we introduce device hotplug, particularly
> > in a case were we have gaps in the instance numbers that cannot easily be
> > reproduced on a migration target. The second is for naming RAMBlocks. For
> > these, we would like a string that matches the vmstate string.
>
> Could you explain why you add "identified properties of the immediate
> parent bus and device"? They make the result ver much *not* a "dev
> path" in the qdev sense...
In order to try to get a unique string. Without looking into device
properties, two e1000s would both be:
/main-system-bus/pci.0/e1000
/main-system-bus/pci.0/e1000
Which is no better than simply "e1000" and would require us to fall back
to instance ids again. The goal here is that anything that makes use of
passing a dev when registering a vmstate gets an instance id of zero.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 12:52 ` Alex Williamson
@ 2010-06-14 13:00 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-14 13:00 UTC (permalink / raw)
To: Alex Williamson
Cc: Markus Armbruster, qemu-devel, chrisw, kvm, paul, kraxel, avi
Alex Williamson wrote:
> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>>> qdev_get_dev_path() is intended to be the canonical utility for creating
>>> a string representing the qdev hierarchy of a device. The path consists
>>> of bus and device names as well as identified properties of the immediate
>>> parent bus and device. This results in strings like:
>>>
>>> "/main-system-bus/pci.0,addr=00.0/i440FX"
>>> "/main-system-bus/pci.0,addr=01.0/PIIX3"
>>> "/main-system-bus/pci.0,addr=02.0/cirrus-vga"
>>> "/main-system-bus/pci.0/isa.0/mc146818rtc"
>>> "/main-system-bus/pci.0/isa.0/isa-serial"
>>> "/main-system-bus/pci.0/isa.0/i8042"
>>> "/main-system-bus/pci.0/isa.0/isa-fdc"
>>> "/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56"
>>> "/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57"
>>> "/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58"
>>> "/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59"
>>> "/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a"
>>> "/main-system-bus/pci.0,addr=01.1/piix3-ide"
>>> "/main-system-bus/pci.0,addr=01.3/PIIX4_PM"
>>> "/main-system-bus/pci.0,addr=08.0/lsi53c895a"
>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>>>
>>> There are two primary targets for these strings. The first is vmsave, where
>>> we currently use a device provided string plus instance number to track
>>> SaveStateEntries. This fails when we introduce device hotplug, particularly
>>> in a case were we have gaps in the instance numbers that cannot easily be
>>> reproduced on a migration target. The second is for naming RAMBlocks. For
>>> these, we would like a string that matches the vmstate string.
>> Could you explain why you add "identified properties of the immediate
>> parent bus and device"? They make the result ver much *not* a "dev
>> path" in the qdev sense...
>
> In order to try to get a unique string. Without looking into device
> properties, two e1000s would both be:
>
> /main-system-bus/pci.0/e1000
> /main-system-bus/pci.0/e1000
>
> Which is no better than simply "e1000" and would require us to fall back
> to instance ids again. The goal here is that anything that makes use of
> passing a dev when registering a vmstate gets an instance id of zero.
Will soon (re-)post a patch that adds per-bus instance numbers to deal
with identically named devices. That's required as not all buses have
canonical node IDs (e.g. ISA or the main system bus).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 13:00 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-14 13:00 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, Markus Armbruster, qemu-devel, paul, avi, kraxel
Alex Williamson wrote:
> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>>> qdev_get_dev_path() is intended to be the canonical utility for creating
>>> a string representing the qdev hierarchy of a device. The path consists
>>> of bus and device names as well as identified properties of the immediate
>>> parent bus and device. This results in strings like:
>>>
>>> "/main-system-bus/pci.0,addr=00.0/i440FX"
>>> "/main-system-bus/pci.0,addr=01.0/PIIX3"
>>> "/main-system-bus/pci.0,addr=02.0/cirrus-vga"
>>> "/main-system-bus/pci.0/isa.0/mc146818rtc"
>>> "/main-system-bus/pci.0/isa.0/isa-serial"
>>> "/main-system-bus/pci.0/isa.0/i8042"
>>> "/main-system-bus/pci.0/isa.0/isa-fdc"
>>> "/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56"
>>> "/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57"
>>> "/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58"
>>> "/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59"
>>> "/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a"
>>> "/main-system-bus/pci.0,addr=01.1/piix3-ide"
>>> "/main-system-bus/pci.0,addr=01.3/PIIX4_PM"
>>> "/main-system-bus/pci.0,addr=08.0/lsi53c895a"
>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>>>
>>> There are two primary targets for these strings. The first is vmsave, where
>>> we currently use a device provided string plus instance number to track
>>> SaveStateEntries. This fails when we introduce device hotplug, particularly
>>> in a case were we have gaps in the instance numbers that cannot easily be
>>> reproduced on a migration target. The second is for naming RAMBlocks. For
>>> these, we would like a string that matches the vmstate string.
>> Could you explain why you add "identified properties of the immediate
>> parent bus and device"? They make the result ver much *not* a "dev
>> path" in the qdev sense...
>
> In order to try to get a unique string. Without looking into device
> properties, two e1000s would both be:
>
> /main-system-bus/pci.0/e1000
> /main-system-bus/pci.0/e1000
>
> Which is no better than simply "e1000" and would require us to fall back
> to instance ids again. The goal here is that anything that makes use of
> passing a dev when registering a vmstate gets an instance id of zero.
Will soon (re-)post a patch that adds per-bus instance numbers to deal
with identically named devices. That's required as not all buses have
canonical node IDs (e.g. ISA or the main system bus).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 12:52 ` Alex Williamson
@ 2010-06-14 13:09 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-14 13:09 UTC (permalink / raw)
To: Alex Williamson; +Cc: Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
> > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
There's a device missing between the main system bus and the pci bus. Should
be something like:
/main-system-bus/piix4-pcihost/pci.0/_09.0
> > Could you explain why you add "identified properties of the immediate
> > parent bus and device"? They make the result ver much *not* a "dev
> > path" in the qdev sense...
>
> In order to try to get a unique string. Without looking into device
> properties, two e1000s would both be:
>
> /main-system-bus/pci.0/e1000
> /main-system-bus/pci.0/e1000
>
> Which is no better than simply "e1000" and would require us to fall back
> to instance ids again. The goal here is that anything that makes use of
> passing a dev when registering a vmstate gets an instance id of zero.
You already got the information you need, you just put it in the wrong place.
The canonical ID for the device could be its bus address. In practice we'd
probably want to allow the user to specify it by name, provided these are
unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
as an aias for [...]:_09.0. Device names have a restricted namespace, so we
can use an initial prefix to disambiguate a name/label from a bus address.
For busses that don't have a consistent addressing scheme then some sort of
instance ID is unavoidable. I guess it may be possible to invent something
based on other device properties (e.g. address of the first IO port/memory
region).
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 13:09 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-14 13:09 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, Markus Armbruster, qemu-devel, avi, kraxel
> > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
There's a device missing between the main system bus and the pci bus. Should
be something like:
/main-system-bus/piix4-pcihost/pci.0/_09.0
> > Could you explain why you add "identified properties of the immediate
> > parent bus and device"? They make the result ver much *not* a "dev
> > path" in the qdev sense...
>
> In order to try to get a unique string. Without looking into device
> properties, two e1000s would both be:
>
> /main-system-bus/pci.0/e1000
> /main-system-bus/pci.0/e1000
>
> Which is no better than simply "e1000" and would require us to fall back
> to instance ids again. The goal here is that anything that makes use of
> passing a dev when registering a vmstate gets an instance id of zero.
You already got the information you need, you just put it in the wrong place.
The canonical ID for the device could be its bus address. In practice we'd
probably want to allow the user to specify it by name, provided these are
unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
as an aias for [...]:_09.0. Device names have a restricted namespace, so we
can use an initial prefix to disambiguate a name/label from a bus address.
For busses that don't have a consistent addressing scheme then some sort of
instance ID is unavoidable. I guess it may be possible to invent something
based on other device properties (e.g. address of the first IO port/memory
region).
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 13:09 ` Paul Brook
@ 2010-06-14 15:29 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 15:29 UTC (permalink / raw)
To: Paul Brook; +Cc: Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>
> There's a device missing between the main system bus and the pci bus. Should
> be something like:
>
> /main-system-bus/piix4-pcihost/pci.0/_09.0
Ok, I can easily come up with:
/System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
to expand the previous output. Code below.
> > > Could you explain why you add "identified properties of the immediate
> > > parent bus and device"? They make the result ver much *not* a "dev
> > > path" in the qdev sense...
> >
> > In order to try to get a unique string. Without looking into device
> > properties, two e1000s would both be:
> >
> > /main-system-bus/pci.0/e1000
> > /main-system-bus/pci.0/e1000
> >
> > Which is no better than simply "e1000" and would require us to fall back
> > to instance ids again. The goal here is that anything that makes use of
> > passing a dev when registering a vmstate gets an instance id of zero.
>
> You already got the information you need, you just put it in the wrong place.
> The canonical ID for the device could be its bus address. In practice we'd
> probably want to allow the user to specify it by name, provided these are
> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
> as an aias for [...]:_09.0.
Sure, if there was a guaranteed unique char* on a DeviceState that was
consistent between guest invocations, we could just use that instead. I
suppose all devices could have a global system id property and if that
was present we'd use that instead of creating the device path.
> Device names have a restricted namespace, so we
> can use an initial prefix to disambiguate a name/label from a bus address.
I'm not sure it's necessary. It seems like it would only be necessary
to differentiate the two if we wanted to translate between namespaces.
But I think it's reasonable to require that if a global name is
provided, it must always be provided for the life of the VM.
> For busses that don't have a consistent addressing scheme then some sort of
> instance ID is unavoidable. I guess it may be possible to invent something
> based on other device properties (e.g. address of the first IO port/memory
> region).
Instance IDs aren't always bad, we just run into trouble with hotplug
and maybe creating unique ramblock names. But, such busses typically
don't support hotplug and don't have multiple instances of the same
device on the bus, so I don't expect us to hit many issues there as long
as we can get a stable address path. Thanks,
Alex
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
static int qdev_strprint_path_props(DeviceState *dev, Property *props,
char *buf, size_t len)
{
int offset = 0;
char pbuf[64];
if (!props)
return 0;
while (props->name) {
if (props->info->flags & PROP_FLAG_PATH) {
if (props->info->print) {
props->info->print(dev, props, pbuf, sizeof(pbuf));
offset += snprintf(buf + offset, len - offset, "/_%s", pbuf);
}
}
props++;
}
return offset;
}
static int qdev_strprint_dev(DeviceState *dev, char *buf, size_t len);
static int qdev_strprint_bus(DeviceState *dev, char *buf, size_t len)
{
int offset = 0;
if (dev->parent_bus->parent)
offset += qdev_strprint_dev(dev->parent_bus->parent, buf, len);
offset += snprintf(buf + offset, len - offset, "/%s/%s",
dev->parent_bus->info->name, dev->parent_bus->name);
offset += qdev_strprint_path_props(dev, dev->parent_bus->info->props,
buf + offset, len - offset);
return offset;
}
static int qdev_strprint_dev(DeviceState *dev, char *buf, size_t len)
{
int offset = 0;
if (dev->parent_bus)
offset += qdev_strprint_bus(dev, buf, len);
offset += snprintf(buf + offset, len - offset, "/%s", dev->info->name);
offset += qdev_strprint_path_props(dev, dev->info->props,
buf + offset, len - offset);
if (dev->id)
offset += snprintf(buf + offset, len - offset, "/%s", dev->id);
return offset;
}
char *qdev_get_dev_path(DeviceState *dev)
{
char buf[256] = "";
if (!dev)
return NULL;
qdev_strprint_dev(dev, buf, sizeof(buf));
return qemu_strdup(buf);
}
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 15:29 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 15:29 UTC (permalink / raw)
To: Paul Brook; +Cc: chrisw, kvm, Markus Armbruster, qemu-devel, avi, kraxel
On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>
> There's a device missing between the main system bus and the pci bus. Should
> be something like:
>
> /main-system-bus/piix4-pcihost/pci.0/_09.0
Ok, I can easily come up with:
/System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
to expand the previous output. Code below.
> > > Could you explain why you add "identified properties of the immediate
> > > parent bus and device"? They make the result ver much *not* a "dev
> > > path" in the qdev sense...
> >
> > In order to try to get a unique string. Without looking into device
> > properties, two e1000s would both be:
> >
> > /main-system-bus/pci.0/e1000
> > /main-system-bus/pci.0/e1000
> >
> > Which is no better than simply "e1000" and would require us to fall back
> > to instance ids again. The goal here is that anything that makes use of
> > passing a dev when registering a vmstate gets an instance id of zero.
>
> You already got the information you need, you just put it in the wrong place.
> The canonical ID for the device could be its bus address. In practice we'd
> probably want to allow the user to specify it by name, provided these are
> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
> as an aias for [...]:_09.0.
Sure, if there was a guaranteed unique char* on a DeviceState that was
consistent between guest invocations, we could just use that instead. I
suppose all devices could have a global system id property and if that
was present we'd use that instead of creating the device path.
> Device names have a restricted namespace, so we
> can use an initial prefix to disambiguate a name/label from a bus address.
I'm not sure it's necessary. It seems like it would only be necessary
to differentiate the two if we wanted to translate between namespaces.
But I think it's reasonable to require that if a global name is
provided, it must always be provided for the life of the VM.
> For busses that don't have a consistent addressing scheme then some sort of
> instance ID is unavoidable. I guess it may be possible to invent something
> based on other device properties (e.g. address of the first IO port/memory
> region).
Instance IDs aren't always bad, we just run into trouble with hotplug
and maybe creating unique ramblock names. But, such busses typically
don't support hotplug and don't have multiple instances of the same
device on the bus, so I don't expect us to hit many issues there as long
as we can get a stable address path. Thanks,
Alex
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
static int qdev_strprint_path_props(DeviceState *dev, Property *props,
char *buf, size_t len)
{
int offset = 0;
char pbuf[64];
if (!props)
return 0;
while (props->name) {
if (props->info->flags & PROP_FLAG_PATH) {
if (props->info->print) {
props->info->print(dev, props, pbuf, sizeof(pbuf));
offset += snprintf(buf + offset, len - offset, "/_%s", pbuf);
}
}
props++;
}
return offset;
}
static int qdev_strprint_dev(DeviceState *dev, char *buf, size_t len);
static int qdev_strprint_bus(DeviceState *dev, char *buf, size_t len)
{
int offset = 0;
if (dev->parent_bus->parent)
offset += qdev_strprint_dev(dev->parent_bus->parent, buf, len);
offset += snprintf(buf + offset, len - offset, "/%s/%s",
dev->parent_bus->info->name, dev->parent_bus->name);
offset += qdev_strprint_path_props(dev, dev->parent_bus->info->props,
buf + offset, len - offset);
return offset;
}
static int qdev_strprint_dev(DeviceState *dev, char *buf, size_t len)
{
int offset = 0;
if (dev->parent_bus)
offset += qdev_strprint_bus(dev, buf, len);
offset += snprintf(buf + offset, len - offset, "/%s", dev->info->name);
offset += qdev_strprint_path_props(dev, dev->info->props,
buf + offset, len - offset);
if (dev->id)
offset += snprintf(buf + offset, len - offset, "/%s", dev->id);
return offset;
}
char *qdev_get_dev_path(DeviceState *dev)
{
char buf[256] = "";
if (!dev)
return NULL;
qdev_strprint_dev(dev, buf, sizeof(buf));
return qemu_strdup(buf);
}
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 15:29 ` Alex Williamson
@ 2010-06-14 15:42 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-14 15:42 UTC (permalink / raw)
To: Alex Williamson; +Cc: Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >
> > There's a device missing between the main system bus and the pci bus.
> > Should be something like:
> >
> > /main-system-bus/piix4-pcihost/pci.0/_09.0
>
> Ok, I can easily come up with:
>
> /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virti
> o-blk
No. Now you've got way to many elements in the path. My point is that you
replace the name of the device with the bus address of the device.
However you determine the element names the path should be /busname/devicename
pairs. I'm undecided whether the root element should be the main system bus,
or a system device node that contains the main system bus.
> > You already got the information you need, you just put it in the wrong
> > place. The canonical ID for the device could be its bus address. In
> > practice we'd probably want to allow the user to specify it by name,
> > provided these are unique. e.g. in the above machine we could accept
> > [...]/virtiio-blk-pci would as an aias for [...]:_09.0.
>
> Sure, if there was a guaranteed unique char* on a DeviceState that was
> consistent between guest invocations, we could just use that instead. I
> suppose all devices could have a global system id property and if that
> was present we'd use that instead of creating the device path.
All we require is some way of uniquely addressing each device on the bus. For
PCI that's trivial (devfn). For other busses we get to pick something
appropriate.
> > Device names have a restricted namespace, so we
> > can use an initial prefix to disambiguate a name/label from a bus
> > address.
>
> I'm not sure it's necessary. It seems like it would only be necessary
> to differentiate the two if we wanted to translate between namespaces.
> But I think it's reasonable to require that if a global name is
> provided, it must always be provided for the life of the VM.
I don't think requiring that all devices are given a globally unique name is
going to fly. locally (per-bus) unique user-specified are still a PITA, but
may be acceptable. Having a canonical addressing system that's independent of
user assigned IDs seems like a good thing.
> > For busses that don't have a consistent addressing scheme then some sort
> > of instance ID is unavoidable. I guess it may be possible to invent
> > something based on other device properties (e.g. address of the first IO
> > port/memory region).
>
> Instance IDs aren't always bad, we just run into trouble with hotplug
> and maybe creating unique ramblock names. But, such busses typically
> don't support hotplug and don't have multiple instances of the same
> device on the bus, so I don't expect us to hit many issues there as long
> as we can get a stable address path. Thanks,
Simple consecutive instance IDs are inherently unstable. They depend on teh
order of device creation. The ID really wants to be something that can be
reliably determined from the device bus itself (and/or its interaction with
its parent bus).
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 15:42 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-14 15:42 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, Markus Armbruster, qemu-devel, avi, kraxel
> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >
> > There's a device missing between the main system bus and the pci bus.
> > Should be something like:
> >
> > /main-system-bus/piix4-pcihost/pci.0/_09.0
>
> Ok, I can easily come up with:
>
> /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virti
> o-blk
No. Now you've got way to many elements in the path. My point is that you
replace the name of the device with the bus address of the device.
However you determine the element names the path should be /busname/devicename
pairs. I'm undecided whether the root element should be the main system bus,
or a system device node that contains the main system bus.
> > You already got the information you need, you just put it in the wrong
> > place. The canonical ID for the device could be its bus address. In
> > practice we'd probably want to allow the user to specify it by name,
> > provided these are unique. e.g. in the above machine we could accept
> > [...]/virtiio-blk-pci would as an aias for [...]:_09.0.
>
> Sure, if there was a guaranteed unique char* on a DeviceState that was
> consistent between guest invocations, we could just use that instead. I
> suppose all devices could have a global system id property and if that
> was present we'd use that instead of creating the device path.
All we require is some way of uniquely addressing each device on the bus. For
PCI that's trivial (devfn). For other busses we get to pick something
appropriate.
> > Device names have a restricted namespace, so we
> > can use an initial prefix to disambiguate a name/label from a bus
> > address.
>
> I'm not sure it's necessary. It seems like it would only be necessary
> to differentiate the two if we wanted to translate between namespaces.
> But I think it's reasonable to require that if a global name is
> provided, it must always be provided for the life of the VM.
I don't think requiring that all devices are given a globally unique name is
going to fly. locally (per-bus) unique user-specified are still a PITA, but
may be acceptable. Having a canonical addressing system that's independent of
user assigned IDs seems like a good thing.
> > For busses that don't have a consistent addressing scheme then some sort
> > of instance ID is unavoidable. I guess it may be possible to invent
> > something based on other device properties (e.g. address of the first IO
> > port/memory region).
>
> Instance IDs aren't always bad, we just run into trouble with hotplug
> and maybe creating unique ramblock names. But, such busses typically
> don't support hotplug and don't have multiple instances of the same
> device on the bus, so I don't expect us to hit many issues there as long
> as we can get a stable address path. Thanks,
Simple consecutive instance IDs are inherently unstable. They depend on teh
order of device creation. The ID really wants to be something that can be
reliably determined from the device bus itself (and/or its interaction with
its parent bus).
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 15:29 ` Alex Williamson
@ 2010-06-14 16:00 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-14 16:00 UTC (permalink / raw)
To: Alex Williamson
Cc: Paul Brook, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
Alex Williamson wrote:
> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
>>>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>> There's a device missing between the main system bus and the pci bus. Should
>> be something like:
>>
>> /main-system-bus/piix4-pcihost/pci.0/_09.0
>
> Ok, I can easily come up with:
>
> /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
First two elements are redundant, '/' already stands for the main system
bus. Then I don't get what last element expresses (the target device is
virtio-blk-pci). Is this due to some vmstate layout? But that should not
be part into qdev paths (maybe I'm missing your use case).
And instead of introducing another hierarchy level with the bus address,
I would also prefer to add this as prefix or suffix to the device name,
e.g. <driver>.<busaddr>.
>
> to expand the previous output. Code below.
>
>>>> Could you explain why you add "identified properties of the immediate
>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>> path" in the qdev sense...
>>> In order to try to get a unique string. Without looking into device
>>> properties, two e1000s would both be:
>>>
>>> /main-system-bus/pci.0/e1000
>>> /main-system-bus/pci.0/e1000
>>>
>>> Which is no better than simply "e1000" and would require us to fall back
>>> to instance ids again. The goal here is that anything that makes use of
>>> passing a dev when registering a vmstate gets an instance id of zero.
>> You already got the information you need, you just put it in the wrong place.
>> The canonical ID for the device could be its bus address. In practice we'd
>> probably want to allow the user to specify it by name, provided these are
>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>> as an aias for [...]:_09.0.
>
> Sure, if there was a guaranteed unique char* on a DeviceState that was
> consistent between guest invocations, we could just use that instead. I
> suppose all devices could have a global system id property and if that
> was present we'd use that instead of creating the device path.
>
>> Device names have a restricted namespace, so we
>> can use an initial prefix to disambiguate a name/label from a bus address.
>
> I'm not sure it's necessary. It seems like it would only be necessary
> to differentiate the two if we wanted to translate between namespaces.
> But I think it's reasonable to require that if a global name is
> provided, it must always be provided for the life of the VM.
>
>> For busses that don't have a consistent addressing scheme then some sort of
>> instance ID is unavoidable. I guess it may be possible to invent something
>> based on other device properties (e.g. address of the first IO port/memory
>> region).
>
> Instance IDs aren't always bad, we just run into trouble with hotplug
> and maybe creating unique ramblock names. But, such busses typically
> don't support hotplug and don't have multiple instances of the same
> device on the bus, so I don't expect us to hit many issues there as long
> as we can get a stable address path. Thanks,
>
If stable instance numbers are required, we could simply keep them in
DeviceState and search for the smallest free one on additions. Actually,
I'm more in favor of this direction than including the bus address. That
way we could keep a canonical format across all buses and do not have to
provide possibly complex ID generation rules for each of them.
BTW, the problem isn't truly solved by printing paths. We also need to
parse them. It would be counterproductive if such paths ever see the
light of day (ie. "leak" outside vmstate) and a user tries to hack it
into the monitor or pass it on the command line. With my series, I'm
currently able to process paths like this one:
/i440FX-pcihost.0/pci.0/PIIX4_PM.0/i2c/smbus-eeprom.6
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 16:00 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-14 16:00 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, kraxel, avi, Paul Brook
Alex Williamson wrote:
> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
>>>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>> There's a device missing between the main system bus and the pci bus. Should
>> be something like:
>>
>> /main-system-bus/piix4-pcihost/pci.0/_09.0
>
> Ok, I can easily come up with:
>
> /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
First two elements are redundant, '/' already stands for the main system
bus. Then I don't get what last element expresses (the target device is
virtio-blk-pci). Is this due to some vmstate layout? But that should not
be part into qdev paths (maybe I'm missing your use case).
And instead of introducing another hierarchy level with the bus address,
I would also prefer to add this as prefix or suffix to the device name,
e.g. <driver>.<busaddr>.
>
> to expand the previous output. Code below.
>
>>>> Could you explain why you add "identified properties of the immediate
>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>> path" in the qdev sense...
>>> In order to try to get a unique string. Without looking into device
>>> properties, two e1000s would both be:
>>>
>>> /main-system-bus/pci.0/e1000
>>> /main-system-bus/pci.0/e1000
>>>
>>> Which is no better than simply "e1000" and would require us to fall back
>>> to instance ids again. The goal here is that anything that makes use of
>>> passing a dev when registering a vmstate gets an instance id of zero.
>> You already got the information you need, you just put it in the wrong place.
>> The canonical ID for the device could be its bus address. In practice we'd
>> probably want to allow the user to specify it by name, provided these are
>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>> as an aias for [...]:_09.0.
>
> Sure, if there was a guaranteed unique char* on a DeviceState that was
> consistent between guest invocations, we could just use that instead. I
> suppose all devices could have a global system id property and if that
> was present we'd use that instead of creating the device path.
>
>> Device names have a restricted namespace, so we
>> can use an initial prefix to disambiguate a name/label from a bus address.
>
> I'm not sure it's necessary. It seems like it would only be necessary
> to differentiate the two if we wanted to translate between namespaces.
> But I think it's reasonable to require that if a global name is
> provided, it must always be provided for the life of the VM.
>
>> For busses that don't have a consistent addressing scheme then some sort of
>> instance ID is unavoidable. I guess it may be possible to invent something
>> based on other device properties (e.g. address of the first IO port/memory
>> region).
>
> Instance IDs aren't always bad, we just run into trouble with hotplug
> and maybe creating unique ramblock names. But, such busses typically
> don't support hotplug and don't have multiple instances of the same
> device on the bus, so I don't expect us to hit many issues there as long
> as we can get a stable address path. Thanks,
>
If stable instance numbers are required, we could simply keep them in
DeviceState and search for the smallest free one on additions. Actually,
I'm more in favor of this direction than including the bus address. That
way we could keep a canonical format across all buses and do not have to
provide possibly complex ID generation rules for each of them.
BTW, the problem isn't truly solved by printing paths. We also need to
parse them. It would be counterproductive if such paths ever see the
light of day (ie. "leak" outside vmstate) and a user tries to hack it
into the monitor or pass it on the command line. With my series, I'm
currently able to process paths like this one:
/i440FX-pcihost.0/pci.0/PIIX4_PM.0/i2c/smbus-eeprom.6
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 16:00 ` Jan Kiszka
@ 2010-06-14 16:38 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 16:38 UTC (permalink / raw)
To: Jan Kiszka
Cc: Paul Brook, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> >>>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >> There's a device missing between the main system bus and the pci bus. Should
> >> be something like:
> >>
> >> /main-system-bus/piix4-pcihost/pci.0/_09.0
> >
> > Ok, I can easily come up with:
> >
> > /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
>
> First two elements are redundant, '/' already stands for the main system
> bus.
Ok, we can start printing after the system bus.
> Then I don't get what last element expresses (the target device is
> virtio-blk-pci). Is this due to some vmstate layout? But that should not
> be part into qdev paths (maybe I'm missing your use case).
Sorry, I wasn't clear about that. My printf is in the savevm code,
after it's already appended the idstr passed in from the device. The
device path in the example above ends at virtio-blk-pci. That's the
dev->info->name of the device passed into this function.
> And instead of introducing another hierarchy level with the bus address,
> I would also prefer to add this as prefix or suffix to the device name,
> e.g. <driver>.<busaddr>.
That's what I had started with. The first post in this thread has
"pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
unnecessary there, but I also prefer something along those lines. For
PCI it'd make sense to have <name>:<addr>, which comes out to
"pci.0:09.0". (Maybe rather than flagging properties as being relevant
to the path and printing them generically, we should extract specific
properties based on the bus type.)
> >> For busses that don't have a consistent addressing scheme then some sort of
> >> instance ID is unavoidable. I guess it may be possible to invent something
> >> based on other device properties (e.g. address of the first IO port/memory
> >> region).
> >
> > Instance IDs aren't always bad, we just run into trouble with hotplug
> > and maybe creating unique ramblock names. But, such busses typically
> > don't support hotplug and don't have multiple instances of the same
> > device on the bus, so I don't expect us to hit many issues there as long
> > as we can get a stable address path. Thanks,
> >
>
> If stable instance numbers are required, we could simply keep them in
> DeviceState and search for the smallest free one on additions. Actually,
> I'm more in favor of this direction than including the bus address. That
> way we could keep a canonical format across all buses and do not have to
> provide possibly complex ID generation rules for each of them.
I started down that path, but it still breaks for hotplug. If we start
a VM with two e1000 NICs, then remove the first, we can no longer
migrate because the target can't represent having a single e1000 with a
non-zero instance ID.
> BTW, the problem isn't truly solved by printing paths. We also need to
> parse them. It would be counterproductive if such paths ever see the
> light of day (ie. "leak" outside vmstate) and a user tries to hack it
> into the monitor or pass it on the command line. With my series, I'm
> currently able to process paths like this one:
>
> /i440FX-pcihost.0/pci.0/PIIX4_PM.0/i2c/smbus-eeprom.6
Yes, these are only intended for internal use, but we should get them to
sync up as much as possible. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 16:38 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 16:38 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, kraxel, avi, Paul Brook
On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> >>>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
> >> There's a device missing between the main system bus and the pci bus. Should
> >> be something like:
> >>
> >> /main-system-bus/piix4-pcihost/pci.0/_09.0
> >
> > Ok, I can easily come up with:
> >
> > /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
>
> First two elements are redundant, '/' already stands for the main system
> bus.
Ok, we can start printing after the system bus.
> Then I don't get what last element expresses (the target device is
> virtio-blk-pci). Is this due to some vmstate layout? But that should not
> be part into qdev paths (maybe I'm missing your use case).
Sorry, I wasn't clear about that. My printf is in the savevm code,
after it's already appended the idstr passed in from the device. The
device path in the example above ends at virtio-blk-pci. That's the
dev->info->name of the device passed into this function.
> And instead of introducing another hierarchy level with the bus address,
> I would also prefer to add this as prefix or suffix to the device name,
> e.g. <driver>.<busaddr>.
That's what I had started with. The first post in this thread has
"pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
unnecessary there, but I also prefer something along those lines. For
PCI it'd make sense to have <name>:<addr>, which comes out to
"pci.0:09.0". (Maybe rather than flagging properties as being relevant
to the path and printing them generically, we should extract specific
properties based on the bus type.)
> >> For busses that don't have a consistent addressing scheme then some sort of
> >> instance ID is unavoidable. I guess it may be possible to invent something
> >> based on other device properties (e.g. address of the first IO port/memory
> >> region).
> >
> > Instance IDs aren't always bad, we just run into trouble with hotplug
> > and maybe creating unique ramblock names. But, such busses typically
> > don't support hotplug and don't have multiple instances of the same
> > device on the bus, so I don't expect us to hit many issues there as long
> > as we can get a stable address path. Thanks,
> >
>
> If stable instance numbers are required, we could simply keep them in
> DeviceState and search for the smallest free one on additions. Actually,
> I'm more in favor of this direction than including the bus address. That
> way we could keep a canonical format across all buses and do not have to
> provide possibly complex ID generation rules for each of them.
I started down that path, but it still breaks for hotplug. If we start
a VM with two e1000 NICs, then remove the first, we can no longer
migrate because the target can't represent having a single e1000 with a
non-zero instance ID.
> BTW, the problem isn't truly solved by printing paths. We also need to
> parse them. It would be counterproductive if such paths ever see the
> light of day (ie. "leak" outside vmstate) and a user tries to hack it
> into the monitor or pass it on the command line. With my series, I'm
> currently able to process paths like this one:
>
> /i440FX-pcihost.0/pci.0/PIIX4_PM.0/i2c/smbus-eeprom.6
Yes, these are only intended for internal use, but we should get them to
sync up as much as possible. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 16:38 ` Alex Williamson
@ 2010-06-14 16:49 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-14 16:49 UTC (permalink / raw)
To: Alex Williamson
Cc: Paul Brook, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
Alex Williamson wrote:
> On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
>> Alex Williamson wrote:
>>> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
>>>>>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>>>> There's a device missing between the main system bus and the pci bus. Should
>>>> be something like:
>>>>
>>>> /main-system-bus/piix4-pcihost/pci.0/_09.0
>>> Ok, I can easily come up with:
>>>
>>> /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
>> First two elements are redundant, '/' already stands for the main system
>> bus.
>
> Ok, we can start printing after the system bus.
>
>> Then I don't get what last element expresses (the target device is
>> virtio-blk-pci). Is this due to some vmstate layout? But that should not
>> be part into qdev paths (maybe I'm missing your use case).
>
> Sorry, I wasn't clear about that. My printf is in the savevm code,
> after it's already appended the idstr passed in from the device. The
> device path in the example above ends at virtio-blk-pci. That's the
> dev->info->name of the device passed into this function.
>
>> And instead of introducing another hierarchy level with the bus address,
>> I would also prefer to add this as prefix or suffix to the device name,
>> e.g. <driver>.<busaddr>.
>
> That's what I had started with. The first post in this thread has
> "pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
> unnecessary there, but I also prefer something along those lines. For
> PCI it'd make sense to have <name>:<addr>, which comes out to
> "pci.0:09.0". (Maybe rather than flagging properties as being relevant
> to the path and printing them generically, we should extract specific
> properties based on the bus type.)
Not bus.addr, driver.addr. We only have one PCI bus here, not as many as
there are slots on that bus.
>
>>>> For busses that don't have a consistent addressing scheme then some sort of
>>>> instance ID is unavoidable. I guess it may be possible to invent something
>>>> based on other device properties (e.g. address of the first IO port/memory
>>>> region).
>>> Instance IDs aren't always bad, we just run into trouble with hotplug
>>> and maybe creating unique ramblock names. But, such busses typically
>>> don't support hotplug and don't have multiple instances of the same
>>> device on the bus, so I don't expect us to hit many issues there as long
>>> as we can get a stable address path. Thanks,
>>>
>> If stable instance numbers are required, we could simply keep them in
>> DeviceState and search for the smallest free one on additions. Actually,
>> I'm more in favor of this direction than including the bus address. That
>> way we could keep a canonical format across all buses and do not have to
>> provide possibly complex ID generation rules for each of them.
>
> I started down that path, but it still breaks for hotplug. If we start
> a VM with two e1000 NICs, then remove the first, we can no longer
> migrate because the target can't represent having a single e1000 with a
> non-zero instance ID.
That's indeed a good point.
Still, I'm worried about having to define numbering schemes for all the
buses qemu supports. Maybe we can run a mixture: address-based for
hotplug-capably buses (they tend to be cooperative in this regard) and
simple instance numbers for the rest, likely the majority.
>
>> BTW, the problem isn't truly solved by printing paths. We also need to
>> parse them. It would be counterproductive if such paths ever see the
>> light of day (ie. "leak" outside vmstate) and a user tries to hack it
>> into the monitor or pass it on the command line. With my series, I'm
>> currently able to process paths like this one:
>>
>> /i440FX-pcihost.0/pci.0/PIIX4_PM.0/i2c/smbus-eeprom.6
>
> Yes, these are only intended for internal use, but we should get them to
> sync up as much as possible. Thanks,
Unless there is a good reason, the match should be 100%.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 16:49 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-14 16:49 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, kraxel, avi, Paul Brook
Alex Williamson wrote:
> On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
>> Alex Williamson wrote:
>>> On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
>>>>>>> "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>>>> There's a device missing between the main system bus and the pci bus. Should
>>>> be something like:
>>>>
>>>> /main-system-bus/piix4-pcihost/pci.0/_09.0
>>> Ok, I can easily come up with:
>>>
>>> /System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
>> First two elements are redundant, '/' already stands for the main system
>> bus.
>
> Ok, we can start printing after the system bus.
>
>> Then I don't get what last element expresses (the target device is
>> virtio-blk-pci). Is this due to some vmstate layout? But that should not
>> be part into qdev paths (maybe I'm missing your use case).
>
> Sorry, I wasn't clear about that. My printf is in the savevm code,
> after it's already appended the idstr passed in from the device. The
> device path in the example above ends at virtio-blk-pci. That's the
> dev->info->name of the device passed into this function.
>
>> And instead of introducing another hierarchy level with the bus address,
>> I would also prefer to add this as prefix or suffix to the device name,
>> e.g. <driver>.<busaddr>.
>
> That's what I had started with. The first post in this thread has
> "pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
> unnecessary there, but I also prefer something along those lines. For
> PCI it'd make sense to have <name>:<addr>, which comes out to
> "pci.0:09.0". (Maybe rather than flagging properties as being relevant
> to the path and printing them generically, we should extract specific
> properties based on the bus type.)
Not bus.addr, driver.addr. We only have one PCI bus here, not as many as
there are slots on that bus.
>
>>>> For busses that don't have a consistent addressing scheme then some sort of
>>>> instance ID is unavoidable. I guess it may be possible to invent something
>>>> based on other device properties (e.g. address of the first IO port/memory
>>>> region).
>>> Instance IDs aren't always bad, we just run into trouble with hotplug
>>> and maybe creating unique ramblock names. But, such busses typically
>>> don't support hotplug and don't have multiple instances of the same
>>> device on the bus, so I don't expect us to hit many issues there as long
>>> as we can get a stable address path. Thanks,
>>>
>> If stable instance numbers are required, we could simply keep them in
>> DeviceState and search for the smallest free one on additions. Actually,
>> I'm more in favor of this direction than including the bus address. That
>> way we could keep a canonical format across all buses and do not have to
>> provide possibly complex ID generation rules for each of them.
>
> I started down that path, but it still breaks for hotplug. If we start
> a VM with two e1000 NICs, then remove the first, we can no longer
> migrate because the target can't represent having a single e1000 with a
> non-zero instance ID.
That's indeed a good point.
Still, I'm worried about having to define numbering schemes for all the
buses qemu supports. Maybe we can run a mixture: address-based for
hotplug-capably buses (they tend to be cooperative in this regard) and
simple instance numbers for the rest, likely the majority.
>
>> BTW, the problem isn't truly solved by printing paths. We also need to
>> parse them. It would be counterproductive if such paths ever see the
>> light of day (ie. "leak" outside vmstate) and a user tries to hack it
>> into the monitor or pass it on the command line. With my series, I'm
>> currently able to process paths like this one:
>>
>> /i440FX-pcihost.0/pci.0/PIIX4_PM.0/i2c/smbus-eeprom.6
>
> Yes, these are only intended for internal use, but we should get them to
> sync up as much as possible. Thanks,
Unless there is a good reason, the match should be 100%.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 16:49 ` Jan Kiszka
@ 2010-06-14 18:35 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 18:35 UTC (permalink / raw)
To: Jan Kiszka
Cc: Paul Brook, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> >> And instead of introducing another hierarchy level with the bus address,
> >> I would also prefer to add this as prefix or suffix to the device name,
> >> e.g. <driver>.<busaddr>.
> >
> > That's what I had started with. The first post in this thread has
> > "pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
> > unnecessary there, but I also prefer something along those lines. For
> > PCI it'd make sense to have <name>:<addr>, which comes out to
> > "pci.0:09.0". (Maybe rather than flagging properties as being relevant
> > to the path and printing them generically, we should extract specific
> > properties based on the bus type.)
>
> Not bus.addr, driver.addr. We only have one PCI bus here, not as many as
> there are slots on that bus.
Ok, I can get it down to something like:
/i440FX-pcihost/pci.0/virtio-blk-pci,09.0
The addr on the device is initially a little non-intuitive to me since
it's a property of the bus, but I guess it make sense if we think of
that level as slot, which includes an address and driver.
> >>>> For busses that don't have a consistent addressing scheme then some sort of
> >>>> instance ID is unavoidable. I guess it may be possible to invent something
> >>>> based on other device properties (e.g. address of the first IO port/memory
> >>>> region).
> >>> Instance IDs aren't always bad, we just run into trouble with hotplug
> >>> and maybe creating unique ramblock names. But, such busses typically
> >>> don't support hotplug and don't have multiple instances of the same
> >>> device on the bus, so I don't expect us to hit many issues there as long
> >>> as we can get a stable address path. Thanks,
> >>>
> >> If stable instance numbers are required, we could simply keep them in
> >> DeviceState and search for the smallest free one on additions. Actually,
> >> I'm more in favor of this direction than including the bus address. That
> >> way we could keep a canonical format across all buses and do not have to
> >> provide possibly complex ID generation rules for each of them.
> >
> > I started down that path, but it still breaks for hotplug. If we start
> > a VM with two e1000 NICs, then remove the first, we can no longer
> > migrate because the target can't represent having a single e1000 with a
> > non-zero instance ID.
>
> That's indeed a good point.
>
> Still, I'm worried about having to define numbering schemes for all the
> buses qemu supports. Maybe we can run a mixture: address-based for
> hotplug-capably buses (they tend to be cooperative in this regard) and
> simple instance numbers for the rest, likely the majority.
Yep, I share that concern, which is I say instance numbers aren't always
bad. If we have devices that we don't care about doing hotplug on, we
can live with instance numbers. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 18:35 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 18:35 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, kraxel, avi, Paul Brook
On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> >> And instead of introducing another hierarchy level with the bus address,
> >> I would also prefer to add this as prefix or suffix to the device name,
> >> e.g. <driver>.<busaddr>.
> >
> > That's what I had started with. The first post in this thread has
> > "pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
> > unnecessary there, but I also prefer something along those lines. For
> > PCI it'd make sense to have <name>:<addr>, which comes out to
> > "pci.0:09.0". (Maybe rather than flagging properties as being relevant
> > to the path and printing them generically, we should extract specific
> > properties based on the bus type.)
>
> Not bus.addr, driver.addr. We only have one PCI bus here, not as many as
> there are slots on that bus.
Ok, I can get it down to something like:
/i440FX-pcihost/pci.0/virtio-blk-pci,09.0
The addr on the device is initially a little non-intuitive to me since
it's a property of the bus, but I guess it make sense if we think of
that level as slot, which includes an address and driver.
> >>>> For busses that don't have a consistent addressing scheme then some sort of
> >>>> instance ID is unavoidable. I guess it may be possible to invent something
> >>>> based on other device properties (e.g. address of the first IO port/memory
> >>>> region).
> >>> Instance IDs aren't always bad, we just run into trouble with hotplug
> >>> and maybe creating unique ramblock names. But, such busses typically
> >>> don't support hotplug and don't have multiple instances of the same
> >>> device on the bus, so I don't expect us to hit many issues there as long
> >>> as we can get a stable address path. Thanks,
> >>>
> >> If stable instance numbers are required, we could simply keep them in
> >> DeviceState and search for the smallest free one on additions. Actually,
> >> I'm more in favor of this direction than including the bus address. That
> >> way we could keep a canonical format across all buses and do not have to
> >> provide possibly complex ID generation rules for each of them.
> >
> > I started down that path, but it still breaks for hotplug. If we start
> > a VM with two e1000 NICs, then remove the first, we can no longer
> > migrate because the target can't represent having a single e1000 with a
> > non-zero instance ID.
>
> That's indeed a good point.
>
> Still, I'm worried about having to define numbering schemes for all the
> buses qemu supports. Maybe we can run a mixture: address-based for
> hotplug-capably buses (they tend to be cooperative in this regard) and
> simple instance numbers for the rest, likely the majority.
Yep, I share that concern, which is I say instance numbers aren't always
bad. If we have devices that we don't care about doing hotplug on, we
can live with instance numbers. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
2010-06-14 7:02 ` [Qemu-devel] " Gerd Hoffmann
@ 2010-06-14 19:56 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 19:56 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: qemu-devel, kvm, avi, anthony, paul, chrisw
On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > 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.
>
> You'll need that for every bus along the way down to the device. Create
> a virtual machine with two lsi scsi host adapters, then attach a disk
> with scsi id 0 to each. Just the scsi id isn't good enougth to identify
> the device. You'll need the lsi pci address too.
Yep, see below.
> > For now, the only properties I've tagged as path
> > properties are PCI bus addresses and MAC addresses.
>
> mac address isn't needed here. You need the property which specifies
> the bus address. For PCI this obviously is the PCI address. For scsi
> the scsi id. For ISA you can use the I/O port base. virtio-serial the
> port number, ...
PCI: addr
SCSI: scsi-id
ISA: serial/parallel = iobase, others??
ide-drive: unit
I2C: address
virtio-serial doesn't seem to make a DeviceState per port, so I think it
can be skipped. I'm sure I'm still missing some...
That gives me the list below (printed from qdev_init()):
/i440FX-pcihost
/i440FX-pcihost/pci.0/i440FX.00.0
/i440FX-pcihost/pci.0/PIIX3.01.0
/i440FX-pcihost/pci.0/cirrus-vga.02.0
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x2f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/i82551.03.0
/i440FX-pcihost/pci.0/virtio-net-pci.04.0
/i440FX-pcihost/pci.0/e1000.05.0
/i440FX-pcihost/pci.0/rtl8139.06.0
/i440FX-pcihost/pci.0/pcnet.07.0
/i440FX-pcihost/pci.0/piix3-ide.01.1
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.0/ide-drive.0
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.0/ide-drive.1
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.1/ide-drive.0
/i440FX-pcihost/pci.0/PIIX4_PM.01.3
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.80
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.81
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.82
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.83
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.84
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.85
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.86
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.87
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.3
/i440FX-pcihost/pci.0/lsi53c895a.08.0
/i440FX-pcihost/pci.0/virtio-serial-pci.09.0
/i440FX-pcihost/pci.0/virtio-serial-pci.0a.0
/i440FX-pcihost/pci.0/virtio-blk-pci.0b.0
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
@ 2010-06-14 19:56 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 19:56 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: chrisw, kvm, qemu-devel, paul, avi
On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > 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.
>
> You'll need that for every bus along the way down to the device. Create
> a virtual machine with two lsi scsi host adapters, then attach a disk
> with scsi id 0 to each. Just the scsi id isn't good enougth to identify
> the device. You'll need the lsi pci address too.
Yep, see below.
> > For now, the only properties I've tagged as path
> > properties are PCI bus addresses and MAC addresses.
>
> mac address isn't needed here. You need the property which specifies
> the bus address. For PCI this obviously is the PCI address. For scsi
> the scsi id. For ISA you can use the I/O port base. virtio-serial the
> port number, ...
PCI: addr
SCSI: scsi-id
ISA: serial/parallel = iobase, others??
ide-drive: unit
I2C: address
virtio-serial doesn't seem to make a DeviceState per port, so I think it
can be skipped. I'm sure I'm still missing some...
That gives me the list below (printed from qdev_init()):
/i440FX-pcihost
/i440FX-pcihost/pci.0/i440FX.00.0
/i440FX-pcihost/pci.0/PIIX3.01.0
/i440FX-pcihost/pci.0/cirrus-vga.02.0
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x2f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/i82551.03.0
/i440FX-pcihost/pci.0/virtio-net-pci.04.0
/i440FX-pcihost/pci.0/e1000.05.0
/i440FX-pcihost/pci.0/rtl8139.06.0
/i440FX-pcihost/pci.0/pcnet.07.0
/i440FX-pcihost/pci.0/piix3-ide.01.1
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.0/ide-drive.0
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.0/ide-drive.1
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.1/ide-drive.0
/i440FX-pcihost/pci.0/PIIX4_PM.01.3
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.80
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.81
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.82
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.83
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.84
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.85
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.86
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.87
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.3
/i440FX-pcihost/pci.0/lsi53c895a.08.0
/i440FX-pcihost/pci.0/virtio-serial-pci.09.0
/i440FX-pcihost/pci.0/virtio-serial-pci.0a.0
/i440FX-pcihost/pci.0/virtio-blk-pci.0b.0
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 18:35 ` Alex Williamson
@ 2010-06-14 21:43 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-14 21:43 UTC (permalink / raw)
To: Alex Williamson
Cc: Jan Kiszka, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
> On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > Alex Williamson wrote:
> > > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> > >> And instead of introducing another hierarchy level with the bus
> > >> address, I would also prefer to add this as prefix or suffix to the
> > >> device name, e.g. <driver>.<busaddr>.
> > >
> > > That's what I had started with. The first post in this thread has
> > > "pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
> > > unnecessary there, but I also prefer something along those lines. For
> > > PCI it'd make sense to have <name>:<addr>, which comes out to
> > > "pci.0:09.0". (Maybe rather than flagging properties as being relevant
> > > to the path and printing them generically, we should extract specific
> > > properties based on the bus type.)
> >
> > Not bus.addr, driver.addr. We only have one PCI bus here, not as many as
> > there are slots on that bus.
>
> Ok, I can get it down to something like:
>
> /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
>
> The addr on the device is initially a little non-intuitive to me since
> it's a property of the bus, but I guess it make sense if we think of
> that level as slot, which includes an address and driver.
That indicates you're thinking about things the wrong way.
The point of this path is to uniquely identify an entity.
/i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
device. To identify a device attached to that bus all you need to know is the
devfn of the device.
For an end-user it may be helpful to allow devices to be identified by the
device type (assuming only one device of a particular type on that bus), or
specify the device type as a crude error checking mechanism. However we're
talking about canonical addresses. These need not include the device type.
Verifying that the device is actually what you expect is a separate problem,
and the device type is not sufficient for that.
i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
> > > I started down that path, but it still breaks for hotplug. If we start
> > > a VM with two e1000 NICs, then remove the first, we can no longer
> > > migrate because the target can't represent having a single e1000 with a
> > > non-zero instance ID.
> >
> > That's indeed a good point.
That's a feature. If you start with two NICs and remove the first, the chances
are that the second will be in a different place to the nice created in a
single-nic config. Allowing migration between these two will cause a PCI
device to suddenly change location. This is not physically or logically
possible, and everyone looses.
Hot-removing a nic and then hotplugging a new nic in the same location may
result in something that is reasonable to migrate.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 21:43 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-14 21:43 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, kraxel, avi
> On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > Alex Williamson wrote:
> > > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> > >> And instead of introducing another hierarchy level with the bus
> > >> address, I would also prefer to add this as prefix or suffix to the
> > >> device name, e.g. <driver>.<busaddr>.
> > >
> > > That's what I had started with. The first post in this thread has
> > > "pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
> > > unnecessary there, but I also prefer something along those lines. For
> > > PCI it'd make sense to have <name>:<addr>, which comes out to
> > > "pci.0:09.0". (Maybe rather than flagging properties as being relevant
> > > to the path and printing them generically, we should extract specific
> > > properties based on the bus type.)
> >
> > Not bus.addr, driver.addr. We only have one PCI bus here, not as many as
> > there are slots on that bus.
>
> Ok, I can get it down to something like:
>
> /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
>
> The addr on the device is initially a little non-intuitive to me since
> it's a property of the bus, but I guess it make sense if we think of
> that level as slot, which includes an address and driver.
That indicates you're thinking about things the wrong way.
The point of this path is to uniquely identify an entity.
/i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
device. To identify a device attached to that bus all you need to know is the
devfn of the device.
For an end-user it may be helpful to allow devices to be identified by the
device type (assuming only one device of a particular type on that bus), or
specify the device type as a crude error checking mechanism. However we're
talking about canonical addresses. These need not include the device type.
Verifying that the device is actually what you expect is a separate problem,
and the device type is not sufficient for that.
i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
> > > I started down that path, but it still breaks for hotplug. If we start
> > > a VM with two e1000 NICs, then remove the first, we can no longer
> > > migrate because the target can't represent having a single e1000 with a
> > > non-zero instance ID.
> >
> > That's indeed a good point.
That's a feature. If you start with two NICs and remove the first, the chances
are that the second will be in a different place to the nice created in a
single-nic config. Allowing migration between these two will cause a PCI
device to suddenly change location. This is not physically or logically
possible, and everyone looses.
Hot-removing a nic and then hotplugging a new nic in the same location may
result in something that is reasonable to migrate.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 21:43 ` Paul Brook
@ 2010-06-14 22:11 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 22:11 UTC (permalink / raw)
To: Paul Brook
Cc: Jan Kiszka, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
On Mon, 2010-06-14 at 22:43 +0100, Paul Brook wrote:
> > On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > > Alex Williamson wrote:
> > Ok, I can get it down to something like:
> >
> > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> >
> > The addr on the device is initially a little non-intuitive to me since
> > it's a property of the bus, but I guess it make sense if we think of
> > that level as slot, which includes an address and driver.
>
> That indicates you're thinking about things the wrong way.
> The point of this path is to uniquely identify an entity.
>
> /i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
> device. To identify a device attached to that bus all you need to know is the
> devfn of the device.
Hmm, I think that identifies where the device is, not what the device
is. It's more helpful to say "the e1000 in slot 7" than it is to say
"the device in slot 7".
> For an end-user it may be helpful to allow devices to be identified by the
> device type (assuming only one device of a particular type on that bus), or
> specify the device type as a crude error checking mechanism. However we're
> talking about canonical addresses. These need not include the device type.
> Verifying that the device is actually what you expect is a separate problem,
> and the device type is not sufficient for that.
>
> i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
We seem to keep introducing new problems, and I'm not sure this one
exists. If I drop the device name/type and use only the devfn, then
what's to prevent the /e1000,09.0/rom (/,09.0/rom) from being stuffed
into the /rtl8139,09.0/rom (/,09.0/rom) on a migration? (or we match it
to /09.0/savevm when trying to migrate state) We can argue that "e1000"
isn't a sufficient identifier, but I can't think of a case where it'd
fail.
> > > > I started down that path, but it still breaks for hotplug. If we start
> > > > a VM with two e1000 NICs, then remove the first, we can no longer
> > > > migrate because the target can't represent having a single e1000 with a
> > > > non-zero instance ID.
> > >
> > > That's indeed a good point.
>
> That's a feature. If you start with two NICs and remove the first, the chances
> are that the second will be in a different place to the nice created in a
> single-nic config. Allowing migration between these two will cause a PCI
> device to suddenly change location. This is not physically or logically
> possible, and everyone looses.
If the BAR addresses don't follow the VM when it's migrated, that's
another bug that needs to be fixed, but we can't get there until we at
least have some infrastructure in place to make that bug possible.
> Hot-removing a nic and then hotplugging a new nic in the same location may
> result in something that is reasonable to migrate.
It might... it might not. I'd rather make it work than try to document
the restrictions.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 22:11 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-14 22:11 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, kraxel, avi
On Mon, 2010-06-14 at 22:43 +0100, Paul Brook wrote:
> > On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > > Alex Williamson wrote:
> > Ok, I can get it down to something like:
> >
> > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> >
> > The addr on the device is initially a little non-intuitive to me since
> > it's a property of the bus, but I guess it make sense if we think of
> > that level as slot, which includes an address and driver.
>
> That indicates you're thinking about things the wrong way.
> The point of this path is to uniquely identify an entity.
>
> /i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
> device. To identify a device attached to that bus all you need to know is the
> devfn of the device.
Hmm, I think that identifies where the device is, not what the device
is. It's more helpful to say "the e1000 in slot 7" than it is to say
"the device in slot 7".
> For an end-user it may be helpful to allow devices to be identified by the
> device type (assuming only one device of a particular type on that bus), or
> specify the device type as a crude error checking mechanism. However we're
> talking about canonical addresses. These need not include the device type.
> Verifying that the device is actually what you expect is a separate problem,
> and the device type is not sufficient for that.
>
> i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
We seem to keep introducing new problems, and I'm not sure this one
exists. If I drop the device name/type and use only the devfn, then
what's to prevent the /e1000,09.0/rom (/,09.0/rom) from being stuffed
into the /rtl8139,09.0/rom (/,09.0/rom) on a migration? (or we match it
to /09.0/savevm when trying to migrate state) We can argue that "e1000"
isn't a sufficient identifier, but I can't think of a case where it'd
fail.
> > > > I started down that path, but it still breaks for hotplug. If we start
> > > > a VM with two e1000 NICs, then remove the first, we can no longer
> > > > migrate because the target can't represent having a single e1000 with a
> > > > non-zero instance ID.
> > >
> > > That's indeed a good point.
>
> That's a feature. If you start with two NICs and remove the first, the chances
> are that the second will be in a different place to the nice created in a
> single-nic config. Allowing migration between these two will cause a PCI
> device to suddenly change location. This is not physically or logically
> possible, and everyone looses.
If the BAR addresses don't follow the VM when it's migrated, that's
another bug that needs to be fixed, but we can't get there until we at
least have some infrastructure in place to make that bug possible.
> Hot-removing a nic and then hotplugging a new nic in the same location may
> result in something that is reasonable to migrate.
It might... it might not. I'd rather make it work than try to document
the restrictions.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 22:11 ` Alex Williamson
@ 2010-06-14 22:46 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-14 22:46 UTC (permalink / raw)
To: Alex Williamson
Cc: Jan Kiszka, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
> > > Ok, I can get it down to something like:
> > >
> > > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> > >
> > > The addr on the device is initially a little non-intuitive to me since
> > > it's a property of the bus, but I guess it make sense if we think of
> > > that level as slot, which includes an address and driver.
> >
> > That indicates you're thinking about things the wrong way.
> > The point of this path is to uniquely identify an entity.
> >
> > /i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
> > device. To identify a device attached to that bus all you need to know is
> > the devfn of the device.
>
> Hmm, I think that identifies where the device is, not what the device
> is. It's more helpful to say "the e1000 in slot 7" than it is to say
> "the device in slot 7".
Why is this more useful? Canonical addresses should not be helpful. They
should identify entities within a machine that is already known to be
consistent. Making them "helpful" just makes them more volatile.
> > For an end-user it may be helpful to allow devices to be identified by
> > the device type (assuming only one device of a particular type on that
> > bus), or specify the device type as a crude error checking mechanism.
> > However we're talking about canonical addresses. These need not include
> > the device type. Verifying that the device is actually what you expect
> > is a separate problem, and the device type is not sufficient for that.
> >
> > i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
>
> We seem to keep introducing new problems, and I'm not sure this one
> exists. If I drop the device name/type and use only the devfn, then
> what's to prevent the /e1000,09.0/rom (/,09.0/rom) from being stuffed
> into the /rtl8139,09.0/rom (/,09.0/rom) on a migration? (or we match it
> to /09.0/savevm when trying to migrate state) We can argue that "e1000"
> isn't a sufficient identifier, but I can't think of a case where it'd
> fail.
The migration code needs to check that the devices are actually compatible.
I'd expect this to require much more than just the device name. What you
actually need is more like "An e1000 with 64k eeprom, fast ethernet PHY, and
frobnitz B". In fact what you really want to do is transfer the device tree
(including properties), and create the machine from scratch, not load state
into a pre-supplied device tree.
> > > > > I started down that path, but it still breaks for hotplug. If we
> > > > > start a VM with two e1000 NICs, then remove the first, we can no
> > > > > longer migrate because the target can't represent having a single
> > > > > e1000 with a non-zero instance ID.
> > > >
> > > > That's indeed a good point.
> >
> > That's a feature. If you start with two NICs and remove the first, the
> > chances are that the second will be in a different place to the nice
> > created in a single-nic config. Allowing migration between these two
> > will cause a PCI device to suddenly change location. This is not
> > physically or logically possible, and everyone looses.
>
> If the BAR addresses don't follow the VM when it's migrated, that's
> another bug that needs to be fixed, but we can't get there until we at
> least have some infrastructure in place to make that bug possible.
Not BAR addresses, the actual PCI device addresses. Devices on the PCI bus are
addressed by device and function. This is guest visible. The device part of
this address corresponds to the physical slot, which typically effects IRQ
routing (amongst other things). If you arbitrarily move a device from slot A
to slot B then this will have catastrophic effects on a running machine.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-14 22:46 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-14 22:46 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, kraxel, avi
> > > Ok, I can get it down to something like:
> > >
> > > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> > >
> > > The addr on the device is initially a little non-intuitive to me since
> > > it's a property of the bus, but I guess it make sense if we think of
> > > that level as slot, which includes an address and driver.
> >
> > That indicates you're thinking about things the wrong way.
> > The point of this path is to uniquely identify an entity.
> >
> > /i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
> > device. To identify a device attached to that bus all you need to know is
> > the devfn of the device.
>
> Hmm, I think that identifies where the device is, not what the device
> is. It's more helpful to say "the e1000 in slot 7" than it is to say
> "the device in slot 7".
Why is this more useful? Canonical addresses should not be helpful. They
should identify entities within a machine that is already known to be
consistent. Making them "helpful" just makes them more volatile.
> > For an end-user it may be helpful to allow devices to be identified by
> > the device type (assuming only one device of a particular type on that
> > bus), or specify the device type as a crude error checking mechanism.
> > However we're talking about canonical addresses. These need not include
> > the device type. Verifying that the device is actually what you expect
> > is a separate problem, and the device type is not sufficient for that.
> >
> > i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
>
> We seem to keep introducing new problems, and I'm not sure this one
> exists. If I drop the device name/type and use only the devfn, then
> what's to prevent the /e1000,09.0/rom (/,09.0/rom) from being stuffed
> into the /rtl8139,09.0/rom (/,09.0/rom) on a migration? (or we match it
> to /09.0/savevm when trying to migrate state) We can argue that "e1000"
> isn't a sufficient identifier, but I can't think of a case where it'd
> fail.
The migration code needs to check that the devices are actually compatible.
I'd expect this to require much more than just the device name. What you
actually need is more like "An e1000 with 64k eeprom, fast ethernet PHY, and
frobnitz B". In fact what you really want to do is transfer the device tree
(including properties), and create the machine from scratch, not load state
into a pre-supplied device tree.
> > > > > I started down that path, but it still breaks for hotplug. If we
> > > > > start a VM with two e1000 NICs, then remove the first, we can no
> > > > > longer migrate because the target can't represent having a single
> > > > > e1000 with a non-zero instance ID.
> > > >
> > > > That's indeed a good point.
> >
> > That's a feature. If you start with two NICs and remove the first, the
> > chances are that the second will be in a different place to the nice
> > created in a single-nic config. Allowing migration between these two
> > will cause a PCI device to suddenly change location. This is not
> > physically or logically possible, and everyone looses.
>
> If the BAR addresses don't follow the VM when it's migrated, that's
> another bug that needs to be fixed, but we can't get there until we at
> least have some infrastructure in place to make that bug possible.
Not BAR addresses, the actual PCI device addresses. Devices on the PCI bus are
addressed by device and function. This is guest visible. The device part of
this address corresponds to the physical slot, which typically effects IRQ
routing (amongst other things). If you arbitrarily move a device from slot A
to slot B then this will have catastrophic effects on a running machine.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 22:46 ` Paul Brook
@ 2010-06-15 1:14 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 1:14 UTC (permalink / raw)
To: Paul Brook
Cc: Jan Kiszka, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
On Mon, 2010-06-14 at 23:46 +0100, Paul Brook wrote:
> > > > Ok, I can get it down to something like:
> > > >
> > > > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> > > >
> > > > The addr on the device is initially a little non-intuitive to me since
> > > > it's a property of the bus, but I guess it make sense if we think of
> > > > that level as slot, which includes an address and driver.
> > >
> > > That indicates you're thinking about things the wrong way.
> > > The point of this path is to uniquely identify an entity.
> > >
> > > /i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
> > > device. To identify a device attached to that bus all you need to know is
> > > the devfn of the device.
> >
> > Hmm, I think that identifies where the device is, not what the device
> > is. It's more helpful to say "the e1000 in slot 7" than it is to say
> > "the device in slot 7".
>
> Why is this more useful? Canonical addresses should not be helpful. They
> should identify entities within a machine that is already known to be
> consistent. Making them "helpful" just makes them more volatile.
Being able to check that device 09.0 is attached to the e1000 driver on
source and the rtl8139 driver on the target seems pretty useful to me.
> > > For an end-user it may be helpful to allow devices to be identified by
> > > the device type (assuming only one device of a particular type on that
> > > bus), or specify the device type as a crude error checking mechanism.
> > > However we're talking about canonical addresses. These need not include
> > > the device type. Verifying that the device is actually what you expect
> > > is a separate problem, and the device type is not sufficient for that.
> > >
> > > i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
> >
> > We seem to keep introducing new problems, and I'm not sure this one
> > exists. If I drop the device name/type and use only the devfn, then
> > what's to prevent the /e1000,09.0/rom (/,09.0/rom) from being stuffed
> > into the /rtl8139,09.0/rom (/,09.0/rom) on a migration? (or we match it
> > to /09.0/savevm when trying to migrate state) We can argue that "e1000"
> > isn't a sufficient identifier, but I can't think of a case where it'd
> > fail.
>
> The migration code needs to check that the devices are actually compatible.
> I'd expect this to require much more than just the device name. What you
> actually need is more like "An e1000 with 64k eeprom, fast ethernet PHY, and
> frobnitz B".
No, that's savevm's problem, and it's perfectly capable of doing it via
the version ids. We're not using the driver name to describe just any
random e1000, it's the one that the e1000 driver created, version foo.
If it added a frobnitz in version foo+1, either that savevm knows how to
import a version foo or rejects it.
> In fact what you really want to do is transfer the device tree
> (including properties), and create the machine from scratch, not load state
> into a pre-supplied device tree.
Well, I agree, but that's a lot more of an overhaul, and once again
we're changing the problem.
> > > > > > I started down that path, but it still breaks for hotplug. If we
> > > > > > start a VM with two e1000 NICs, then remove the first, we can no
> > > > > > longer migrate because the target can't represent having a single
> > > > > > e1000 with a non-zero instance ID.
> > > > >
> > > > > That's indeed a good point.
> > >
> > > That's a feature. If you start with two NICs and remove the first, the
> > > chances are that the second will be in a different place to the nice
> > > created in a single-nic config. Allowing migration between these two
> > > will cause a PCI device to suddenly change location. This is not
> > > physically or logically possible, and everyone looses.
> >
> > If the BAR addresses don't follow the VM when it's migrated, that's
> > another bug that needs to be fixed, but we can't get there until we at
> > least have some infrastructure in place to make that bug possible.
>
> Not BAR addresses, the actual PCI device addresses. Devices on the PCI bus are
> addressed by device and function. This is guest visible. The device part of
> this address corresponds to the physical slot, which typically effects IRQ
> routing (amongst other things). If you arbitrarily move a device from slot A
> to slot B then this will have catastrophic effects on a running machine.
Sorry, I jumped to BARs because the PCI device address mismatch is kinda
the point of where I'm going. With these changes, we're at least
allowing that a smart enough management tool is actually able to create
a VM state to match a source instance that has done hotplug operations.
As it is today, I don't think it's possible to migrate a VM that has
gaps in it's savevm instance ids.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 1:14 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 1:14 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, kraxel, avi
On Mon, 2010-06-14 at 23:46 +0100, Paul Brook wrote:
> > > > Ok, I can get it down to something like:
> > > >
> > > > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
> > > >
> > > > The addr on the device is initially a little non-intuitive to me since
> > > > it's a property of the bus, but I guess it make sense if we think of
> > > > that level as slot, which includes an address and driver.
> > >
> > > That indicates you're thinking about things the wrong way.
> > > The point of this path is to uniquely identify an entity.
> > >
> > > /i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
> > > device. To identify a device attached to that bus all you need to know is
> > > the devfn of the device.
> >
> > Hmm, I think that identifies where the device is, not what the device
> > is. It's more helpful to say "the e1000 in slot 7" than it is to say
> > "the device in slot 7".
>
> Why is this more useful? Canonical addresses should not be helpful. They
> should identify entities within a machine that is already known to be
> consistent. Making them "helpful" just makes them more volatile.
Being able to check that device 09.0 is attached to the e1000 driver on
source and the rtl8139 driver on the target seems pretty useful to me.
> > > For an end-user it may be helpful to allow devices to be identified by
> > > the device type (assuming only one device of a particular type on that
> > > bus), or specify the device type as a crude error checking mechanism.
> > > However we're talking about canonical addresses. These need not include
> > > the device type. Verifying that the device is actually what you expect
> > > is a separate problem, and the device type is not sufficient for that.
> > >
> > > i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
> >
> > We seem to keep introducing new problems, and I'm not sure this one
> > exists. If I drop the device name/type and use only the devfn, then
> > what's to prevent the /e1000,09.0/rom (/,09.0/rom) from being stuffed
> > into the /rtl8139,09.0/rom (/,09.0/rom) on a migration? (or we match it
> > to /09.0/savevm when trying to migrate state) We can argue that "e1000"
> > isn't a sufficient identifier, but I can't think of a case where it'd
> > fail.
>
> The migration code needs to check that the devices are actually compatible.
> I'd expect this to require much more than just the device name. What you
> actually need is more like "An e1000 with 64k eeprom, fast ethernet PHY, and
> frobnitz B".
No, that's savevm's problem, and it's perfectly capable of doing it via
the version ids. We're not using the driver name to describe just any
random e1000, it's the one that the e1000 driver created, version foo.
If it added a frobnitz in version foo+1, either that savevm knows how to
import a version foo or rejects it.
> In fact what you really want to do is transfer the device tree
> (including properties), and create the machine from scratch, not load state
> into a pre-supplied device tree.
Well, I agree, but that's a lot more of an overhaul, and once again
we're changing the problem.
> > > > > > I started down that path, but it still breaks for hotplug. If we
> > > > > > start a VM with two e1000 NICs, then remove the first, we can no
> > > > > > longer migrate because the target can't represent having a single
> > > > > > e1000 with a non-zero instance ID.
> > > > >
> > > > > That's indeed a good point.
> > >
> > > That's a feature. If you start with two NICs and remove the first, the
> > > chances are that the second will be in a different place to the nice
> > > created in a single-nic config. Allowing migration between these two
> > > will cause a PCI device to suddenly change location. This is not
> > > physically or logically possible, and everyone looses.
> >
> > If the BAR addresses don't follow the VM when it's migrated, that's
> > another bug that needs to be fixed, but we can't get there until we at
> > least have some infrastructure in place to make that bug possible.
>
> Not BAR addresses, the actual PCI device addresses. Devices on the PCI bus are
> addressed by device and function. This is guest visible. The device part of
> this address corresponds to the physical slot, which typically effects IRQ
> routing (amongst other things). If you arbitrarily move a device from slot A
> to slot B then this will have catastrophic effects on a running machine.
Sorry, I jumped to BARs because the PCI device address mismatch is kinda
the point of where I'm going. With these changes, we're at least
allowing that a smart enough management tool is actually able to create
a VM state to match a source instance that has done hotplug operations.
As it is today, I don't think it's possible to migrate a VM that has
gaps in it's savevm instance ids.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-14 13:09 ` Paul Brook
@ 2010-06-15 8:47 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 8:47 UTC (permalink / raw)
To: Paul Brook; +Cc: Alex Williamson, chrisw, kvm, qemu-devel, avi, kraxel
Paul Brook <paul@codesourcery.com> writes:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>> > Could you explain why you add "identified properties of the immediate
>> > parent bus and device"? They make the result ver much *not* a "dev
>> > path" in the qdev sense...
>>
>> In order to try to get a unique string. Without looking into device
>> properties, two e1000s would both be:
>>
>> /main-system-bus/pci.0/e1000
>> /main-system-bus/pci.0/e1000
>>
>> Which is no better than simply "e1000" and would require us to fall back
>> to instance ids again. The goal here is that anything that makes use of
>> passing a dev when registering a vmstate gets an instance id of zero.
>
> You already got the information you need, you just put it in the wrong place.
> The canonical ID for the device could be its bus address. In practice we'd
> probably want to allow the user to specify it by name, provided these are
> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
> can use an initial prefix to disambiguate a name/label from a bus address.
>
> For busses that don't have a consistent addressing scheme then some sort of
> instance ID is unavoidable. I guess it may be possible to invent something
> based on other device properties (e.g. address of the first IO port/memory
> region).
When that's inconvenient or impossible, we can still punt to user: make
device ID mandatory.
We obviously need a way to unambigously name a device. It's okay to
have multiple names for the same device.
If the device has a device ID, that's an unambigous name.
qdev paths may be ambigous when path components are resolved to driver
names instead of IDs.
Alex proposed to disambiguate by adding "identified properties of the
immediate parent bus and device" to the path component. For PCI, these
are dev.fn. Likewise for any other bus where devices have unambigous
bus address. The driver name carries no information!
For other buses, we need to make something up.
Note that addressing by bus address rather than name is generally
useful, not just in the context of savevm. For instance, I'd appreciate
being able to say something like "device_del pci.0/04.0".
An easy way to get that is to reserve part of the name space for bus
addresses. If the path component starts with a letter, it's an ID or
driver name. If it starts with say '@', it's a bus address in
bus-specific syntax. The bus provides a method to look it up.
That way, we gain a useful feature, and avoid having an savevm-specific
"device path" that isn't recognized anywhere else.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 8:47 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 8:47 UTC (permalink / raw)
To: Paul Brook; +Cc: chrisw, kvm, qemu-devel, Alex Williamson, kraxel, avi
Paul Brook <paul@codesourcery.com> writes:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>> > Could you explain why you add "identified properties of the immediate
>> > parent bus and device"? They make the result ver much *not* a "dev
>> > path" in the qdev sense...
>>
>> In order to try to get a unique string. Without looking into device
>> properties, two e1000s would both be:
>>
>> /main-system-bus/pci.0/e1000
>> /main-system-bus/pci.0/e1000
>>
>> Which is no better than simply "e1000" and would require us to fall back
>> to instance ids again. The goal here is that anything that makes use of
>> passing a dev when registering a vmstate gets an instance id of zero.
>
> You already got the information you need, you just put it in the wrong place.
> The canonical ID for the device could be its bus address. In practice we'd
> probably want to allow the user to specify it by name, provided these are
> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
> can use an initial prefix to disambiguate a name/label from a bus address.
>
> For busses that don't have a consistent addressing scheme then some sort of
> instance ID is unavoidable. I guess it may be possible to invent something
> based on other device properties (e.g. address of the first IO port/memory
> region).
When that's inconvenient or impossible, we can still punt to user: make
device ID mandatory.
We obviously need a way to unambigously name a device. It's okay to
have multiple names for the same device.
If the device has a device ID, that's an unambigous name.
qdev paths may be ambigous when path components are resolved to driver
names instead of IDs.
Alex proposed to disambiguate by adding "identified properties of the
immediate parent bus and device" to the path component. For PCI, these
are dev.fn. Likewise for any other bus where devices have unambigous
bus address. The driver name carries no information!
For other buses, we need to make something up.
Note that addressing by bus address rather than name is generally
useful, not just in the context of savevm. For instance, I'd appreciate
being able to say something like "device_del pci.0/04.0".
An easy way to get that is to reserve part of the name space for bus
addresses. If the path component starts with a letter, it's an ID or
driver name. If it starts with say '@', it's a bus address in
bus-specific syntax. The bus provides a method to look it up.
That way, we gain a useful feature, and avoid having an savevm-specific
"device path" that isn't recognized anywhere else.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
2010-06-14 19:56 ` [Qemu-devel] " Alex Williamson
@ 2010-06-15 8:53 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 8:53 UTC (permalink / raw)
To: Alex Williamson; +Cc: Gerd Hoffmann, chrisw, kvm, qemu-devel, paul, avi
Alex Williamson <alex.williamson@redhat.com> writes:
> On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
>> Hi,
>>
>> > 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.
>>
>> You'll need that for every bus along the way down to the device. Create
>> a virtual machine with two lsi scsi host adapters, then attach a disk
>> with scsi id 0 to each. Just the scsi id isn't good enougth to identify
>> the device. You'll need the lsi pci address too.
>
> Yep, see below.
>
>> > For now, the only properties I've tagged as path
>> > properties are PCI bus addresses and MAC addresses.
>>
>> mac address isn't needed here. You need the property which specifies
>> the bus address. For PCI this obviously is the PCI address. For scsi
>> the scsi id. For ISA you can use the I/O port base. virtio-serial the
>> port number, ...
>
> PCI: addr
> SCSI: scsi-id
> ISA: serial/parallel = iobase, others??
If there's no iobase (pathological case), require ID.
> ide-drive: unit
Bus name is IDE, but it's clear enough what you mean :)
> I2C: address
>
> virtio-serial doesn't seem to make a DeviceState per port, so I think it
> can be skipped.
Really?
Anyway, its port number should do as bus address.
> I'm sure I'm still missing some...
s390-virtio
SSI
System
USB
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
@ 2010-06-15 8:53 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 8:53 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, Gerd Hoffmann, kvm, qemu-devel, paul, avi
Alex Williamson <alex.williamson@redhat.com> writes:
> On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
>> Hi,
>>
>> > 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.
>>
>> You'll need that for every bus along the way down to the device. Create
>> a virtual machine with two lsi scsi host adapters, then attach a disk
>> with scsi id 0 to each. Just the scsi id isn't good enougth to identify
>> the device. You'll need the lsi pci address too.
>
> Yep, see below.
>
>> > For now, the only properties I've tagged as path
>> > properties are PCI bus addresses and MAC addresses.
>>
>> mac address isn't needed here. You need the property which specifies
>> the bus address. For PCI this obviously is the PCI address. For scsi
>> the scsi id. For ISA you can use the I/O port base. virtio-serial the
>> port number, ...
>
> PCI: addr
> SCSI: scsi-id
> ISA: serial/parallel = iobase, others??
If there's no iobase (pathological case), require ID.
> ide-drive: unit
Bus name is IDE, but it's clear enough what you mean :)
> I2C: address
>
> virtio-serial doesn't seem to make a DeviceState per port, so I think it
> can be skipped.
Really?
Anyway, its port number should do as bus address.
> I'm sure I'm still missing some...
s390-virtio
SSI
System
USB
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
2010-06-14 19:56 ` [Qemu-devel] " Alex Williamson
@ 2010-06-15 9:12 ` Gerd Hoffmann
-1 siblings, 0 replies; 160+ messages in thread
From: Gerd Hoffmann @ 2010-06-15 9:12 UTC (permalink / raw)
To: Alex Williamson; +Cc: qemu-devel, kvm, avi, anthony, paul, chrisw
> ISA: serial/parallel = iobase, others??
ne2k_isa has iobase too.
I think all remaining isa devices (timer, kbd, vga, ...) have a fixed
i/o base and can be only once in the system.
> ide-drive: unit
> I2C: address
>
> virtio-serial doesn't seem to make a DeviceState per port, so I think it
> can be skipped. I'm sure I'm still missing some...
Hmm? -device virtio-serial -device virtconsole,chardev=foo,port=23
cheers,
Gerd
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
@ 2010-06-15 9:12 ` Gerd Hoffmann
0 siblings, 0 replies; 160+ messages in thread
From: Gerd Hoffmann @ 2010-06-15 9:12 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, qemu-devel, paul, avi
> ISA: serial/parallel = iobase, others??
ne2k_isa has iobase too.
I think all remaining isa devices (timer, kbd, vga, ...) have a fixed
i/o base and can be only once in the system.
> ide-drive: unit
> I2C: address
>
> virtio-serial doesn't seem to make a DeviceState per port, so I think it
> can be skipped. I'm sure I'm still missing some...
Hmm? -device virtio-serial -device virtconsole,chardev=foo,port=23
cheers,
Gerd
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 8:47 ` Markus Armbruster
@ 2010-06-15 9:34 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 9:34 UTC (permalink / raw)
To: Markus Armbruster
Cc: Paul Brook, Alex Williamson, chrisw, kvm, qemu-devel, avi, kraxel
Markus Armbruster wrote:
> Paul Brook <paul@codesourcery.com> writes:
>
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>> Could you explain why you add "identified properties of the immediate
>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>> path" in the qdev sense...
>>> In order to try to get a unique string. Without looking into device
>>> properties, two e1000s would both be:
>>>
>>> /main-system-bus/pci.0/e1000
>>> /main-system-bus/pci.0/e1000
>>>
>>> Which is no better than simply "e1000" and would require us to fall back
>>> to instance ids again. The goal here is that anything that makes use of
>>> passing a dev when registering a vmstate gets an instance id of zero.
>> You already got the information you need, you just put it in the wrong place.
>> The canonical ID for the device could be its bus address. In practice we'd
>> probably want to allow the user to specify it by name, provided these are
>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>> can use an initial prefix to disambiguate a name/label from a bus address.
>>
>> For busses that don't have a consistent addressing scheme then some sort of
>> instance ID is unavoidable. I guess it may be possible to invent something
>> based on other device properties (e.g. address of the first IO port/memory
>> region).
>
> When that's inconvenient or impossible, we can still punt to user: make
> device ID mandatory.
No option due to auto-created devices. And auto-generating IDs would
just create usability issues.
>
>
> We obviously need a way to unambigously name a device. It's okay to
> have multiple names for the same device.
>
> If the device has a device ID, that's an unambigous name.
>
> qdev paths may be ambigous when path components are resolved to driver
> names instead of IDs.
>
> Alex proposed to disambiguate by adding "identified properties of the
> immediate parent bus and device" to the path component. For PCI, these
> are dev.fn. Likewise for any other bus where devices have unambigous
> bus address. The driver name carries no information!
>From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the same
bus that are handled by the same driver. For that case we need to
augment the device name with a useful per-bus ID, derived from the bus
address where available, otherwise based on instance numbers.
>
> For other buses, we need to make something up.
>
> Note that addressing by bus address rather than name is generally
> useful, not just in the context of savevm. For instance, I'd appreciate
> being able to say something like "device_del pci.0/04.0".
And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
the bus first before you can identify which device you want to remove.
>
> An easy way to get that is to reserve part of the name space for bus
> addresses. If the path component starts with a letter, it's an ID or
> driver name. If it starts with say '@', it's a bus address in
> bus-specific syntax. The bus provides a method to look it up.
I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
set for buses that implement some to-be-defined device addressing
service, the latter is the default on buses where that service is not
available.
>
> That way, we gain a useful feature, and avoid having an savevm-specific
> "device path" that isn't recognized anywhere else.
Agreed, we should find one solution for all use cases.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 9:34 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 9:34 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kraxel, kvm, qemu-devel, Alex Williamson, avi, Paul Brook
Markus Armbruster wrote:
> Paul Brook <paul@codesourcery.com> writes:
>
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>> Could you explain why you add "identified properties of the immediate
>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>> path" in the qdev sense...
>>> In order to try to get a unique string. Without looking into device
>>> properties, two e1000s would both be:
>>>
>>> /main-system-bus/pci.0/e1000
>>> /main-system-bus/pci.0/e1000
>>>
>>> Which is no better than simply "e1000" and would require us to fall back
>>> to instance ids again. The goal here is that anything that makes use of
>>> passing a dev when registering a vmstate gets an instance id of zero.
>> You already got the information you need, you just put it in the wrong place.
>> The canonical ID for the device could be its bus address. In practice we'd
>> probably want to allow the user to specify it by name, provided these are
>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>> can use an initial prefix to disambiguate a name/label from a bus address.
>>
>> For busses that don't have a consistent addressing scheme then some sort of
>> instance ID is unavoidable. I guess it may be possible to invent something
>> based on other device properties (e.g. address of the first IO port/memory
>> region).
>
> When that's inconvenient or impossible, we can still punt to user: make
> device ID mandatory.
No option due to auto-created devices. And auto-generating IDs would
just create usability issues.
>
>
> We obviously need a way to unambigously name a device. It's okay to
> have multiple names for the same device.
>
> If the device has a device ID, that's an unambigous name.
>
> qdev paths may be ambigous when path components are resolved to driver
> names instead of IDs.
>
> Alex proposed to disambiguate by adding "identified properties of the
> immediate parent bus and device" to the path component. For PCI, these
> are dev.fn. Likewise for any other bus where devices have unambigous
> bus address. The driver name carries no information!
>From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the same
bus that are handled by the same driver. For that case we need to
augment the device name with a useful per-bus ID, derived from the bus
address where available, otherwise based on instance numbers.
>
> For other buses, we need to make something up.
>
> Note that addressing by bus address rather than name is generally
> useful, not just in the context of savevm. For instance, I'd appreciate
> being able to say something like "device_del pci.0/04.0".
And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
the bus first before you can identify which device you want to remove.
>
> An easy way to get that is to reserve part of the name space for bus
> addresses. If the path component starts with a letter, it's an ID or
> driver name. If it starts with say '@', it's a bus address in
> bus-specific syntax. The bus provides a method to look it up.
I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
set for buses that implement some to-be-defined device addressing
service, the latter is the default on buses where that service is not
available.
>
> That way, we gain a useful feature, and avoid having an savevm-specific
> "device path" that isn't recognized anywhere else.
Agreed, we should find one solution for all use cases.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 1:14 ` Alex Williamson
@ 2010-06-15 11:24 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 11:24 UTC (permalink / raw)
To: Alex Williamson
Cc: Jan Kiszka, Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
> > In fact what you really want to do is transfer the device tree
> > (including properties), and create the machine from scratch, not load
> > state into a pre-supplied device tree.
>
> Well, I agree, but that's a lot more of an overhaul, and once again
> we're changing the problem.
I think it's you that's changing the problem.
The requirement is to uniquely identify a device within a machine.
Verifying that this device is that compatible with the device at the same
address in a different machine is a separate problem. We should not be trying
to encode this information in the canonical device path.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 11:24 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 11:24 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, kraxel, avi
> > In fact what you really want to do is transfer the device tree
> > (including properties), and create the machine from scratch, not load
> > state into a pre-supplied device tree.
>
> Well, I agree, but that's a lot more of an overhaul, and once again
> we're changing the problem.
I think it's you that's changing the problem.
The requirement is to uniquely identify a device within a machine.
Verifying that this device is that compatible with the device at the same
address in a different machine is a separate problem. We should not be trying
to encode this information in the canonical device path.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 9:34 ` Jan Kiszka
@ 2010-06-15 11:28 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 11:28 UTC (permalink / raw)
To: Jan Kiszka
Cc: Markus Armbruster, Alex Williamson, chrisw, kvm, qemu-devel, avi, kraxel
> > Alex proposed to disambiguate by adding "identified properties of the
> > immediate parent bus and device" to the path component. For PCI, these
> > are dev.fn. Likewise for any other bus where devices have unambigous
> > bus address. The driver name carries no information!
>
> From user POV, driver names are very handly to address a device
> intuitively - except for the case you have tones of devices on the same
> bus that are handled by the same driver. For that case we need to
> augment the device name with a useful per-bus ID, derived from the bus
> address where available, otherwise based on instance numbers.
This is where I think you're missing a trick. We don't need to augment the
name, we just need to allow the bus id to be used instead.
> > For other buses, we need to make something up.
> >
> > Note that addressing by bus address rather than name is generally
> > useful, not just in the context of savevm. For instance, I'd appreciate
> > being able to say something like "device_del pci.0/04.0".
>
> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> the bus first before you can identify which device you want to remove.
We can allow both.
A bus address is sufficient to uniquely identify a device. I see no reason to
require the driver name, or to include it in the canonical device address.
> > An easy way to get that is to reserve part of the name space for bus
> > addresses. If the path component starts with a letter, it's an ID or
> > driver name. If it starts with say '@', it's a bus address in
> > bus-specific syntax. The bus provides a method to look it up.
>
> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
> set for buses that implement some to-be-defined device addressing
> service, the latter is the default on buses where that service is not
> available.
If we have bus-address then I see no good reason to also add instance-no.
For busses that no natural address, we can define the address to be an
instance number.
> > That way, we gain a useful feature, and avoid having an savevm-specific
> > "device path" that isn't recognized anywhere else.
>
> Agreed, we should find one solution for all use cases.
I wasn't aware that there was any suggestion of a separate savevm-specific
path. The whole point of a device path is to uniquely identify a device
within a machine. There may be many different paths that identify the same
device. When given a device and asked to generate path, the result should be
the canonical address. IMO this should be the least volatile, and avoid
redundant information.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 11:28 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 11:28 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, Markus Armbruster, qemu-devel, Alex Williamson, avi, kraxel
> > Alex proposed to disambiguate by adding "identified properties of the
> > immediate parent bus and device" to the path component. For PCI, these
> > are dev.fn. Likewise for any other bus where devices have unambigous
> > bus address. The driver name carries no information!
>
> From user POV, driver names are very handly to address a device
> intuitively - except for the case you have tones of devices on the same
> bus that are handled by the same driver. For that case we need to
> augment the device name with a useful per-bus ID, derived from the bus
> address where available, otherwise based on instance numbers.
This is where I think you're missing a trick. We don't need to augment the
name, we just need to allow the bus id to be used instead.
> > For other buses, we need to make something up.
> >
> > Note that addressing by bus address rather than name is generally
> > useful, not just in the context of savevm. For instance, I'd appreciate
> > being able to say something like "device_del pci.0/04.0".
>
> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> the bus first before you can identify which device you want to remove.
We can allow both.
A bus address is sufficient to uniquely identify a device. I see no reason to
require the driver name, or to include it in the canonical device address.
> > An easy way to get that is to reserve part of the name space for bus
> > addresses. If the path component starts with a letter, it's an ID or
> > driver name. If it starts with say '@', it's a bus address in
> > bus-specific syntax. The bus provides a method to look it up.
>
> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
> set for buses that implement some to-be-defined device addressing
> service, the latter is the default on buses where that service is not
> available.
If we have bus-address then I see no good reason to also add instance-no.
For busses that no natural address, we can define the address to be an
instance number.
> > That way, we gain a useful feature, and avoid having an savevm-specific
> > "device path" that isn't recognized anywhere else.
>
> Agreed, we should find one solution for all use cases.
I wasn't aware that there was any suggestion of a separate savevm-specific
path. The whole point of a device path is to uniquely identify a device
within a machine. There may be many different paths that identify the same
device. When given a device and asked to generate path, the result should be
the canonical address. IMO this should be the least volatile, and avoid
redundant information.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 9:34 ` Jan Kiszka
@ 2010-06-15 11:42 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 11:42 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kraxel, kvm, qemu-devel, Alex Williamson, avi, Paul Brook
Jan Kiszka <jan.kiszka@siemens.com> writes:
> Markus Armbruster wrote:
>> Paul Brook <paul@codesourcery.com> writes:
>>
>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>
>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>> Could you explain why you add "identified properties of the immediate
>>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>>> path" in the qdev sense...
>>>> In order to try to get a unique string. Without looking into device
>>>> properties, two e1000s would both be:
>>>>
>>>> /main-system-bus/pci.0/e1000
>>>> /main-system-bus/pci.0/e1000
>>>>
>>>> Which is no better than simply "e1000" and would require us to fall back
>>>> to instance ids again. The goal here is that anything that makes use of
>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>> You already got the information you need, you just put it in the wrong place.
>>> The canonical ID for the device could be its bus address. In practice we'd
>>> probably want to allow the user to specify it by name, provided these are
>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>
>>> For busses that don't have a consistent addressing scheme then some sort of
>>> instance ID is unavoidable. I guess it may be possible to invent something
>>> based on other device properties (e.g. address of the first IO port/memory
>>> region).
>>
>> When that's inconvenient or impossible, we can still punt to user: make
>> device ID mandatory.
>
> No option due to auto-created devices. And auto-generating IDs would
> just create usability issues.
Auto-generated IDs would become part of the ABI. Really so bad that
it's "no option"? Mind, device ID becomes mandatory *only* for devices
that don't have a useful bus address. We could even waive the ID
requirement for the first device of a kind, i.e. require ID if and only
if it's needed to disambiguate.
>> We obviously need a way to unambigously name a device. It's okay to
>> have multiple names for the same device.
>>
>> If the device has a device ID, that's an unambigous name.
>>
>> qdev paths may be ambigous when path components are resolved to driver
>> names instead of IDs.
>>
>> Alex proposed to disambiguate by adding "identified properties of the
>> immediate parent bus and device" to the path component. For PCI, these
>> are dev.fn. Likewise for any other bus where devices have unambigous
>> bus address. The driver name carries no information!
>
>>From user POV, driver names are very handly to address a device
> intuitively - except for the case you have tones of devices on the same
> bus that are handled by the same driver. For that case we need to
> augment the device name with a useful per-bus ID, derived from the bus
> address where available, otherwise based on instance numbers.
I'm not arguing against the use of driver names at all.
>> For other buses, we need to make something up.
>>
>> Note that addressing by bus address rather than name is generally
>> useful, not just in the context of savevm. For instance, I'd appreciate
>> being able to say something like "device_del pci.0/04.0".
>
> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> the bus first before you can identify which device you want to remove.
It's not either/or. Addressing by ID continues to work. Addressing by
bus/driver-name continues to work. We merely add addressing by
bus/@bus-address.
>> An easy way to get that is to reserve part of the name space for bus
>> addresses. If the path component starts with a letter, it's an ID or
>> driver name. If it starts with say '@', it's a bus address in
>> bus-specific syntax. The bus provides a method to look it up.
>
> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
> set for buses that implement some to-be-defined device addressing
> service, the latter is the default on buses where that service is not
> available.
I object to <driver>@<bus-address>, because the <driver> part carries no
information.
Not the case for <driver>.<instance-no>. We still need a suitable
definition of <instance-no>. Possible definitions:
* n-th creation of a <driver> device. Drawbacks: depends on creation
order. Relatively hard to maintain across migration.
* n-th instance of a <driver> device. Drawback: changes on unplug.
Good enough for interactive use, but it doesn't provide a stable
device name.
When counting <driver> devices either way, we can count per bus or
globally. I prefer per bus.
None of the above instance numbers are nearly as neat as bus addresses.
>> That way, we gain a useful feature, and avoid having an savevm-specific
>> "device path" that isn't recognized anywhere else.
>
> Agreed, we should find one solution for all use cases.
>
> Jan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 11:42 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 11:42 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, Paul Brook, qemu-devel, Alex Williamson, avi, kraxel
Jan Kiszka <jan.kiszka@siemens.com> writes:
> Markus Armbruster wrote:
>> Paul Brook <paul@codesourcery.com> writes:
>>
>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>
>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>> Could you explain why you add "identified properties of the immediate
>>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>>> path" in the qdev sense...
>>>> In order to try to get a unique string. Without looking into device
>>>> properties, two e1000s would both be:
>>>>
>>>> /main-system-bus/pci.0/e1000
>>>> /main-system-bus/pci.0/e1000
>>>>
>>>> Which is no better than simply "e1000" and would require us to fall back
>>>> to instance ids again. The goal here is that anything that makes use of
>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>> You already got the information you need, you just put it in the wrong place.
>>> The canonical ID for the device could be its bus address. In practice we'd
>>> probably want to allow the user to specify it by name, provided these are
>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>
>>> For busses that don't have a consistent addressing scheme then some sort of
>>> instance ID is unavoidable. I guess it may be possible to invent something
>>> based on other device properties (e.g. address of the first IO port/memory
>>> region).
>>
>> When that's inconvenient or impossible, we can still punt to user: make
>> device ID mandatory.
>
> No option due to auto-created devices. And auto-generating IDs would
> just create usability issues.
Auto-generated IDs would become part of the ABI. Really so bad that
it's "no option"? Mind, device ID becomes mandatory *only* for devices
that don't have a useful bus address. We could even waive the ID
requirement for the first device of a kind, i.e. require ID if and only
if it's needed to disambiguate.
>> We obviously need a way to unambigously name a device. It's okay to
>> have multiple names for the same device.
>>
>> If the device has a device ID, that's an unambigous name.
>>
>> qdev paths may be ambigous when path components are resolved to driver
>> names instead of IDs.
>>
>> Alex proposed to disambiguate by adding "identified properties of the
>> immediate parent bus and device" to the path component. For PCI, these
>> are dev.fn. Likewise for any other bus where devices have unambigous
>> bus address. The driver name carries no information!
>
>>From user POV, driver names are very handly to address a device
> intuitively - except for the case you have tones of devices on the same
> bus that are handled by the same driver. For that case we need to
> augment the device name with a useful per-bus ID, derived from the bus
> address where available, otherwise based on instance numbers.
I'm not arguing against the use of driver names at all.
>> For other buses, we need to make something up.
>>
>> Note that addressing by bus address rather than name is generally
>> useful, not just in the context of savevm. For instance, I'd appreciate
>> being able to say something like "device_del pci.0/04.0".
>
> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> the bus first before you can identify which device you want to remove.
It's not either/or. Addressing by ID continues to work. Addressing by
bus/driver-name continues to work. We merely add addressing by
bus/@bus-address.
>> An easy way to get that is to reserve part of the name space for bus
>> addresses. If the path component starts with a letter, it's an ID or
>> driver name. If it starts with say '@', it's a bus address in
>> bus-specific syntax. The bus provides a method to look it up.
>
> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
> set for buses that implement some to-be-defined device addressing
> service, the latter is the default on buses where that service is not
> available.
I object to <driver>@<bus-address>, because the <driver> part carries no
information.
Not the case for <driver>.<instance-no>. We still need a suitable
definition of <instance-no>. Possible definitions:
* n-th creation of a <driver> device. Drawbacks: depends on creation
order. Relatively hard to maintain across migration.
* n-th instance of a <driver> device. Drawback: changes on unplug.
Good enough for interactive use, but it doesn't provide a stable
device name.
When counting <driver> devices either way, we can count per bus or
globally. I prefer per bus.
None of the above instance numbers are nearly as neat as bus addresses.
>> That way, we gain a useful feature, and avoid having an savevm-specific
>> "device path" that isn't recognized anywhere else.
>
> Agreed, we should find one solution for all use cases.
>
> Jan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 11:28 ` Paul Brook
@ 2010-06-15 11:45 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 11:45 UTC (permalink / raw)
To: Paul Brook
Cc: Markus Armbruster, Alex Williamson, chrisw, kvm, qemu-devel, avi, kraxel
Paul Brook wrote:
>>> Alex proposed to disambiguate by adding "identified properties of the
>>> immediate parent bus and device" to the path component. For PCI, these
>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>> bus address. The driver name carries no information!
>> From user POV, driver names are very handly to address a device
>> intuitively - except for the case you have tones of devices on the same
>> bus that are handled by the same driver. For that case we need to
>> augment the device name with a useful per-bus ID, derived from the bus
>> address where available, otherwise based on instance numbers.
>
> This is where I think you're missing a trick. We don't need to augment the
> name, we just need to allow the bus id to be used instead.
I prefer having one name per device, both unique AND human-friendly.
Adding yet another alias will solve only the first requirement. E.g.,
which one should I present to the monitor user when listing a bus for
auto-completion or path error reporting?
>
>>> For other buses, we need to make something up.
>>>
>>> Note that addressing by bus address rather than name is generally
>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>> being able to say something like "device_del pci.0/04.0".
>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>> the bus first before you can identify which device you want to remove.
>
> We can allow both.
>
> A bus address is sufficient to uniquely identify a device. I see no reason to
> require the driver name, or to include it in the canonical device address.
Readability and simplicity (less aliases - for the same reason, I'm
removing ID-based addresses from qtree paths, restricting them to the
global, flat namespace).
>
>>> An easy way to get that is to reserve part of the name space for bus
>>> addresses. If the path component starts with a letter, it's an ID or
>>> driver name. If it starts with say '@', it's a bus address in
>>> bus-specific syntax. The bus provides a method to look it up.
>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>> set for buses that implement some to-be-defined device addressing
>> service, the latter is the default on buses where that service is not
>> available.
>
> If we have bus-address then I see no good reason to also add instance-no.
> For busses that no natural address, we can define the address to be an
> instance number.
Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
devices registered before them.
>
>>> That way, we gain a useful feature, and avoid having an savevm-specific
>>> "device path" that isn't recognized anywhere else.
>> Agreed, we should find one solution for all use cases.
>
> I wasn't aware that there was any suggestion of a separate savevm-specific
> path. The whole point of a device path is to uniquely identify a device
> within a machine. There may be many different paths that identify the same
> device. When given a device and asked to generate path, the result should be
> the canonical address. IMO this should be the least volatile, and avoid
> redundant information.
Given that it is also user-visible, it should also have an intuitive and
informative format to avoid confusions. That may imply slightly more
information than strictly required for machine-based processing.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 11:45 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 11:45 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, Markus Armbruster, qemu-devel, Alex Williamson, avi, kraxel
Paul Brook wrote:
>>> Alex proposed to disambiguate by adding "identified properties of the
>>> immediate parent bus and device" to the path component. For PCI, these
>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>> bus address. The driver name carries no information!
>> From user POV, driver names are very handly to address a device
>> intuitively - except for the case you have tones of devices on the same
>> bus that are handled by the same driver. For that case we need to
>> augment the device name with a useful per-bus ID, derived from the bus
>> address where available, otherwise based on instance numbers.
>
> This is where I think you're missing a trick. We don't need to augment the
> name, we just need to allow the bus id to be used instead.
I prefer having one name per device, both unique AND human-friendly.
Adding yet another alias will solve only the first requirement. E.g.,
which one should I present to the monitor user when listing a bus for
auto-completion or path error reporting?
>
>>> For other buses, we need to make something up.
>>>
>>> Note that addressing by bus address rather than name is generally
>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>> being able to say something like "device_del pci.0/04.0".
>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>> the bus first before you can identify which device you want to remove.
>
> We can allow both.
>
> A bus address is sufficient to uniquely identify a device. I see no reason to
> require the driver name, or to include it in the canonical device address.
Readability and simplicity (less aliases - for the same reason, I'm
removing ID-based addresses from qtree paths, restricting them to the
global, flat namespace).
>
>>> An easy way to get that is to reserve part of the name space for bus
>>> addresses. If the path component starts with a letter, it's an ID or
>>> driver name. If it starts with say '@', it's a bus address in
>>> bus-specific syntax. The bus provides a method to look it up.
>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>> set for buses that implement some to-be-defined device addressing
>> service, the latter is the default on buses where that service is not
>> available.
>
> If we have bus-address then I see no good reason to also add instance-no.
> For busses that no natural address, we can define the address to be an
> instance number.
Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
devices registered before them.
>
>>> That way, we gain a useful feature, and avoid having an savevm-specific
>>> "device path" that isn't recognized anywhere else.
>> Agreed, we should find one solution for all use cases.
>
> I wasn't aware that there was any suggestion of a separate savevm-specific
> path. The whole point of a device path is to uniquely identify a device
> within a machine. There may be many different paths that identify the same
> device. When given a device and asked to generate path, the result should be
> the canonical address. IMO this should be the least volatile, and avoid
> redundant information.
Given that it is also user-visible, it should also have an intuitive and
informative format to avoid confusions. That may imply slightly more
information than strictly required for machine-based processing.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 11:42 ` Markus Armbruster
@ 2010-06-15 11:59 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 11:59 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kraxel, kvm, qemu-devel, Alex Williamson, avi, Paul Brook
Markus Armbruster wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> Markus Armbruster wrote:
>>> Paul Brook <paul@codesourcery.com> writes:
>>>
>>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>>
>>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>>> Could you explain why you add "identified properties of the immediate
>>>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>>>> path" in the qdev sense...
>>>>> In order to try to get a unique string. Without looking into device
>>>>> properties, two e1000s would both be:
>>>>>
>>>>> /main-system-bus/pci.0/e1000
>>>>> /main-system-bus/pci.0/e1000
>>>>>
>>>>> Which is no better than simply "e1000" and would require us to fall back
>>>>> to instance ids again. The goal here is that anything that makes use of
>>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>>> You already got the information you need, you just put it in the wrong place.
>>>> The canonical ID for the device could be its bus address. In practice we'd
>>>> probably want to allow the user to specify it by name, provided these are
>>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>>
>>>> For busses that don't have a consistent addressing scheme then some sort of
>>>> instance ID is unavoidable. I guess it may be possible to invent something
>>>> based on other device properties (e.g. address of the first IO port/memory
>>>> region).
>>> When that's inconvenient or impossible, we can still punt to user: make
>>> device ID mandatory.
>> No option due to auto-created devices. And auto-generating IDs would
>> just create usability issues.
>
> Auto-generated IDs would become part of the ABI. Really so bad that
> it's "no option"? Mind, device ID becomes mandatory *only* for devices
> that don't have a useful bus address. We could even waive the ID
> requirement for the first device of a kind, i.e. require ID if and only
> if it's needed to disambiguate.
IDs are there to find devices the user (or a higher level tool) passed
to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
a well-organized hierarchy. That allows to explore and address a qtree
element at the same time.
>
>>> We obviously need a way to unambigously name a device. It's okay to
>>> have multiple names for the same device.
>>>
>>> If the device has a device ID, that's an unambigous name.
>>>
>>> qdev paths may be ambigous when path components are resolved to driver
>>> names instead of IDs.
>>>
>>> Alex proposed to disambiguate by adding "identified properties of the
>>> immediate parent bus and device" to the path component. For PCI, these
>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>> bus address. The driver name carries no information!
>> >From user POV, driver names are very handly to address a device
>> intuitively - except for the case you have tones of devices on the same
>> bus that are handled by the same driver. For that case we need to
>> augment the device name with a useful per-bus ID, derived from the bus
>> address where available, otherwise based on instance numbers.
>
> I'm not arguing against the use of driver names at all.
>
>>> For other buses, we need to make something up.
>>>
>>> Note that addressing by bus address rather than name is generally
>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>> being able to say something like "device_del pci.0/04.0".
>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>> the bus first before you can identify which device you want to remove.
>
> It's not either/or. Addressing by ID continues to work. Addressing by
> bus/driver-name continues to work. We merely add addressing by
> bus/@bus-address.
The format I will propose is "global-ID|/absolute/path", no more
/path/global-ID as this comes with the risk of ambiguity (ID may shadow
bus-local name of a device).
>
>>> An easy way to get that is to reserve part of the name space for bus
>>> addresses. If the path component starts with a letter, it's an ID or
>>> driver name. If it starts with say '@', it's a bus address in
>>> bus-specific syntax. The bus provides a method to look it up.
>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>> set for buses that implement some to-be-defined device addressing
>> service, the latter is the default on buses where that service is not
>> available.
>
> I object to <driver>@<bus-address>, because the <driver> part carries no
> information.
I does for a human being as bus addresses tend to be unreadable and can
easily be confused, hence the additional, sometimes redundant driver name.
>
> Not the case for <driver>.<instance-no>. We still need a suitable
> definition of <instance-no>. Possible definitions:
>
> * n-th creation of a <driver> device. Drawbacks: depends on creation
> order. Relatively hard to maintain across migration.
>
> * n-th instance of a <driver> device. Drawback: changes on unplug.
> Good enough for interactive use, but it doesn't provide a stable
> device name.
Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.
>
> When counting <driver> devices either way, we can count per bus or
> globally. I prefer per bus.
Yes, counting should be both per-driver and per-bus ("the <n>th device
managed by <driver> on this bus").
>
> None of the above instance numbers are nearly as neat as bus addresses.
Right, wherever they are available.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 11:59 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 11:59 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kvm, Paul Brook, qemu-devel, Alex Williamson, avi, kraxel
Markus Armbruster wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> Markus Armbruster wrote:
>>> Paul Brook <paul@codesourcery.com> writes:
>>>
>>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>>
>>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>>> Could you explain why you add "identified properties of the immediate
>>>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>>>> path" in the qdev sense...
>>>>> In order to try to get a unique string. Without looking into device
>>>>> properties, two e1000s would both be:
>>>>>
>>>>> /main-system-bus/pci.0/e1000
>>>>> /main-system-bus/pci.0/e1000
>>>>>
>>>>> Which is no better than simply "e1000" and would require us to fall back
>>>>> to instance ids again. The goal here is that anything that makes use of
>>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>>> You already got the information you need, you just put it in the wrong place.
>>>> The canonical ID for the device could be its bus address. In practice we'd
>>>> probably want to allow the user to specify it by name, provided these are
>>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>>
>>>> For busses that don't have a consistent addressing scheme then some sort of
>>>> instance ID is unavoidable. I guess it may be possible to invent something
>>>> based on other device properties (e.g. address of the first IO port/memory
>>>> region).
>>> When that's inconvenient or impossible, we can still punt to user: make
>>> device ID mandatory.
>> No option due to auto-created devices. And auto-generating IDs would
>> just create usability issues.
>
> Auto-generated IDs would become part of the ABI. Really so bad that
> it's "no option"? Mind, device ID becomes mandatory *only* for devices
> that don't have a useful bus address. We could even waive the ID
> requirement for the first device of a kind, i.e. require ID if and only
> if it's needed to disambiguate.
IDs are there to find devices the user (or a higher level tool) passed
to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
a well-organized hierarchy. That allows to explore and address a qtree
element at the same time.
>
>>> We obviously need a way to unambigously name a device. It's okay to
>>> have multiple names for the same device.
>>>
>>> If the device has a device ID, that's an unambigous name.
>>>
>>> qdev paths may be ambigous when path components are resolved to driver
>>> names instead of IDs.
>>>
>>> Alex proposed to disambiguate by adding "identified properties of the
>>> immediate parent bus and device" to the path component. For PCI, these
>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>> bus address. The driver name carries no information!
>> >From user POV, driver names are very handly to address a device
>> intuitively - except for the case you have tones of devices on the same
>> bus that are handled by the same driver. For that case we need to
>> augment the device name with a useful per-bus ID, derived from the bus
>> address where available, otherwise based on instance numbers.
>
> I'm not arguing against the use of driver names at all.
>
>>> For other buses, we need to make something up.
>>>
>>> Note that addressing by bus address rather than name is generally
>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>> being able to say something like "device_del pci.0/04.0".
>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>> the bus first before you can identify which device you want to remove.
>
> It's not either/or. Addressing by ID continues to work. Addressing by
> bus/driver-name continues to work. We merely add addressing by
> bus/@bus-address.
The format I will propose is "global-ID|/absolute/path", no more
/path/global-ID as this comes with the risk of ambiguity (ID may shadow
bus-local name of a device).
>
>>> An easy way to get that is to reserve part of the name space for bus
>>> addresses. If the path component starts with a letter, it's an ID or
>>> driver name. If it starts with say '@', it's a bus address in
>>> bus-specific syntax. The bus provides a method to look it up.
>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>> set for buses that implement some to-be-defined device addressing
>> service, the latter is the default on buses where that service is not
>> available.
>
> I object to <driver>@<bus-address>, because the <driver> part carries no
> information.
I does for a human being as bus addresses tend to be unreadable and can
easily be confused, hence the additional, sometimes redundant driver name.
>
> Not the case for <driver>.<instance-no>. We still need a suitable
> definition of <instance-no>. Possible definitions:
>
> * n-th creation of a <driver> device. Drawbacks: depends on creation
> order. Relatively hard to maintain across migration.
>
> * n-th instance of a <driver> device. Drawback: changes on unplug.
> Good enough for interactive use, but it doesn't provide a stable
> device name.
Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.
>
> When counting <driver> devices either way, we can count per bus or
> globally. I prefer per bus.
Yes, counting should be both per-driver and per-bus ("the <n>th device
managed by <driver> on this bus").
>
> None of the above instance numbers are nearly as neat as bus addresses.
Right, wherever they are available.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 11:45 ` Jan Kiszka
@ 2010-06-15 12:04 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 12:04 UTC (permalink / raw)
To: qemu-devel
Cc: Jan Kiszka, chrisw, kvm, Markus Armbruster, Alex Williamson, avi, kraxel
> >> From user POV, driver names are very handly to address a device
> >> intuitively - except for the case you have tones of devices on the same
> >> bus that are handled by the same driver. For that case we need to
> >> augment the device name with a useful per-bus ID, derived from the bus
> >> address where available, otherwise based on instance numbers.
> >
> > This is where I think you're missing a trick. We don't need to augment
> > the name, we just need to allow the bus id to be used instead.
>
> I prefer having one name per device, both unique AND human-friendly.
> Adding yet another alias will solve only the first requirement. E.g.,
> which one should I present to the monitor user when listing a bus for
> auto-completion or path error reporting?
Autocompletion can report all of them. Errors should report either what the
user specified (if the problem is with the address), or the canonical address
(if the problem is unrelated to the address).
Remember that we also have global aliases (paths that do not begin with "/").
> >>> An easy way to get that is to reserve part of the name space for bus
> >>> addresses. If the path component starts with a letter, it's an ID or
> >>> driver name. If it starts with say '@', it's a bus address in
> >>> bus-specific syntax. The bus provides a method to look it up.
> >>
> >> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
> >> set for buses that implement some to-be-defined device addressing
> >> service, the latter is the default on buses where that service is not
> >> available.
> >
> > If we have bus-address then I see no good reason to also add instance-no.
> > For busses that no natural address, we can define the address to be an
> > instance number.
>
> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
> devices registered before them.
I don't think either of these are intuitive. There's a good chance that
isa-serial.0 will not correspond to the first serial port in the guest.
Much better would be allowing use of IO port or MMIO addresses to identify ISA
devices. Some modification to the ISABus code may be required to implement
this.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 12:04 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 12:04 UTC (permalink / raw)
To: qemu-devel
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, Alex Williamson, avi, kraxel
> >> From user POV, driver names are very handly to address a device
> >> intuitively - except for the case you have tones of devices on the same
> >> bus that are handled by the same driver. For that case we need to
> >> augment the device name with a useful per-bus ID, derived from the bus
> >> address where available, otherwise based on instance numbers.
> >
> > This is where I think you're missing a trick. We don't need to augment
> > the name, we just need to allow the bus id to be used instead.
>
> I prefer having one name per device, both unique AND human-friendly.
> Adding yet another alias will solve only the first requirement. E.g.,
> which one should I present to the monitor user when listing a bus for
> auto-completion or path error reporting?
Autocompletion can report all of them. Errors should report either what the
user specified (if the problem is with the address), or the canonical address
(if the problem is unrelated to the address).
Remember that we also have global aliases (paths that do not begin with "/").
> >>> An easy way to get that is to reserve part of the name space for bus
> >>> addresses. If the path component starts with a letter, it's an ID or
> >>> driver name. If it starts with say '@', it's a bus address in
> >>> bus-specific syntax. The bus provides a method to look it up.
> >>
> >> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
> >> set for buses that implement some to-be-defined device addressing
> >> service, the latter is the default on buses where that service is not
> >> available.
> >
> > If we have bus-address then I see no good reason to also add instance-no.
> > For busses that no natural address, we can define the address to be an
> > instance number.
>
> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
> devices registered before them.
I don't think either of these are intuitive. There's a good chance that
isa-serial.0 will not correspond to the first serial port in the guest.
Much better would be allowing use of IO port or MMIO addresses to identify ISA
devices. Some modification to the ISABus code may be required to implement
this.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 12:04 ` Paul Brook
@ 2010-06-15 12:16 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 12:16 UTC (permalink / raw)
To: Paul Brook
Cc: qemu-devel, chrisw, kvm, Markus Armbruster, Alex Williamson, avi, kraxel
Paul Brook wrote:
>>>> From user POV, driver names are very handly to address a device
>>>> intuitively - except for the case you have tones of devices on the same
>>>> bus that are handled by the same driver. For that case we need to
>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>> address where available, otherwise based on instance numbers.
>>> This is where I think you're missing a trick. We don't need to augment
>>> the name, we just need to allow the bus id to be used instead.
>> I prefer having one name per device, both unique AND human-friendly.
>> Adding yet another alias will solve only the first requirement. E.g.,
>> which one should I present to the monitor user when listing a bus for
>> auto-completion or path error reporting?
>
> Autocompletion can report all of them.
Autocompletion can only provide what is later on parseable. It doesn't
help to see "e1000" and "03.0" as device addresses because you do not
know their relation that way. Only combining the information into a
single name does.
> Errors should report either what the
> user specified (if the problem is with the address), or the canonical address
> (if the problem is unrelated to the address).
>
> Remember that we also have global aliases (paths that do not begin with "/").
They only help if the user set them and therefore should know their
semantics.
>
>>>>> An easy way to get that is to reserve part of the name space for bus
>>>>> addresses. If the path component starts with a letter, it's an ID or
>>>>> driver name. If it starts with say '@', it's a bus address in
>>>>> bus-specific syntax. The bus provides a method to look it up.
>>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>>> set for buses that implement some to-be-defined device addressing
>>>> service, the latter is the default on buses where that service is not
>>>> available.
>>> If we have bus-address then I see no good reason to also add instance-no.
>>> For busses that no natural address, we can define the address to be an
>>> instance number.
>> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
>> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
>> devices registered before them.
>
> I don't think either of these are intuitive. There's a good chance that
> isa-serial.0 will not correspond to the first serial port in the guest.
Only if you start tweaking the base addresses. Then it will still
correspond to the addition order AND the user should be aware of this
special setup.
> Much better would be allowing use of IO port or MMIO addresses to identify ISA
> devices. Some modification to the ISABus code may be required to implement
> this.
Works for serial, but fails for ISA devices not occupying an address.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 12:16 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 12:16 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, Alex Williamson, avi, kraxel
Paul Brook wrote:
>>>> From user POV, driver names are very handly to address a device
>>>> intuitively - except for the case you have tones of devices on the same
>>>> bus that are handled by the same driver. For that case we need to
>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>> address where available, otherwise based on instance numbers.
>>> This is where I think you're missing a trick. We don't need to augment
>>> the name, we just need to allow the bus id to be used instead.
>> I prefer having one name per device, both unique AND human-friendly.
>> Adding yet another alias will solve only the first requirement. E.g.,
>> which one should I present to the monitor user when listing a bus for
>> auto-completion or path error reporting?
>
> Autocompletion can report all of them.
Autocompletion can only provide what is later on parseable. It doesn't
help to see "e1000" and "03.0" as device addresses because you do not
know their relation that way. Only combining the information into a
single name does.
> Errors should report either what the
> user specified (if the problem is with the address), or the canonical address
> (if the problem is unrelated to the address).
>
> Remember that we also have global aliases (paths that do not begin with "/").
They only help if the user set them and therefore should know their
semantics.
>
>>>>> An easy way to get that is to reserve part of the name space for bus
>>>>> addresses. If the path component starts with a letter, it's an ID or
>>>>> driver name. If it starts with say '@', it's a bus address in
>>>>> bus-specific syntax. The bus provides a method to look it up.
>>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>>> set for buses that implement some to-be-defined device addressing
>>>> service, the latter is the default on buses where that service is not
>>>> available.
>>> If we have bus-address then I see no good reason to also add instance-no.
>>> For busses that no natural address, we can define the address to be an
>>> instance number.
>> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
>> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
>> devices registered before them.
>
> I don't think either of these are intuitive. There's a good chance that
> isa-serial.0 will not correspond to the first serial port in the guest.
Only if you start tweaking the base addresses. Then it will still
correspond to the addition order AND the user should be aware of this
special setup.
> Much better would be allowing use of IO port or MMIO addresses to identify ISA
> devices. Some modification to the ISABus code may be required to implement
> this.
Works for serial, but fails for ISA devices not occupying an address.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 12:16 ` Jan Kiszka
@ 2010-06-15 12:39 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 12:39 UTC (permalink / raw)
To: Jan Kiszka
Cc: qemu-devel, chrisw, kvm, Markus Armbruster, Alex Williamson, avi, kraxel
> Paul Brook wrote:
> >>>> From user POV, driver names are very handly to address a device
> >>>> intuitively - except for the case you have tones of devices on the
> >>>> same bus that are handled by the same driver. For that case we need
> >>>> to augment the device name with a useful per-bus ID, derived from the
> >>>> bus address where available, otherwise based on instance numbers.
> >>>
> >>> This is where I think you're missing a trick. We don't need to augment
> >>> the name, we just need to allow the bus id to be used instead.
> >>
> >> I prefer having one name per device, both unique AND human-friendly.
> >> Adding yet another alias will solve only the first requirement. E.g.,
> >> which one should I present to the monitor user when listing a bus for
> >> auto-completion or path error reporting?
> >
> > Autocompletion can report all of them.
>
> Autocompletion can only provide what is later on parseable.
Of course.
> It doesn't
> help to see "e1000" and "03.0" as device addresses because you do not
> know their relation that way. Only combining the information into a
> single name does.
I don't get your argument here. Why shouldn't e1000 and @03.0 refer to the
same device? Querying the device itself will tell you both, so it's not hard
to figure out that they refer to the same thing. Either piece of information
is sufficient, so why do we require both?
Note that autocompletion and enumeration for mechanical traversal are
different problems. The former should include useful aliases for humans (i.e.
both e1000 and @03.0). The latter should be limited to the unique values
corresponding to canonical addresses (i.e. @03.0).
> >> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
> >> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
> >> devices registered before them.
> >
> > I don't think either of these are intuitive. There's a good chance that
> > isa-serial.0 will not correspond to the first serial port in the guest.
>
> Only if you start tweaking the base addresses. Then it will still
> correspond to the addition order AND the user should be aware of this
> special setup.
I'm pretty sure there are some machines that have both internal UARTs
(considered to be the primary ports), and secondary ports on an ISA bus.
If you really want instance numbers, then they may make most sense appended to
the driver name. However I think this should be independent of bus addressing,
and bus addresses make most sense as the canonical address.
> > Much better would be allowing use of IO port or MMIO addresses to
> > identify ISA devices. Some modification to the ISABus code may be
> > required to implement this.
>
> Works for serial, but fails for ISA devices not occupying an address.
An ISA device without an IO/MMIO capabilities seems extremely unlikely. What
exactly would such a device do?
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 12:39 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 12:39 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, Alex Williamson, avi, kraxel
> Paul Brook wrote:
> >>>> From user POV, driver names are very handly to address a device
> >>>> intuitively - except for the case you have tones of devices on the
> >>>> same bus that are handled by the same driver. For that case we need
> >>>> to augment the device name with a useful per-bus ID, derived from the
> >>>> bus address where available, otherwise based on instance numbers.
> >>>
> >>> This is where I think you're missing a trick. We don't need to augment
> >>> the name, we just need to allow the bus id to be used instead.
> >>
> >> I prefer having one name per device, both unique AND human-friendly.
> >> Adding yet another alias will solve only the first requirement. E.g.,
> >> which one should I present to the monitor user when listing a bus for
> >> auto-completion or path error reporting?
> >
> > Autocompletion can report all of them.
>
> Autocompletion can only provide what is later on parseable.
Of course.
> It doesn't
> help to see "e1000" and "03.0" as device addresses because you do not
> know their relation that way. Only combining the information into a
> single name does.
I don't get your argument here. Why shouldn't e1000 and @03.0 refer to the
same device? Querying the device itself will tell you both, so it's not hard
to figure out that they refer to the same thing. Either piece of information
is sufficient, so why do we require both?
Note that autocompletion and enumeration for mechanical traversal are
different problems. The former should include useful aliases for humans (i.e.
both e1000 and @03.0). The latter should be limited to the unique values
corresponding to canonical addresses (i.e. @03.0).
> >> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
> >> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
> >> devices registered before them.
> >
> > I don't think either of these are intuitive. There's a good chance that
> > isa-serial.0 will not correspond to the first serial port in the guest.
>
> Only if you start tweaking the base addresses. Then it will still
> correspond to the addition order AND the user should be aware of this
> special setup.
I'm pretty sure there are some machines that have both internal UARTs
(considered to be the primary ports), and secondary ports on an ISA bus.
If you really want instance numbers, then they may make most sense appended to
the driver name. However I think this should be independent of bus addressing,
and bus addresses make most sense as the canonical address.
> > Much better would be allowing use of IO port or MMIO addresses to
> > identify ISA devices. Some modification to the ISABus code may be
> > required to implement this.
>
> Works for serial, but fails for ISA devices not occupying an address.
An ISA device without an IO/MMIO capabilities seems extremely unlikely. What
exactly would such a device do?
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 12:39 ` Paul Brook
@ 2010-06-15 13:00 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 13:00 UTC (permalink / raw)
To: Paul Brook
Cc: qemu-devel, chrisw, kvm, Markus Armbruster, Alex Williamson, avi, kraxel
Paul Brook wrote:
>> Paul Brook wrote:
>>>>>> From user POV, driver names are very handly to address a device
>>>>>> intuitively - except for the case you have tones of devices on the
>>>>>> same bus that are handled by the same driver. For that case we need
>>>>>> to augment the device name with a useful per-bus ID, derived from the
>>>>>> bus address where available, otherwise based on instance numbers.
>>>>> This is where I think you're missing a trick. We don't need to augment
>>>>> the name, we just need to allow the bus id to be used instead.
>>>> I prefer having one name per device, both unique AND human-friendly.
>>>> Adding yet another alias will solve only the first requirement. E.g.,
>>>> which one should I present to the monitor user when listing a bus for
>>>> auto-completion or path error reporting?
>>> Autocompletion can report all of them.
>> Autocompletion can only provide what is later on parseable.
>
> Of course.
>
>> It doesn't
>> help to see "e1000" and "03.0" as device addresses because you do not
>> know their relation that way. Only combining the information into a
>> single name does.
>
> I don't get your argument here. Why shouldn't e1000 and @03.0 refer to the
> same device? Querying the device itself will tell you both, so it's not hard
> to figure out that they refer to the same thing. Either piece of information
> is sufficient, so why do we require both?
To avoid having to issue an "info qtree" in the middle of an
auto-completion for some other command.
>
> Note that autocompletion and enumeration for mechanical traversal are
> different problems. The former should include useful aliases for humans (i.e.
> both e1000 and @03.0). The latter should be limited to the unique values
> corresponding to canonical addresses (i.e. @03.0).
>
>>>> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
>>>> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
>>>> devices registered before them.
>>> I don't think either of these are intuitive. There's a good chance that
>>> isa-serial.0 will not correspond to the first serial port in the guest.
>> Only if you start tweaking the base addresses. Then it will still
>> correspond to the addition order AND the user should be aware of this
>> special setup.
>
> I'm pretty sure there are some machines that have both internal UARTs
> (considered to be the primary ports), and secondary ports on an ISA bus.
>
> If you really want instance numbers, then they may make most sense appended to
> the driver name. However I think this should be independent of bus addressing,
> and bus addresses make most sense as the canonical address.
That's how my current implementation looks like.
>
>>> Much better would be allowing use of IO port or MMIO addresses to
>>> identify ISA devices. Some modification to the ISABus code may be
>>> required to implement this.
>> Works for serial, but fails for ISA devices not occupying an address.
>
> An ISA device without an IO/MMIO capabilities seems extremely unlikely. What
> exactly would such a device do?
Inject interrupts via that bus (while exposing registers in some other
way). The m48t59 seems to fall in this category (unless I'm missing
something ATM).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 13:00 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 13:00 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, Alex Williamson, avi, kraxel
Paul Brook wrote:
>> Paul Brook wrote:
>>>>>> From user POV, driver names are very handly to address a device
>>>>>> intuitively - except for the case you have tones of devices on the
>>>>>> same bus that are handled by the same driver. For that case we need
>>>>>> to augment the device name with a useful per-bus ID, derived from the
>>>>>> bus address where available, otherwise based on instance numbers.
>>>>> This is where I think you're missing a trick. We don't need to augment
>>>>> the name, we just need to allow the bus id to be used instead.
>>>> I prefer having one name per device, both unique AND human-friendly.
>>>> Adding yet another alias will solve only the first requirement. E.g.,
>>>> which one should I present to the monitor user when listing a bus for
>>>> auto-completion or path error reporting?
>>> Autocompletion can report all of them.
>> Autocompletion can only provide what is later on parseable.
>
> Of course.
>
>> It doesn't
>> help to see "e1000" and "03.0" as device addresses because you do not
>> know their relation that way. Only combining the information into a
>> single name does.
>
> I don't get your argument here. Why shouldn't e1000 and @03.0 refer to the
> same device? Querying the device itself will tell you both, so it's not hard
> to figure out that they refer to the same thing. Either piece of information
> is sufficient, so why do we require both?
To avoid having to issue an "info qtree" in the middle of an
auto-completion for some other command.
>
> Note that autocompletion and enumeration for mechanical traversal are
> different problems. The former should include useful aliases for humans (i.e.
> both e1000 and @03.0). The latter should be limited to the unique values
> corresponding to canonical addresses (i.e. @03.0).
>
>>>> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
>>>> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
>>>> devices registered before them.
>>> I don't think either of these are intuitive. There's a good chance that
>>> isa-serial.0 will not correspond to the first serial port in the guest.
>> Only if you start tweaking the base addresses. Then it will still
>> correspond to the addition order AND the user should be aware of this
>> special setup.
>
> I'm pretty sure there are some machines that have both internal UARTs
> (considered to be the primary ports), and secondary ports on an ISA bus.
>
> If you really want instance numbers, then they may make most sense appended to
> the driver name. However I think this should be independent of bus addressing,
> and bus addresses make most sense as the canonical address.
That's how my current implementation looks like.
>
>>> Much better would be allowing use of IO port or MMIO addresses to
>>> identify ISA devices. Some modification to the ISABus code may be
>>> required to implement this.
>> Works for serial, but fails for ISA devices not occupying an address.
>
> An ISA device without an IO/MMIO capabilities seems extremely unlikely. What
> exactly would such a device do?
Inject interrupts via that bus (while exposing registers in some other
way). The m48t59 seems to fall in this category (unless I'm missing
something ATM).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 11:59 ` Jan Kiszka
@ 2010-06-15 13:07 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 13:07 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, Paul Brook, qemu-devel, Alex Williamson, avi, kraxel
Jan Kiszka <jan.kiszka@siemens.com> writes:
> Markus Armbruster wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>
>>> Markus Armbruster wrote:
>>>> Paul Brook <paul@codesourcery.com> writes:
>>>>
>>>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>>>
>>>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>>>> Could you explain why you add "identified properties of the immediate
>>>>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>>>>> path" in the qdev sense...
>>>>>> In order to try to get a unique string. Without looking into device
>>>>>> properties, two e1000s would both be:
>>>>>>
>>>>>> /main-system-bus/pci.0/e1000
>>>>>> /main-system-bus/pci.0/e1000
>>>>>>
>>>>>> Which is no better than simply "e1000" and would require us to fall back
>>>>>> to instance ids again. The goal here is that anything that makes use of
>>>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>>>> You already got the information you need, you just put it in the wrong place.
>>>>> The canonical ID for the device could be its bus address. In practice we'd
>>>>> probably want to allow the user to specify it by name, provided these are
>>>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>>>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>>>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>>>
>>>>> For busses that don't have a consistent addressing scheme then some sort of
>>>>> instance ID is unavoidable. I guess it may be possible to invent something
>>>>> based on other device properties (e.g. address of the first IO port/memory
>>>>> region).
>>>> When that's inconvenient or impossible, we can still punt to user: make
>>>> device ID mandatory.
>>> No option due to auto-created devices. And auto-generating IDs would
>>> just create usability issues.
>>
>> Auto-generated IDs would become part of the ABI. Really so bad that
>> it's "no option"? Mind, device ID becomes mandatory *only* for devices
>> that don't have a useful bus address. We could even waive the ID
>> requirement for the first device of a kind, i.e. require ID if and only
>> if it's needed to disambiguate.
>
> IDs are there to find devices the user (or a higher level tool) passed
> to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
> a well-organized hierarchy. That allows to explore and address a qtree
> element at the same time.
>
>>
>>>> We obviously need a way to unambigously name a device. It's okay to
>>>> have multiple names for the same device.
>>>>
>>>> If the device has a device ID, that's an unambigous name.
>>>>
>>>> qdev paths may be ambigous when path components are resolved to driver
>>>> names instead of IDs.
>>>>
>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>> immediate parent bus and device" to the path component. For PCI, these
>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>> bus address. The driver name carries no information!
>>> >From user POV, driver names are very handly to address a device
>>> intuitively - except for the case you have tones of devices on the same
>>> bus that are handled by the same driver. For that case we need to
>>> augment the device name with a useful per-bus ID, derived from the bus
>>> address where available, otherwise based on instance numbers.
>>
>> I'm not arguing against the use of driver names at all.
>>
>>>> For other buses, we need to make something up.
>>>>
>>>> Note that addressing by bus address rather than name is generally
>>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>>> being able to say something like "device_del pci.0/04.0".
>>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>>> the bus first before you can identify which device you want to remove.
>>
>> It's not either/or. Addressing by ID continues to work. Addressing by
>> bus/driver-name continues to work. We merely add addressing by
>> bus/@bus-address.
>
> The format I will propose is "global-ID|/absolute/path", no more
> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
> bus-local name of a device).
Doesn't this break existing usage?
We have a rule to resolve any ambiguity added by ID: it always takes
precedence over driver name. What path/ID does add is shadowing: it can
make a device inaccessible by driver name. Not much of a difference to
adding a second device with the same driver name.
>>>> An easy way to get that is to reserve part of the name space for bus
>>>> addresses. If the path component starts with a letter, it's an ID or
>>>> driver name. If it starts with say '@', it's a bus address in
>>>> bus-specific syntax. The bus provides a method to look it up.
>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>> set for buses that implement some to-be-defined device addressing
>>> service, the latter is the default on buses where that service is not
>>> available.
>>
>> I object to <driver>@<bus-address>, because the <driver> part carries no
>> information.
>
> I does for a human being as bus addresses tend to be unreadable and can
> easily be confused, hence the additional, sometimes redundant driver name.
I *strenuously* object to making the driver name mandatory with
bus-address addressing.
If you think the human user needs to be protected from mistakes by
making him supply redundant information, then "device_del pci.0/04.0
e1000" is much better way than complicating device paths for human and
machine users alike, not to mention uses internal to QEMU.
>> Not the case for <driver>.<instance-no>. We still need a suitable
>> definition of <instance-no>. Possible definitions:
>>
>> * n-th creation of a <driver> device. Drawbacks: depends on creation
>> order. Relatively hard to maintain across migration.
>>
>> * n-th instance of a <driver> device. Drawback: changes on unplug.
>> Good enough for interactive use, but it doesn't provide a stable
>> device name.
>
> Every hotplug-capable bus must have a proper addressing scheme, I think
> this is a reasonable and achievable requirement. Then we don't need
> instance numbers for those buses.
What about USB?
>> When counting <driver> devices either way, we can count per bus or
>> globally. I prefer per bus.
>
> Yes, counting should be both per-driver and per-bus ("the <n>th device
> managed by <driver> on this bus").
Works for me.
>> None of the above instance numbers are nearly as neat as bus addresses.
>
> Right, wherever they are available.
>
> Jan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 13:07 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 13:07 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kraxel, kvm, qemu-devel, Alex Williamson, avi, Paul Brook
Jan Kiszka <jan.kiszka@siemens.com> writes:
> Markus Armbruster wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>
>>> Markus Armbruster wrote:
>>>> Paul Brook <paul@codesourcery.com> writes:
>>>>
>>>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>>>
>>>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>>>> Could you explain why you add "identified properties of the immediate
>>>>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>>>>> path" in the qdev sense...
>>>>>> In order to try to get a unique string. Without looking into device
>>>>>> properties, two e1000s would both be:
>>>>>>
>>>>>> /main-system-bus/pci.0/e1000
>>>>>> /main-system-bus/pci.0/e1000
>>>>>>
>>>>>> Which is no better than simply "e1000" and would require us to fall back
>>>>>> to instance ids again. The goal here is that anything that makes use of
>>>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>>>> You already got the information you need, you just put it in the wrong place.
>>>>> The canonical ID for the device could be its bus address. In practice we'd
>>>>> probably want to allow the user to specify it by name, provided these are
>>>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>>>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>>>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>>>
>>>>> For busses that don't have a consistent addressing scheme then some sort of
>>>>> instance ID is unavoidable. I guess it may be possible to invent something
>>>>> based on other device properties (e.g. address of the first IO port/memory
>>>>> region).
>>>> When that's inconvenient or impossible, we can still punt to user: make
>>>> device ID mandatory.
>>> No option due to auto-created devices. And auto-generating IDs would
>>> just create usability issues.
>>
>> Auto-generated IDs would become part of the ABI. Really so bad that
>> it's "no option"? Mind, device ID becomes mandatory *only* for devices
>> that don't have a useful bus address. We could even waive the ID
>> requirement for the first device of a kind, i.e. require ID if and only
>> if it's needed to disambiguate.
>
> IDs are there to find devices the user (or a higher level tool) passed
> to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
> a well-organized hierarchy. That allows to explore and address a qtree
> element at the same time.
>
>>
>>>> We obviously need a way to unambigously name a device. It's okay to
>>>> have multiple names for the same device.
>>>>
>>>> If the device has a device ID, that's an unambigous name.
>>>>
>>>> qdev paths may be ambigous when path components are resolved to driver
>>>> names instead of IDs.
>>>>
>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>> immediate parent bus and device" to the path component. For PCI, these
>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>> bus address. The driver name carries no information!
>>> >From user POV, driver names are very handly to address a device
>>> intuitively - except for the case you have tones of devices on the same
>>> bus that are handled by the same driver. For that case we need to
>>> augment the device name with a useful per-bus ID, derived from the bus
>>> address where available, otherwise based on instance numbers.
>>
>> I'm not arguing against the use of driver names at all.
>>
>>>> For other buses, we need to make something up.
>>>>
>>>> Note that addressing by bus address rather than name is generally
>>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>>> being able to say something like "device_del pci.0/04.0".
>>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>>> the bus first before you can identify which device you want to remove.
>>
>> It's not either/or. Addressing by ID continues to work. Addressing by
>> bus/driver-name continues to work. We merely add addressing by
>> bus/@bus-address.
>
> The format I will propose is "global-ID|/absolute/path", no more
> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
> bus-local name of a device).
Doesn't this break existing usage?
We have a rule to resolve any ambiguity added by ID: it always takes
precedence over driver name. What path/ID does add is shadowing: it can
make a device inaccessible by driver name. Not much of a difference to
adding a second device with the same driver name.
>>>> An easy way to get that is to reserve part of the name space for bus
>>>> addresses. If the path component starts with a letter, it's an ID or
>>>> driver name. If it starts with say '@', it's a bus address in
>>>> bus-specific syntax. The bus provides a method to look it up.
>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>> set for buses that implement some to-be-defined device addressing
>>> service, the latter is the default on buses where that service is not
>>> available.
>>
>> I object to <driver>@<bus-address>, because the <driver> part carries no
>> information.
>
> I does for a human being as bus addresses tend to be unreadable and can
> easily be confused, hence the additional, sometimes redundant driver name.
I *strenuously* object to making the driver name mandatory with
bus-address addressing.
If you think the human user needs to be protected from mistakes by
making him supply redundant information, then "device_del pci.0/04.0
e1000" is much better way than complicating device paths for human and
machine users alike, not to mention uses internal to QEMU.
>> Not the case for <driver>.<instance-no>. We still need a suitable
>> definition of <instance-no>. Possible definitions:
>>
>> * n-th creation of a <driver> device. Drawbacks: depends on creation
>> order. Relatively hard to maintain across migration.
>>
>> * n-th instance of a <driver> device. Drawback: changes on unplug.
>> Good enough for interactive use, but it doesn't provide a stable
>> device name.
>
> Every hotplug-capable bus must have a proper addressing scheme, I think
> this is a reasonable and achievable requirement. Then we don't need
> instance numbers for those buses.
What about USB?
>> When counting <driver> devices either way, we can count per bus or
>> globally. I prefer per bus.
>
> Yes, counting should be both per-driver and per-bus ("the <n>th device
> managed by <driver> on this bus").
Works for me.
>> None of the above instance numbers are nearly as neat as bus addresses.
>
> Right, wherever they are available.
>
> Jan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 13:00 ` Jan Kiszka
@ 2010-06-15 13:14 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 13:14 UTC (permalink / raw)
To: Jan Kiszka
Cc: qemu-devel, chrisw, kvm, Markus Armbruster, Alex Williamson, avi, kraxel
> >> Works for serial, but fails for ISA devices not occupying an address.
> >
> > An ISA device without an IO/MMIO capabilities seems extremely unlikely.
> > What exactly would such a device do?
>
> Inject interrupts via that bus (while exposing registers in some other
> way). The m48t59 seems to fall in this category (unless I'm missing
> something ATM).
m48t59_isa responds to IO ports. You're probably confused because it has not
been properly converted to the qdev.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 13:14 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 13:14 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, Alex Williamson, avi, kraxel
> >> Works for serial, but fails for ISA devices not occupying an address.
> >
> > An ISA device without an IO/MMIO capabilities seems extremely unlikely.
> > What exactly would such a device do?
>
> Inject interrupts via that bus (while exposing registers in some other
> way). The m48t59 seems to fall in this category (unless I'm missing
> something ATM).
m48t59_isa responds to IO ports. You're probably confused because it has not
been properly converted to the qdev.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 11:45 ` Jan Kiszka
@ 2010-06-15 13:16 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 13:16 UTC (permalink / raw)
To: Jan Kiszka
Cc: Paul Brook, chrisw, kvm, qemu-devel, Alex Williamson, avi, kraxel
Jan Kiszka <jan.kiszka@siemens.com> writes:
> Paul Brook wrote:
>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>> immediate parent bus and device" to the path component. For PCI, these
>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>> bus address. The driver name carries no information!
>>> From user POV, driver names are very handly to address a device
>>> intuitively - except for the case you have tones of devices on the same
>>> bus that are handled by the same driver. For that case we need to
>>> augment the device name with a useful per-bus ID, derived from the bus
>>> address where available, otherwise based on instance numbers.
>>
>> This is where I think you're missing a trick. We don't need to augment the
>> name, we just need to allow the bus id to be used instead.
>
> I prefer having one name per device, both unique AND human-friendly.
> Adding yet another alias will solve only the first requirement. E.g.,
> which one should I present to the monitor user when listing a bus for
> auto-completion or path error reporting?
>
>>
>>>> For other buses, we need to make something up.
>>>>
>>>> Note that addressing by bus address rather than name is generally
>>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>>> being able to say something like "device_del pci.0/04.0".
>>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>>> the bus first before you can identify which device you want to remove.
>>
>> We can allow both.
>>
>> A bus address is sufficient to uniquely identify a device. I see no reason to
>> require the driver name, or to include it in the canonical device address.
>
> Readability and simplicity (less aliases - for the same reason, I'm
> removing ID-based addresses from qtree paths, restricting them to the
> global, flat namespace).
>
>>
>>>> An easy way to get that is to reserve part of the name space for bus
>>>> addresses. If the path component starts with a letter, it's an ID or
>>>> driver name. If it starts with say '@', it's a bus address in
>>>> bus-specific syntax. The bus provides a method to look it up.
>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>> set for buses that implement some to-be-defined device addressing
>>> service, the latter is the default on buses where that service is not
>>> available.
>>
>> If we have bus-address then I see no good reason to also add instance-no.
>> For busses that no natural address, we can define the address to be an
>> instance number.
>
> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
> devices registered before them.
Readability is in the eye of the beholder. If the beholder wants to
number his serial devices a certain way, he better makes his wishes
known with id=, because the system has a hard time guessing them.
>>>> That way, we gain a useful feature, and avoid having an savevm-specific
>>>> "device path" that isn't recognized anywhere else.
>>> Agreed, we should find one solution for all use cases.
>>
>> I wasn't aware that there was any suggestion of a separate savevm-specific
>> path. The whole point of a device path is to uniquely identify a device
>> within a machine. There may be many different paths that identify the same
>> device. When given a device and asked to generate path, the result should be
>> the canonical address. IMO this should be the least volatile, and avoid
>> redundant information.
>
> Given that it is also user-visible, it should also have an intuitive and
> informative format to avoid confusions. That may imply slightly more
> information than strictly required for machine-based processing.
I'm with Paul here.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 13:16 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-15 13:16 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kraxel, kvm, qemu-devel, Alex Williamson, avi, Paul Brook
Jan Kiszka <jan.kiszka@siemens.com> writes:
> Paul Brook wrote:
>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>> immediate parent bus and device" to the path component. For PCI, these
>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>> bus address. The driver name carries no information!
>>> From user POV, driver names are very handly to address a device
>>> intuitively - except for the case you have tones of devices on the same
>>> bus that are handled by the same driver. For that case we need to
>>> augment the device name with a useful per-bus ID, derived from the bus
>>> address where available, otherwise based on instance numbers.
>>
>> This is where I think you're missing a trick. We don't need to augment the
>> name, we just need to allow the bus id to be used instead.
>
> I prefer having one name per device, both unique AND human-friendly.
> Adding yet another alias will solve only the first requirement. E.g.,
> which one should I present to the monitor user when listing a bus for
> auto-completion or path error reporting?
>
>>
>>>> For other buses, we need to make something up.
>>>>
>>>> Note that addressing by bus address rather than name is generally
>>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>>> being able to say something like "device_del pci.0/04.0".
>>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>>> the bus first before you can identify which device you want to remove.
>>
>> We can allow both.
>>
>> A bus address is sufficient to uniquely identify a device. I see no reason to
>> require the driver name, or to include it in the canonical device address.
>
> Readability and simplicity (less aliases - for the same reason, I'm
> removing ID-based addresses from qtree paths, restricting them to the
> global, flat namespace).
>
>>
>>>> An easy way to get that is to reserve part of the name space for bus
>>>> addresses. If the path component starts with a letter, it's an ID or
>>>> driver name. If it starts with say '@', it's a bus address in
>>>> bus-specific syntax. The bus provides a method to look it up.
>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>> set for buses that implement some to-be-defined device addressing
>>> service, the latter is the default on buses where that service is not
>>> available.
>>
>> If we have bus-address then I see no good reason to also add instance-no.
>> For busses that no natural address, we can define the address to be an
>> instance number.
>
> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
> devices registered before them.
Readability is in the eye of the beholder. If the beholder wants to
number his serial devices a certain way, he better makes his wishes
known with id=, because the system has a hard time guessing them.
>>>> That way, we gain a useful feature, and avoid having an savevm-specific
>>>> "device path" that isn't recognized anywhere else.
>>> Agreed, we should find one solution for all use cases.
>>
>> I wasn't aware that there was any suggestion of a separate savevm-specific
>> path. The whole point of a device path is to uniquely identify a device
>> within a machine. There may be many different paths that identify the same
>> device. When given a device and asked to generate path, the result should be
>> the canonical address. IMO this should be the least volatile, and avoid
>> redundant information.
>
> Given that it is also user-visible, it should also have an intuitive and
> informative format to avoid confusions. That may imply slightly more
> information than strictly required for machine-based processing.
I'm with Paul here.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 13:07 ` Markus Armbruster
@ 2010-06-15 13:19 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 13:19 UTC (permalink / raw)
To: Markus Armbruster
Cc: Jan Kiszka, chrisw, kvm, qemu-devel, Alex Williamson, avi, kraxel
> > Every hotplug-capable bus must have a proper addressing scheme, I think
> > this is a reasonable and achievable requirement. Then we don't need
> > instance numbers for those buses.
>
> What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the higher-level protocols (logically USB is a
flat bus structure), but the physically tree topology is still there if you
look hard enough.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 13:19 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 13:19 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kvm, Jan Kiszka, qemu-devel, Alex Williamson, avi, kraxel
> > Every hotplug-capable bus must have a proper addressing scheme, I think
> > this is a reasonable and achievable requirement. Then we don't need
> > instance numbers for those buses.
>
> What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the higher-level protocols (logically USB is a
flat bus structure), but the physically tree topology is still there if you
look hard enough.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 13:19 ` Paul Brook
@ 2010-06-15 13:32 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 13:32 UTC (permalink / raw)
To: Markus Armbruster
Cc: Jan Kiszka, chrisw, kvm, qemu-devel, Alex Williamson, avi, kraxel
> > > Every hotplug-capable bus must have a proper addressing scheme, I think
> > > this is a reasonable and achievable requirement. Then we don't need
> > > instance numbers for those buses.
> >
> > What about USB?
>
> USB has useful device addresses (physical ports).
> These aren't used by most of the higher-level protocols (logically USB is a
> flat bus structure), but the physically tree topology is still there if you
> look hard enough.
... and thinking about it a bit more, this adds an extra addressing
possibility.
USB devices have both physical and logical. The physical addresses is which
port the device is plugged into (including port addresses of any intermediate
hubs). These never change, so should be the canonical address.
The logical address is set by the guest OS so may change (or be absent). Most
software uses the logical address, so this is by far the most useful option
for mapping from a guest device to a qemu device.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 13:32 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 13:32 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kvm, Jan Kiszka, qemu-devel, Alex Williamson, avi, kraxel
> > > Every hotplug-capable bus must have a proper addressing scheme, I think
> > > this is a reasonable and achievable requirement. Then we don't need
> > > instance numbers for those buses.
> >
> > What about USB?
>
> USB has useful device addresses (physical ports).
> These aren't used by most of the higher-level protocols (logically USB is a
> flat bus structure), but the physically tree topology is still there if you
> look hard enough.
... and thinking about it a bit more, this adds an extra addressing
possibility.
USB devices have both physical and logical. The physical addresses is which
port the device is plugged into (including port addresses of any intermediate
hubs). These never change, so should be the canonical address.
The logical address is set by the guest OS so may change (or be absent). Most
software uses the logical address, so this is by far the most useful option
for mapping from a guest device to a qemu device.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 13:16 ` Markus Armbruster
@ 2010-06-15 13:32 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 13:32 UTC (permalink / raw)
To: Markus Armbruster
Cc: Paul Brook, chrisw, kvm, qemu-devel, Alex Williamson, avi, kraxel
Markus Armbruster wrote:
>>>>> That way, we gain a useful feature, and avoid having an savevm-specific
>>>>> "device path" that isn't recognized anywhere else.
>>>> Agreed, we should find one solution for all use cases.
>>> I wasn't aware that there was any suggestion of a separate savevm-specific
>>> path. The whole point of a device path is to uniquely identify a device
>>> within a machine. There may be many different paths that identify the same
>>> device. When given a device and asked to generate path, the result should be
>>> the canonical address. IMO this should be the least volatile, and avoid
>>> redundant information.
>> Given that it is also user-visible, it should also have an intuitive and
>> informative format to avoid confusions. That may imply slightly more
>> information than strictly required for machine-based processing.
>
> I'm with Paul here.
Well, what I'm proposing is derived from my experiences collected while
playing with device_show and device_add/del over the past weeks. For
these monitor scenarios, it was very handy to have expressive path
elements which avoid having to issue 'info qtree' all the time (which is
annoying if you are in the middle of a command input).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 13:32 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 13:32 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kraxel, kvm, qemu-devel, Alex Williamson, avi, Paul Brook
Markus Armbruster wrote:
>>>>> That way, we gain a useful feature, and avoid having an savevm-specific
>>>>> "device path" that isn't recognized anywhere else.
>>>> Agreed, we should find one solution for all use cases.
>>> I wasn't aware that there was any suggestion of a separate savevm-specific
>>> path. The whole point of a device path is to uniquely identify a device
>>> within a machine. There may be many different paths that identify the same
>>> device. When given a device and asked to generate path, the result should be
>>> the canonical address. IMO this should be the least volatile, and avoid
>>> redundant information.
>> Given that it is also user-visible, it should also have an intuitive and
>> informative format to avoid confusions. That may imply slightly more
>> information than strictly required for machine-based processing.
>
> I'm with Paul here.
Well, what I'm proposing is derived from my experiences collected while
playing with device_show and device_add/del over the past weeks. For
these monitor scenarios, it was very handy to have expressive path
elements which avoid having to issue 'info qtree' all the time (which is
annoying if you are in the middle of a command input).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 13:07 ` Markus Armbruster
@ 2010-06-15 15:08 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 15:08 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kvm, Paul Brook, qemu-devel, Alex Williamson, avi, kraxel
Markus Armbruster wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> Markus Armbruster wrote:
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> Markus Armbruster wrote:
>>>>> Paul Brook <paul@codesourcery.com> writes:
>>>>>
>>>>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>>>>
>>>>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>>>>> Could you explain why you add "identified properties of the immediate
>>>>>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>>>>>> path" in the qdev sense...
>>>>>>> In order to try to get a unique string. Without looking into device
>>>>>>> properties, two e1000s would both be:
>>>>>>>
>>>>>>> /main-system-bus/pci.0/e1000
>>>>>>> /main-system-bus/pci.0/e1000
>>>>>>>
>>>>>>> Which is no better than simply "e1000" and would require us to fall back
>>>>>>> to instance ids again. The goal here is that anything that makes use of
>>>>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>>>>> You already got the information you need, you just put it in the wrong place.
>>>>>> The canonical ID for the device could be its bus address. In practice we'd
>>>>>> probably want to allow the user to specify it by name, provided these are
>>>>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>>>>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>>>>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>>>>
>>>>>> For busses that don't have a consistent addressing scheme then some sort of
>>>>>> instance ID is unavoidable. I guess it may be possible to invent something
>>>>>> based on other device properties (e.g. address of the first IO port/memory
>>>>>> region).
>>>>> When that's inconvenient or impossible, we can still punt to user: make
>>>>> device ID mandatory.
>>>> No option due to auto-created devices. And auto-generating IDs would
>>>> just create usability issues.
>>> Auto-generated IDs would become part of the ABI. Really so bad that
>>> it's "no option"? Mind, device ID becomes mandatory *only* for devices
>>> that don't have a useful bus address. We could even waive the ID
>>> requirement for the first device of a kind, i.e. require ID if and only
>>> if it's needed to disambiguate.
>> IDs are there to find devices the user (or a higher level tool) passed
>> to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
>> a well-organized hierarchy. That allows to explore and address a qtree
>> element at the same time.
>>
>>>>> We obviously need a way to unambigously name a device. It's okay to
>>>>> have multiple names for the same device.
>>>>>
>>>>> If the device has a device ID, that's an unambigous name.
>>>>>
>>>>> qdev paths may be ambigous when path components are resolved to driver
>>>>> names instead of IDs.
>>>>>
>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>> immediate parent bus and device" to the path component. For PCI, these
>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>>> bus address. The driver name carries no information!
>>>> >From user POV, driver names are very handly to address a device
>>>> intuitively - except for the case you have tones of devices on the same
>>>> bus that are handled by the same driver. For that case we need to
>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>> address where available, otherwise based on instance numbers.
>>> I'm not arguing against the use of driver names at all.
>>>
>>>>> For other buses, we need to make something up.
>>>>>
>>>>> Note that addressing by bus address rather than name is generally
>>>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>>>> being able to say something like "device_del pci.0/04.0".
>>>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>>>> the bus first before you can identify which device you want to remove.
>>> It's not either/or. Addressing by ID continues to work. Addressing by
>>> bus/driver-name continues to work. We merely add addressing by
>>> bus/@bus-address.
>> The format I will propose is "global-ID|/absolute/path", no more
>> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
>> bus-local name of a device).
>
> Doesn't this break existing usage?
Please name one. It could only be weird corner cases like "device_add
driver,bus=bus1/ID/bus2" or "bus=ID/bus". But given that we always
allowed to address "bus2" directly (and this is something I cannot and
will not change), does this really matter? Maybe allowing paths to start
with an ID is something worth considering, will think about this again.
>
> We have a rule to resolve any ambiguity added by ID: it always takes
> precedence over driver name. What path/ID does add is shadowing: it can
> make a device inaccessible by driver name. Not much of a difference to
> adding a second device with the same driver name.
ID was introduces as a _global_ address, there is simply no point using
it _inside_ qtree paths, it will just cause troubles and confusions.
Rather, we need to resolve the ambiguity of bus-local names - what this
thread is about.
>
>>>>> An easy way to get that is to reserve part of the name space for bus
>>>>> addresses. If the path component starts with a letter, it's an ID or
>>>>> driver name. If it starts with say '@', it's a bus address in
>>>>> bus-specific syntax. The bus provides a method to look it up.
>>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>>> set for buses that implement some to-be-defined device addressing
>>>> service, the latter is the default on buses where that service is not
>>>> available.
>>> I object to <driver>@<bus-address>, because the <driver> part carries no
>>> information.
>> I does for a human being as bus addresses tend to be unreadable and can
>> easily be confused, hence the additional, sometimes redundant driver name.
>
> I *strenuously* object to making the driver name mandatory with
> bus-address addressing.
>
> If you think the human user needs to be protected from mistakes by
> making him supply redundant information, then "device_del pci.0/04.0
> e1000" is much better way than complicating device paths for human and
> machine users alike, not to mention uses internal to QEMU.
The only think that may speak against expressive device names might be
the overall path length. Not sure if we can already reach critical
limits for any involved subsystem, though. Anything else can and should
easily be encapsulated for qdev users in a single service providing the
unique device name for a given device - independent of the final format.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 15:08 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-15 15:08 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kraxel, kvm, qemu-devel, Alex Williamson, avi, Paul Brook
Markus Armbruster wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> Markus Armbruster wrote:
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> Markus Armbruster wrote:
>>>>> Paul Brook <paul@codesourcery.com> writes:
>>>>>
>>>>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>>>>
>>>>>>> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
>>>>>>>> Could you explain why you add "identified properties of the immediate
>>>>>>>> parent bus and device"? They make the result ver much *not* a "dev
>>>>>>>> path" in the qdev sense...
>>>>>>> In order to try to get a unique string. Without looking into device
>>>>>>> properties, two e1000s would both be:
>>>>>>>
>>>>>>> /main-system-bus/pci.0/e1000
>>>>>>> /main-system-bus/pci.0/e1000
>>>>>>>
>>>>>>> Which is no better than simply "e1000" and would require us to fall back
>>>>>>> to instance ids again. The goal here is that anything that makes use of
>>>>>>> passing a dev when registering a vmstate gets an instance id of zero.
>>>>>> You already got the information you need, you just put it in the wrong place.
>>>>>> The canonical ID for the device could be its bus address. In practice we'd
>>>>>> probably want to allow the user to specify it by name, provided these are
>>>>>> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
>>>>>> as an aias for [...]:_09.0. Device names have a restricted namespace, so we
>>>>>> can use an initial prefix to disambiguate a name/label from a bus address.
>>>>>>
>>>>>> For busses that don't have a consistent addressing scheme then some sort of
>>>>>> instance ID is unavoidable. I guess it may be possible to invent something
>>>>>> based on other device properties (e.g. address of the first IO port/memory
>>>>>> region).
>>>>> When that's inconvenient or impossible, we can still punt to user: make
>>>>> device ID mandatory.
>>>> No option due to auto-created devices. And auto-generating IDs would
>>>> just create usability issues.
>>> Auto-generated IDs would become part of the ABI. Really so bad that
>>> it's "no option"? Mind, device ID becomes mandatory *only* for devices
>>> that don't have a useful bus address. We could even waive the ID
>>> requirement for the first device of a kind, i.e. require ID if and only
>>> if it's needed to disambiguate.
>> IDs are there to find devices the user (or a higher level tool) passed
>> to QEMU, qtree paths allow to locate _every_ device in a VM, and that in
>> a well-organized hierarchy. That allows to explore and address a qtree
>> element at the same time.
>>
>>>>> We obviously need a way to unambigously name a device. It's okay to
>>>>> have multiple names for the same device.
>>>>>
>>>>> If the device has a device ID, that's an unambigous name.
>>>>>
>>>>> qdev paths may be ambigous when path components are resolved to driver
>>>>> names instead of IDs.
>>>>>
>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>> immediate parent bus and device" to the path component. For PCI, these
>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>>> bus address. The driver name carries no information!
>>>> >From user POV, driver names are very handly to address a device
>>>> intuitively - except for the case you have tones of devices on the same
>>>> bus that are handled by the same driver. For that case we need to
>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>> address where available, otherwise based on instance numbers.
>>> I'm not arguing against the use of driver names at all.
>>>
>>>>> For other buses, we need to make something up.
>>>>>
>>>>> Note that addressing by bus address rather than name is generally
>>>>> useful, not just in the context of savevm. For instance, I'd appreciate
>>>>> being able to say something like "device_del pci.0/04.0".
>>>> And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>>>> the bus first before you can identify which device you want to remove.
>>> It's not either/or. Addressing by ID continues to work. Addressing by
>>> bus/driver-name continues to work. We merely add addressing by
>>> bus/@bus-address.
>> The format I will propose is "global-ID|/absolute/path", no more
>> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
>> bus-local name of a device).
>
> Doesn't this break existing usage?
Please name one. It could only be weird corner cases like "device_add
driver,bus=bus1/ID/bus2" or "bus=ID/bus". But given that we always
allowed to address "bus2" directly (and this is something I cannot and
will not change), does this really matter? Maybe allowing paths to start
with an ID is something worth considering, will think about this again.
>
> We have a rule to resolve any ambiguity added by ID: it always takes
> precedence over driver name. What path/ID does add is shadowing: it can
> make a device inaccessible by driver name. Not much of a difference to
> adding a second device with the same driver name.
ID was introduces as a _global_ address, there is simply no point using
it _inside_ qtree paths, it will just cause troubles and confusions.
Rather, we need to resolve the ambiguity of bus-local names - what this
thread is about.
>
>>>>> An easy way to get that is to reserve part of the name space for bus
>>>>> addresses. If the path component starts with a letter, it's an ID or
>>>>> driver name. If it starts with say '@', it's a bus address in
>>>>> bus-specific syntax. The bus provides a method to look it up.
>>>> I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>>>> set for buses that implement some to-be-defined device addressing
>>>> service, the latter is the default on buses where that service is not
>>>> available.
>>> I object to <driver>@<bus-address>, because the <driver> part carries no
>>> information.
>> I does for a human being as bus addresses tend to be unreadable and can
>> easily be confused, hence the additional, sometimes redundant driver name.
>
> I *strenuously* object to making the driver name mandatory with
> bus-address addressing.
>
> If you think the human user needs to be protected from mistakes by
> making him supply redundant information, then "device_del pci.0/04.0
> e1000" is much better way than complicating device paths for human and
> machine users alike, not to mention uses internal to QEMU.
The only think that may speak against expressive device names might be
the overall path length. Not sure if we can already reach critical
limits for any involved subsystem, though. Anything else can and should
easily be encapsulated for qdev users in a single service providing the
unique device name for a given device - independent of the final format.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
2010-06-15 8:53 ` Markus Armbruster
@ 2010-06-15 18:01 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 18:01 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Gerd Hoffmann, chrisw, kvm, qemu-devel, paul, avi
On Tue, 2010-06-15 at 10:53 +0200, Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
> > On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >> > 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.
> >>
> >> You'll need that for every bus along the way down to the device. Create
> >> a virtual machine with two lsi scsi host adapters, then attach a disk
> >> with scsi id 0 to each. Just the scsi id isn't good enougth to identify
> >> the device. You'll need the lsi pci address too.
> >
> > Yep, see below.
> >
> >> > For now, the only properties I've tagged as path
> >> > properties are PCI bus addresses and MAC addresses.
> >>
> >> mac address isn't needed here. You need the property which specifies
> >> the bus address. For PCI this obviously is the PCI address. For scsi
> >> the scsi id. For ISA you can use the I/O port base. virtio-serial the
> >> port number, ...
> >
> > PCI: addr
> > SCSI: scsi-id
> > ISA: serial/parallel = iobase, others??
>
> If there's no iobase (pathological case), require ID.
>
> > ide-drive: unit
>
> Bus name is IDE, but it's clear enough what you mean :)
I put ide-drive here because the unit is a property of the device, not
the bus.
> > I2C: address
> >
> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
> > can be skipped.
>
> Really?
>
> Anyway, its port number should do as bus address.
Maybe I'm not specifying it correctly. I see a max_nr_ports property,
but I don't see that each port is a separate qdev.
> > I'm sure I'm still missing some...
>
> s390-virtio
> SSI
> System
I'll need some help coming up with useful properties to key on for
these. I had hoped there's only one System bus.
> USB
usb-storage seems to have a useful drive property that lets me
distinguish these devices:
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb1/scsi.0/scsi-disk.0
^^^^ drive
But otherwise USB is disappointingly devoid of useful properties at the
bus level.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
@ 2010-06-15 18:01 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 18:01 UTC (permalink / raw)
To: Markus Armbruster; +Cc: chrisw, Gerd Hoffmann, kvm, qemu-devel, paul, avi
On Tue, 2010-06-15 at 10:53 +0200, Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
> > On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >> > 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.
> >>
> >> You'll need that for every bus along the way down to the device. Create
> >> a virtual machine with two lsi scsi host adapters, then attach a disk
> >> with scsi id 0 to each. Just the scsi id isn't good enougth to identify
> >> the device. You'll need the lsi pci address too.
> >
> > Yep, see below.
> >
> >> > For now, the only properties I've tagged as path
> >> > properties are PCI bus addresses and MAC addresses.
> >>
> >> mac address isn't needed here. You need the property which specifies
> >> the bus address. For PCI this obviously is the PCI address. For scsi
> >> the scsi id. For ISA you can use the I/O port base. virtio-serial the
> >> port number, ...
> >
> > PCI: addr
> > SCSI: scsi-id
> > ISA: serial/parallel = iobase, others??
>
> If there's no iobase (pathological case), require ID.
>
> > ide-drive: unit
>
> Bus name is IDE, but it's clear enough what you mean :)
I put ide-drive here because the unit is a property of the device, not
the bus.
> > I2C: address
> >
> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
> > can be skipped.
>
> Really?
>
> Anyway, its port number should do as bus address.
Maybe I'm not specifying it correctly. I see a max_nr_ports property,
but I don't see that each port is a separate qdev.
> > I'm sure I'm still missing some...
>
> s390-virtio
> SSI
> System
I'll need some help coming up with useful properties to key on for
these. I had hoped there's only one System bus.
> USB
usb-storage seems to have a useful drive property that lets me
distinguish these devices:
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb1/scsi.0/scsi-disk.0
^^^^ drive
But otherwise USB is disappointingly devoid of useful properties at the
bus level.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
2010-06-15 9:12 ` [Qemu-devel] " Gerd Hoffmann
@ 2010-06-15 18:03 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 18:03 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: qemu-devel, kvm, avi, anthony, paul, chrisw
On Tue, 2010-06-15 at 11:12 +0200, Gerd Hoffmann wrote:
> > ISA: serial/parallel = iobase, others??
>
> ne2k_isa has iobase too.
Added
> I think all remaining isa devices (timer, kbd, vga, ...) have a fixed
> i/o base and can be only once in the system.
Yep, isa doesn't support hotplug either, so there's usually only one of
the devices and they don't move.
> > ide-drive: unit
> > I2C: address
> >
> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
> > can be skipped. I'm sure I'm still missing some...
>
> Hmm? -device virtio-serial -device virtconsole,chardev=foo,port=23
Ok, there's a nr property on virtconsole, I'll add that. But I still
don't see ports enumerated as qdev entries for generic virtio-serial.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
@ 2010-06-15 18:03 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 18:03 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: chrisw, kvm, qemu-devel, paul, avi
On Tue, 2010-06-15 at 11:12 +0200, Gerd Hoffmann wrote:
> > ISA: serial/parallel = iobase, others??
>
> ne2k_isa has iobase too.
Added
> I think all remaining isa devices (timer, kbd, vga, ...) have a fixed
> i/o base and can be only once in the system.
Yep, isa doesn't support hotplug either, so there's usually only one of
the devices and they don't move.
> > ide-drive: unit
> > I2C: address
> >
> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
> > can be skipped. I'm sure I'm still missing some...
>
> Hmm? -device virtio-serial -device virtconsole,chardev=foo,port=23
Ok, there's a nr property on virtconsole, I'll add that. But I still
don't see ports enumerated as qdev entries for generic virtio-serial.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 11:28 ` Paul Brook
@ 2010-06-15 20:53 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 20:53 UTC (permalink / raw)
To: Paul Brook
Cc: Jan Kiszka, Markus Armbruster, chrisw, kvm, qemu-devel, avi, kraxel
On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > Alex proposed to disambiguate by adding "identified properties of the
> > > immediate parent bus and device" to the path component. For PCI, these
> > > are dev.fn. Likewise for any other bus where devices have unambigous
> > > bus address. The driver name carries no information!
> >
> > From user POV, driver names are very handly to address a device
> > intuitively - except for the case you have tones of devices on the same
> > bus that are handled by the same driver. For that case we need to
> > augment the device name with a useful per-bus ID, derived from the bus
> > address where available, otherwise based on instance numbers.
>
> This is where I think you're missing a trick. We don't need to augment the
> name, we just need to allow the bus id to be used instead.
For the case of a hot remove, I agree. If the user specifies "pci_del
pci.0/03.0", that's completely sufficient because we don't care what's
in that slot, just remove it. However, I still see some use cases for
device names in the path. Take for example:
(A): /i440FX-pcihost/pci.0/e1000.05.0
vs
(B): /pci.0/05.0
(removing both the root bridge driver name and the device driver name)
If we attach a pci option rom to the device, create some ram to store
the option rom and name the ram block $(PATH)/rom, with (A) we know more
about the hierarchy to get to the actual devfn device, and we know the
type of device that's in the slot. With (B), there's no robustness. If
we migrated using (B), we could be stuffing a pc e1000 option rom into a
ppc lsi895, just because it happened to live that the same place and
have a ram block named rom. Including driver names increases the
uniqueness of the path.
Another example; if we have two drivers that create a vmstate with name
"foo", plug one driver into slot 03.0 on the migration source, the other
into slot 03.0 on the migration destination, what happens? It seems
likely that the destination will try to load the vmstate from a
different driver and fail in wonderful and bizarre ways. If we use (A),
each path automatically has it's own namespace.
ISA is also a good example even though it doesn't do hotplug. Given
this set:
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/ne2k_isa.0x300
versus this set:
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0/0x3f8
/pci.0.01.0/isa.0/0x378
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0/0x300
Which one has devices that are easier to uniquely identify?
> > > For other buses, we need to make something up.
> > >
> > > Note that addressing by bus address rather than name is generally
> > > useful, not just in the context of savevm. For instance, I'd appreciate
> > > being able to say something like "device_del pci.0/04.0".
> >
> > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> > the bus first before you can identify which device you want to remove.
>
> We can allow both.
>
> A bus address is sufficient to uniquely identify a device.
A bus address (assuming it exists) is sufficient to uniquely identify a
device, on a given VM. A bus address only identifies a location when
comparing two separate VMs.
> I see no reason to
> require the driver name, or to include it in the canonical device address.
Migration. Including the driver name extends our ability to uniquely
identify a device across separate VMs. It's then up to the vmstate code
to figure out whether the device are compatible for migrate state.
> > > An easy way to get that is to reserve part of the name space for bus
> > > addresses. If the path component starts with a letter, it's an ID or
> > > driver name. If it starts with say '@', it's a bus address in
> > > bus-specific syntax. The bus provides a method to look it up.
> >
> > I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
> > set for buses that implement some to-be-defined device addressing
> > service, the latter is the default on buses where that service is not
> > available.
>
> If we have bus-address then I see no good reason to also add instance-no.
> For busses that no natural address, we can define the address to be an
> instance number.
I agree, it should be a bug for any device with a bus address to have an
instance number other than zero. Anything without a bus number can make
use of instance numbers, and hopefully will never be hotplugged.
> > > That way, we gain a useful feature, and avoid having an savevm-specific
> > > "device path" that isn't recognized anywhere else.
> >
> > Agreed, we should find one solution for all use cases.
>
> I wasn't aware that there was any suggestion of a separate savevm-specific
> path. The whole point of a device path is to uniquely identify a device
> within a machine. There may be many different paths that identify the same
> device. When given a device and asked to generate path, the result should be
> the canonical address. IMO this should be the least volatile, and avoid
> redundant information.
Yep, I'm certainly aiming to not make this specific to savevm, but maybe
the difference is that savevm does care about migration. If we take
migration out of the picture, then I would tend to agree that we can
remove driver names. A bus address uniquely identifies a given device
on a given VM. But if we add migration back in, I think we can increase
the robustness of the device path without reducing the stability by
including the driver names. Most of my examples above are pathological
cases that aren't going to happen. I think the driver name does provide
useful information across VMs, but I'll go with the consensus whether to
include it. BTW, find below output for a VM using the full driver name
path versus no driver names.
Alex
(A)
/i440FX-pcihost
/i440FX-pcihost/pci.0/i440FX.00.0
/i440FX-pcihost/pci.0/PIIX3.01.0
/i440FX-pcihost/pci.0/cirrus-vga.02.0
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/i82551.03.0
/i440FX-pcihost/pci.0/virtio-net-pci.04.0
/i440FX-pcihost/pci.0/e1000.05.0
/i440FX-pcihost/pci.0/rtl8139.06.0
/i440FX-pcihost/pci.0/pcnet.07.0
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/ne2k_isa.0x300
/i440FX-pcihost/pci.0/piix3-ide.01.1
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.0/ide-drive.0
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.1/ide-drive.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2
/i440FX-pcihost/pci.0/PIIX4_PM.01.3
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.80
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.81
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.82
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.83
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.84
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.85
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.86
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.87
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.3
/i440FX-pcihost/pci.0/lsi53c895a.08.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0
/i440FX-pcihost/pci.0/virtio-blk-pci.09.0
(B)
/pci.0.00.0
/pci.0.01.0
/pci.0.02.0
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0/0x3f8
/pci.0.01.0/isa.0/0x378
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0
/pci.0.03.0
/pci.0.04.0
/pci.0.05.0
/pci.0.06.0
/pci.0.07.0
/pci.0.01.0/isa.0/0x300
/pci.0.01.1
/pci.0.01.1/ide.0.0
/pci.0.01.1/ide.1.0
/pci.0.01.2
/pci.0.01.3
/pci.0.01.3/i2c/80
/pci.0.01.3/i2c/81
/pci.0.01.3/i2c/82
/pci.0.01.3/i2c/83
/pci.0.01.3/i2c/84
/pci.0.01.3/i2c/85
/pci.0.01.3/i2c/86
/pci.0.01.3/i2c/87
/pci.0.08.0/scsi.0/0
/pci.0.08.0/scsi.0/3
/pci.0.08.0
/pci.0.01.2/usb.0/usb0/scsi.0/0
/pci.0.01.2/usb.0/usb0
/pci.0.09.0
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 20:53 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 20:53 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, avi, kraxel
On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > Alex proposed to disambiguate by adding "identified properties of the
> > > immediate parent bus and device" to the path component. For PCI, these
> > > are dev.fn. Likewise for any other bus where devices have unambigous
> > > bus address. The driver name carries no information!
> >
> > From user POV, driver names are very handly to address a device
> > intuitively - except for the case you have tones of devices on the same
> > bus that are handled by the same driver. For that case we need to
> > augment the device name with a useful per-bus ID, derived from the bus
> > address where available, otherwise based on instance numbers.
>
> This is where I think you're missing a trick. We don't need to augment the
> name, we just need to allow the bus id to be used instead.
For the case of a hot remove, I agree. If the user specifies "pci_del
pci.0/03.0", that's completely sufficient because we don't care what's
in that slot, just remove it. However, I still see some use cases for
device names in the path. Take for example:
(A): /i440FX-pcihost/pci.0/e1000.05.0
vs
(B): /pci.0/05.0
(removing both the root bridge driver name and the device driver name)
If we attach a pci option rom to the device, create some ram to store
the option rom and name the ram block $(PATH)/rom, with (A) we know more
about the hierarchy to get to the actual devfn device, and we know the
type of device that's in the slot. With (B), there's no robustness. If
we migrated using (B), we could be stuffing a pc e1000 option rom into a
ppc lsi895, just because it happened to live that the same place and
have a ram block named rom. Including driver names increases the
uniqueness of the path.
Another example; if we have two drivers that create a vmstate with name
"foo", plug one driver into slot 03.0 on the migration source, the other
into slot 03.0 on the migration destination, what happens? It seems
likely that the destination will try to load the vmstate from a
different driver and fail in wonderful and bizarre ways. If we use (A),
each path automatically has it's own namespace.
ISA is also a good example even though it doesn't do hotplug. Given
this set:
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/ne2k_isa.0x300
versus this set:
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0/0x3f8
/pci.0.01.0/isa.0/0x378
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0/0x300
Which one has devices that are easier to uniquely identify?
> > > For other buses, we need to make something up.
> > >
> > > Note that addressing by bus address rather than name is generally
> > > useful, not just in the context of savevm. For instance, I'd appreciate
> > > being able to say something like "device_del pci.0/04.0".
> >
> > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> > the bus first before you can identify which device you want to remove.
>
> We can allow both.
>
> A bus address is sufficient to uniquely identify a device.
A bus address (assuming it exists) is sufficient to uniquely identify a
device, on a given VM. A bus address only identifies a location when
comparing two separate VMs.
> I see no reason to
> require the driver name, or to include it in the canonical device address.
Migration. Including the driver name extends our ability to uniquely
identify a device across separate VMs. It's then up to the vmstate code
to figure out whether the device are compatible for migrate state.
> > > An easy way to get that is to reserve part of the name space for bus
> > > addresses. If the path component starts with a letter, it's an ID or
> > > driver name. If it starts with say '@', it's a bus address in
> > > bus-specific syntax. The bus provides a method to look it up.
> >
> > I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
> > set for buses that implement some to-be-defined device addressing
> > service, the latter is the default on buses where that service is not
> > available.
>
> If we have bus-address then I see no good reason to also add instance-no.
> For busses that no natural address, we can define the address to be an
> instance number.
I agree, it should be a bug for any device with a bus address to have an
instance number other than zero. Anything without a bus number can make
use of instance numbers, and hopefully will never be hotplugged.
> > > That way, we gain a useful feature, and avoid having an savevm-specific
> > > "device path" that isn't recognized anywhere else.
> >
> > Agreed, we should find one solution for all use cases.
>
> I wasn't aware that there was any suggestion of a separate savevm-specific
> path. The whole point of a device path is to uniquely identify a device
> within a machine. There may be many different paths that identify the same
> device. When given a device and asked to generate path, the result should be
> the canonical address. IMO this should be the least volatile, and avoid
> redundant information.
Yep, I'm certainly aiming to not make this specific to savevm, but maybe
the difference is that savevm does care about migration. If we take
migration out of the picture, then I would tend to agree that we can
remove driver names. A bus address uniquely identifies a given device
on a given VM. But if we add migration back in, I think we can increase
the robustness of the device path without reducing the stability by
including the driver names. Most of my examples above are pathological
cases that aren't going to happen. I think the driver name does provide
useful information across VMs, but I'll go with the consensus whether to
include it. BTW, find below output for a VM using the full driver name
path versus no driver names.
Alex
(A)
/i440FX-pcihost
/i440FX-pcihost/pci.0/i440FX.00.0
/i440FX-pcihost/pci.0/PIIX3.01.0
/i440FX-pcihost/pci.0/cirrus-vga.02.0
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/i82551.03.0
/i440FX-pcihost/pci.0/virtio-net-pci.04.0
/i440FX-pcihost/pci.0/e1000.05.0
/i440FX-pcihost/pci.0/rtl8139.06.0
/i440FX-pcihost/pci.0/pcnet.07.0
/i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/ne2k_isa.0x300
/i440FX-pcihost/pci.0/piix3-ide.01.1
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.0/ide-drive.0
/i440FX-pcihost/pci.0/piix3-ide.01.1/ide.1/ide-drive.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2
/i440FX-pcihost/pci.0/PIIX4_PM.01.3
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.80
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.81
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.82
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.83
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.84
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.85
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.86
/i440FX-pcihost/pci.0/PIIX4_PM.01.3/i2c/smbus-eeprom.87
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/lsi53c895a.08.0/scsi.0/scsi-disk.3
/i440FX-pcihost/pci.0/lsi53c895a.08.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0/scsi.0/scsi-disk.0
/i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0
/i440FX-pcihost/pci.0/virtio-blk-pci.09.0
(B)
/pci.0.00.0
/pci.0.01.0
/pci.0.02.0
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0/0x3f8
/pci.0.01.0/isa.0/0x378
/pci.0.01.0/isa.0
/pci.0.01.0/isa.0
/pci.0.03.0
/pci.0.04.0
/pci.0.05.0
/pci.0.06.0
/pci.0.07.0
/pci.0.01.0/isa.0/0x300
/pci.0.01.1
/pci.0.01.1/ide.0.0
/pci.0.01.1/ide.1.0
/pci.0.01.2
/pci.0.01.3
/pci.0.01.3/i2c/80
/pci.0.01.3/i2c/81
/pci.0.01.3/i2c/82
/pci.0.01.3/i2c/83
/pci.0.01.3/i2c/84
/pci.0.01.3/i2c/85
/pci.0.01.3/i2c/86
/pci.0.01.3/i2c/87
/pci.0.08.0/scsi.0/0
/pci.0.08.0/scsi.0/3
/pci.0.08.0
/pci.0.01.2/usb.0/usb0/scsi.0/0
/pci.0.01.2/usb.0/usb0
/pci.0.09.0
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 20:53 ` Alex Williamson
@ 2010-06-15 21:55 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 21:55 UTC (permalink / raw)
To: Alex Williamson
Cc: Jan Kiszka, Markus Armbruster, chrisw, kvm, qemu-devel, avi, kraxel
> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > > Alex proposed to disambiguate by adding "identified properties of the
> > > > immediate parent bus and device" to the path component. For PCI,
> > > > these are dev.fn. Likewise for any other bus where devices have
> > > > unambigous bus address. The driver name carries no information!
> > >
> > > From user POV, driver names are very handly to address a device
> > > intuitively - except for the case you have tones of devices on the same
> > > bus that are handled by the same driver. For that case we need to
> > > augment the device name with a useful per-bus ID, derived from the bus
> > > address where available, otherwise based on instance numbers.
> >
> > This is where I think you're missing a trick. We don't need to augment
> > the name, we just need to allow the bus id to be used instead.
>
> For the case of a hot remove, I agree. If the user specifies "pci_del
> pci.0/03.0", that's completely sufficient because we don't care what's
> in that slot, just remove it. However, I still see some use cases for
> device names in the path. Take for example:
>
> (A): /i440FX-pcihost/pci.0/e1000.05.0
>
> vs
>
> (B): /pci.0/05.0
> (removing both the root bridge driver name and the device driver name)
This is wrong. You still need an entry for the host pci bridge.
> If we attach a pci option rom to the device, create some ram to store
> the option rom and name the ram block $(PATH)/rom, with (A) we know more
> about the hierarchy to get to the actual devfn device, and we know the
> type of device that's in the slot. With (B), there's no robustness. If
> we migrated using (B), we could be stuffing a pc e1000 option rom into a
> ppc lsi895, just because it happened to live that the same place and
> have a ram block named rom. Including driver names increases the
> uniqueness of the path.
No it doesn't. It adds redundant information and a false sense of security.
Driver name is not sufficient to determine whether you've actually got a
compatible device. The type of the device doesn't reliably tell you anything
about how many ram blocks that device has, or how big they are.
> > > > For other buses, we need to make something up.
> > > >
> > > > Note that addressing by bus address rather than name is generally
> > > > useful, not just in the context of savevm. For instance, I'd
> > > > appreciate being able to say something like "device_del pci.0/04.0".
> > >
> > > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> > > the bus first before you can identify which device you want to remove.
> >
> > We can allow both.
> > A bus address is sufficient to uniquely identify a device.
>
> A bus address (assuming it exists) is sufficient to uniquely identify a
> device, on a given VM. A bus address only identifies a location when
> comparing two separate VMs.
I can't make any sense of this statement.
> > I see no reason to
> > require the driver name, or to include it in the canonical device
> > address.
>
> Migration. Including the driver name extends our ability to uniquely
> identify a device across separate VMs. It's then up to the vmstate code
> to figure out whether the device are compatible for migrate state.
I find this argument contradictory. The migration code already needs to check
whether a device is compatible before it allows migration. The driver name is
not sufficient to ensure compatibility, so I see no benefit in including it in
the device address. If we include the device name, why aren't we also
including all other properties that would make the devices incompatible?
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 21:55 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 21:55 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, avi, kraxel
> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > > Alex proposed to disambiguate by adding "identified properties of the
> > > > immediate parent bus and device" to the path component. For PCI,
> > > > these are dev.fn. Likewise for any other bus where devices have
> > > > unambigous bus address. The driver name carries no information!
> > >
> > > From user POV, driver names are very handly to address a device
> > > intuitively - except for the case you have tones of devices on the same
> > > bus that are handled by the same driver. For that case we need to
> > > augment the device name with a useful per-bus ID, derived from the bus
> > > address where available, otherwise based on instance numbers.
> >
> > This is where I think you're missing a trick. We don't need to augment
> > the name, we just need to allow the bus id to be used instead.
>
> For the case of a hot remove, I agree. If the user specifies "pci_del
> pci.0/03.0", that's completely sufficient because we don't care what's
> in that slot, just remove it. However, I still see some use cases for
> device names in the path. Take for example:
>
> (A): /i440FX-pcihost/pci.0/e1000.05.0
>
> vs
>
> (B): /pci.0/05.0
> (removing both the root bridge driver name and the device driver name)
This is wrong. You still need an entry for the host pci bridge.
> If we attach a pci option rom to the device, create some ram to store
> the option rom and name the ram block $(PATH)/rom, with (A) we know more
> about the hierarchy to get to the actual devfn device, and we know the
> type of device that's in the slot. With (B), there's no robustness. If
> we migrated using (B), we could be stuffing a pc e1000 option rom into a
> ppc lsi895, just because it happened to live that the same place and
> have a ram block named rom. Including driver names increases the
> uniqueness of the path.
No it doesn't. It adds redundant information and a false sense of security.
Driver name is not sufficient to determine whether you've actually got a
compatible device. The type of the device doesn't reliably tell you anything
about how many ram blocks that device has, or how big they are.
> > > > For other buses, we need to make something up.
> > > >
> > > > Note that addressing by bus address rather than name is generally
> > > > useful, not just in the context of savevm. For instance, I'd
> > > > appreciate being able to say something like "device_del pci.0/04.0".
> > >
> > > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> > > the bus first before you can identify which device you want to remove.
> >
> > We can allow both.
> > A bus address is sufficient to uniquely identify a device.
>
> A bus address (assuming it exists) is sufficient to uniquely identify a
> device, on a given VM. A bus address only identifies a location when
> comparing two separate VMs.
I can't make any sense of this statement.
> > I see no reason to
> > require the driver name, or to include it in the canonical device
> > address.
>
> Migration. Including the driver name extends our ability to uniquely
> identify a device across separate VMs. It's then up to the vmstate code
> to figure out whether the device are compatible for migrate state.
I find this argument contradictory. The migration code already needs to check
whether a device is compatible before it allows migration. The driver name is
not sufficient to ensure compatibility, so I see no benefit in including it in
the device address. If we include the device name, why aren't we also
including all other properties that would make the devices incompatible?
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 21:55 ` Paul Brook
@ 2010-06-15 22:33 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 22:33 UTC (permalink / raw)
To: Paul Brook
Cc: Jan Kiszka, Markus Armbruster, chrisw, kvm, qemu-devel, avi, kraxel
On Tue, 2010-06-15 at 22:55 +0100, Paul Brook wrote:
> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > > > Alex proposed to disambiguate by adding "identified properties of the
> > > > > immediate parent bus and device" to the path component. For PCI,
> > > > > these are dev.fn. Likewise for any other bus where devices have
> > > > > unambigous bus address. The driver name carries no information!
> > > >
> > > > From user POV, driver names are very handly to address a device
> > > > intuitively - except for the case you have tones of devices on the same
> > > > bus that are handled by the same driver. For that case we need to
> > > > augment the device name with a useful per-bus ID, derived from the bus
> > > > address where available, otherwise based on instance numbers.
> > >
> > > This is where I think you're missing a trick. We don't need to augment
> > > the name, we just need to allow the bus id to be used instead.
> >
> > For the case of a hot remove, I agree. If the user specifies "pci_del
> > pci.0/03.0", that's completely sufficient because we don't care what's
> > in that slot, just remove it. However, I still see some use cases for
> > device names in the path. Take for example:
> >
> > (A): /i440FX-pcihost/pci.0/e1000.05.0
> >
> > vs
> >
> > (B): /pci.0/05.0
>
> > (removing both the root bridge driver name and the device driver name)
>
> This is wrong. You still need an entry for the host pci bridge.
The host pci bridge has no identifying properties, so all we'd be
printing is the pci bridge driver name, which we claim adds no value.
Or are we saying that some driver names are useful while others aren't?
> > If we attach a pci option rom to the device, create some ram to store
> > the option rom and name the ram block $(PATH)/rom, with (A) we know more
> > about the hierarchy to get to the actual devfn device, and we know the
> > type of device that's in the slot. With (B), there's no robustness. If
> > we migrated using (B), we could be stuffing a pc e1000 option rom into a
> > ppc lsi895, just because it happened to live that the same place and
> > have a ram block named rom. Including driver names increases the
> > uniqueness of the path.
>
> No it doesn't. It adds redundant information and a false sense of security.
> Driver name is not sufficient to determine whether you've actually got a
> compatible device. The type of the device doesn't reliably tell you anything
> about how many ram blocks that device has, or how big they are.
Driver name is sufficient to tell me that driver "foo" created this
device on both the source and destination and hand off responsibility to
driver "foo" to make the determination about whether it's compatible. I
think it's reasonably safe to say we're not going to have two completely
different drivers with name "foo"s within an instance of qemu and we're
not going to turn over the name to a different driver and expect
anything sane to happen wrt to migration. I disagree that this is a
false sense of security, it gives me warm fuzzies. Please convince me
otherwise.
> > > > > For other buses, we need to make something up.
> > > > >
> > > > > Note that addressing by bus address rather than name is generally
> > > > > useful, not just in the context of savevm. For instance, I'd
> > > > > appreciate being able to say something like "device_del pci.0/04.0".
> > > >
> > > > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> > > > the bus first before you can identify which device you want to remove.
> > >
> > > We can allow both.
> > > A bus address is sufficient to uniquely identify a device.
> >
> > A bus address (assuming it exists) is sufficient to uniquely identify a
> > device, on a given VM. A bus address only identifies a location when
> > comparing two separate VMs.
>
> I can't make any sense of this statement.
Makes sense to me ;) A bus address is unique only within the context of
the VM. Within that VM I can figure out that the device at that bus
address uses driver foo, so foo seems redundant in the device path. Now
I try to apply that bus address to another VM, the migration target, and
all I have is a location. I have to make a leap of faith that the
device at that location is the same as the device at the same location
on the migration source. Where are those warm fuzzies?
> > > I see no reason to
> > > require the driver name, or to include it in the canonical device
> > > address.
> >
> > Migration. Including the driver name extends our ability to uniquely
> > identify a device across separate VMs. It's then up to the vmstate code
> > to figure out whether the device are compatible for migrate state.
>
> I find this argument contradictory. The migration code already needs to check
> whether a device is compatible before it allows migration. The driver name is
> not sufficient to ensure compatibility, so I see no benefit in including it in
> the device address.
See my comment above, I'm not seeing a sufficient argument about why
driver name matching is a false sense of security. If on an incoming
migration I'm able to match the source provided e1000.03.0/vmstate
against the target registered e1000.03.0/vmstate and hand off to the
e1000 driver to check version ids, you bet I'm feeling a lot more secure
than if I'm handing off to whatever happened to register 03.0/vmstate on
the target.
> If we include the device name, why aren't we also
> including all other properties that would make the devices incompatible?
Well, in some ways that'd be really nice, then we could rebuild the
device on the fly in the target. But, I'm attempting to work within the
existing migration code, because I'd really like something working
better than it does today very soon. Therefore, we do want to reduce
the path to only those elements that are stable and add value. I argue
the driver name is both stable and adds value. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 22:33 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 22:33 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, avi, kraxel
On Tue, 2010-06-15 at 22:55 +0100, Paul Brook wrote:
> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> > > > > Alex proposed to disambiguate by adding "identified properties of the
> > > > > immediate parent bus and device" to the path component. For PCI,
> > > > > these are dev.fn. Likewise for any other bus where devices have
> > > > > unambigous bus address. The driver name carries no information!
> > > >
> > > > From user POV, driver names are very handly to address a device
> > > > intuitively - except for the case you have tones of devices on the same
> > > > bus that are handled by the same driver. For that case we need to
> > > > augment the device name with a useful per-bus ID, derived from the bus
> > > > address where available, otherwise based on instance numbers.
> > >
> > > This is where I think you're missing a trick. We don't need to augment
> > > the name, we just need to allow the bus id to be used instead.
> >
> > For the case of a hot remove, I agree. If the user specifies "pci_del
> > pci.0/03.0", that's completely sufficient because we don't care what's
> > in that slot, just remove it. However, I still see some use cases for
> > device names in the path. Take for example:
> >
> > (A): /i440FX-pcihost/pci.0/e1000.05.0
> >
> > vs
> >
> > (B): /pci.0/05.0
>
> > (removing both the root bridge driver name and the device driver name)
>
> This is wrong. You still need an entry for the host pci bridge.
The host pci bridge has no identifying properties, so all we'd be
printing is the pci bridge driver name, which we claim adds no value.
Or are we saying that some driver names are useful while others aren't?
> > If we attach a pci option rom to the device, create some ram to store
> > the option rom and name the ram block $(PATH)/rom, with (A) we know more
> > about the hierarchy to get to the actual devfn device, and we know the
> > type of device that's in the slot. With (B), there's no robustness. If
> > we migrated using (B), we could be stuffing a pc e1000 option rom into a
> > ppc lsi895, just because it happened to live that the same place and
> > have a ram block named rom. Including driver names increases the
> > uniqueness of the path.
>
> No it doesn't. It adds redundant information and a false sense of security.
> Driver name is not sufficient to determine whether you've actually got a
> compatible device. The type of the device doesn't reliably tell you anything
> about how many ram blocks that device has, or how big they are.
Driver name is sufficient to tell me that driver "foo" created this
device on both the source and destination and hand off responsibility to
driver "foo" to make the determination about whether it's compatible. I
think it's reasonably safe to say we're not going to have two completely
different drivers with name "foo"s within an instance of qemu and we're
not going to turn over the name to a different driver and expect
anything sane to happen wrt to migration. I disagree that this is a
false sense of security, it gives me warm fuzzies. Please convince me
otherwise.
> > > > > For other buses, we need to make something up.
> > > > >
> > > > > Note that addressing by bus address rather than name is generally
> > > > > useful, not just in the context of savevm. For instance, I'd
> > > > > appreciate being able to say something like "device_del pci.0/04.0".
> > > >
> > > > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
> > > > the bus first before you can identify which device you want to remove.
> > >
> > > We can allow both.
> > > A bus address is sufficient to uniquely identify a device.
> >
> > A bus address (assuming it exists) is sufficient to uniquely identify a
> > device, on a given VM. A bus address only identifies a location when
> > comparing two separate VMs.
>
> I can't make any sense of this statement.
Makes sense to me ;) A bus address is unique only within the context of
the VM. Within that VM I can figure out that the device at that bus
address uses driver foo, so foo seems redundant in the device path. Now
I try to apply that bus address to another VM, the migration target, and
all I have is a location. I have to make a leap of faith that the
device at that location is the same as the device at the same location
on the migration source. Where are those warm fuzzies?
> > > I see no reason to
> > > require the driver name, or to include it in the canonical device
> > > address.
> >
> > Migration. Including the driver name extends our ability to uniquely
> > identify a device across separate VMs. It's then up to the vmstate code
> > to figure out whether the device are compatible for migrate state.
>
> I find this argument contradictory. The migration code already needs to check
> whether a device is compatible before it allows migration. The driver name is
> not sufficient to ensure compatibility, so I see no benefit in including it in
> the device address.
See my comment above, I'm not seeing a sufficient argument about why
driver name matching is a false sense of security. If on an incoming
migration I'm able to match the source provided e1000.03.0/vmstate
against the target registered e1000.03.0/vmstate and hand off to the
e1000 driver to check version ids, you bet I'm feeling a lot more secure
than if I'm handing off to whatever happened to register 03.0/vmstate on
the target.
> If we include the device name, why aren't we also
> including all other properties that would make the devices incompatible?
Well, in some ways that'd be really nice, then we could rebuild the
device on the fly in the target. But, I'm attempting to work within the
existing migration code, because I'd really like something working
better than it does today very soon. Therefore, we do want to reduce
the path to only those elements that are stable and add value. I argue
the driver name is both stable and adds value. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 22:33 ` Alex Williamson
@ 2010-06-15 23:01 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 23:01 UTC (permalink / raw)
To: Alex Williamson
Cc: Jan Kiszka, Markus Armbruster, chrisw, kvm, qemu-devel, avi, kraxel
> > I find this argument contradictory. The migration code already needs to
> > check whether a device is compatible before it allows migration. The
> > driver name is not sufficient to ensure compatibility, so I see no
> > benefit in including it in the device address.
>
> See my comment above, I'm not seeing a sufficient argument about why
> driver name matching is a false sense of security. If on an incoming
> migration I'm able to match the source provided e1000.03.0/vmstate
> against the target registered e1000.03.0/vmstate and hand off to the
> e1000 driver to check version ids, you bet I'm feeling a lot more secure
> than if I'm handing off to whatever happened to register 03.0/vmstate on
> the target.
I still say it should be the migration code that checks that both vmstate
structures are for the same type of device. i.e. if necessary the device name
should be embedded in the device state, not the device path.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 23:01 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-15 23:01 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, avi, kraxel
> > I find this argument contradictory. The migration code already needs to
> > check whether a device is compatible before it allows migration. The
> > driver name is not sufficient to ensure compatibility, so I see no
> > benefit in including it in the device address.
>
> See my comment above, I'm not seeing a sufficient argument about why
> driver name matching is a false sense of security. If on an incoming
> migration I'm able to match the source provided e1000.03.0/vmstate
> against the target registered e1000.03.0/vmstate and hand off to the
> e1000 driver to check version ids, you bet I'm feeling a lot more secure
> than if I'm handing off to whatever happened to register 03.0/vmstate on
> the target.
I still say it should be the migration code that checks that both vmstate
structures are for the same type of device. i.e. if necessary the device name
should be embedded in the device state, not the device path.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 23:01 ` Paul Brook
@ 2010-06-15 23:10 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 23:10 UTC (permalink / raw)
To: Paul Brook
Cc: Jan Kiszka, Markus Armbruster, chrisw, kvm, qemu-devel, avi, kraxel
On Wed, 2010-06-16 at 00:01 +0100, Paul Brook wrote:
> > > I find this argument contradictory. The migration code already needs to
> > > check whether a device is compatible before it allows migration. The
> > > driver name is not sufficient to ensure compatibility, so I see no
> > > benefit in including it in the device address.
> >
> > See my comment above, I'm not seeing a sufficient argument about why
> > driver name matching is a false sense of security. If on an incoming
> > migration I'm able to match the source provided e1000.03.0/vmstate
> > against the target registered e1000.03.0/vmstate and hand off to the
> > e1000 driver to check version ids, you bet I'm feeling a lot more secure
> > than if I'm handing off to whatever happened to register 03.0/vmstate on
> > the target.
>
> I still say it should be the migration code that checks that both vmstate
> structures are for the same type of device. i.e. if necessary the device name
> should be embedded in the device state, not the device path.
The migration code would check that ("%s/%s", path, name) match. So
embedding the driver name into path gives us a per path namespace. Sure
the migration code could check ("%s/%s/%s, path, dev->info->name, name),
but should it be the migration code's responsibility to dig that out?
And if you think that i440FX-pcihost is a useful driver name, then we'd
have to figure out which driver names are useful. I think it's more
consistent to simply put them all there. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-15 23:10 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-15 23:10 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel, avi, kraxel
On Wed, 2010-06-16 at 00:01 +0100, Paul Brook wrote:
> > > I find this argument contradictory. The migration code already needs to
> > > check whether a device is compatible before it allows migration. The
> > > driver name is not sufficient to ensure compatibility, so I see no
> > > benefit in including it in the device address.
> >
> > See my comment above, I'm not seeing a sufficient argument about why
> > driver name matching is a false sense of security. If on an incoming
> > migration I'm able to match the source provided e1000.03.0/vmstate
> > against the target registered e1000.03.0/vmstate and hand off to the
> > e1000 driver to check version ids, you bet I'm feeling a lot more secure
> > than if I'm handing off to whatever happened to register 03.0/vmstate on
> > the target.
>
> I still say it should be the migration code that checks that both vmstate
> structures are for the same type of device. i.e. if necessary the device name
> should be embedded in the device state, not the device path.
The migration code would check that ("%s/%s", path, name) match. So
embedding the driver name into path gives us a per path namespace. Sure
the migration code could check ("%s/%s/%s, path, dev->info->name, name),
but should it be the migration code's responsibility to dig that out?
And if you think that i440FX-pcihost is a useful driver name, then we'd
have to figure out which driver names are useful. I think it's more
consistent to simply put them all there. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 23:01 ` Paul Brook
@ 2010-06-16 0:25 ` Chris Wright
-1 siblings, 0 replies; 160+ messages in thread
From: Chris Wright @ 2010-06-16 0:25 UTC (permalink / raw)
To: Paul Brook
Cc: Alex Williamson, Jan Kiszka, Markus Armbruster, chrisw, kvm,
qemu-devel, avi, kraxel
* Paul Brook (paul@codesourcery.com) wrote:
> > > I find this argument contradictory. The migration code already needs to
> > > check whether a device is compatible before it allows migration. The
> > > driver name is not sufficient to ensure compatibility, so I see no
> > > benefit in including it in the device address.
> >
> > See my comment above, I'm not seeing a sufficient argument about why
> > driver name matching is a false sense of security. If on an incoming
> > migration I'm able to match the source provided e1000.03.0/vmstate
> > against the target registered e1000.03.0/vmstate and hand off to the
> > e1000 driver to check version ids, you bet I'm feeling a lot more secure
> > than if I'm handing off to whatever happened to register 03.0/vmstate on
> > the target.
>
> I still say it should be the migration code that checks that both vmstate
> structures are for the same type of device. i.e. if necessary the device name
> should be embedded in the device state, not the device path.
I not sure how that fixes the ramblock issue that started this whole
discussion. It's not part of device's vmstate, it goes w/ ram. I think
I'm missing a piece of the puzzle here?
thanks,
-chris
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-16 0:25 ` Chris Wright
0 siblings, 0 replies; 160+ messages in thread
From: Chris Wright @ 2010-06-16 0:25 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, qemu-devel,
Alex Williamson, avi, kraxel
* Paul Brook (paul@codesourcery.com) wrote:
> > > I find this argument contradictory. The migration code already needs to
> > > check whether a device is compatible before it allows migration. The
> > > driver name is not sufficient to ensure compatibility, so I see no
> > > benefit in including it in the device address.
> >
> > See my comment above, I'm not seeing a sufficient argument about why
> > driver name matching is a false sense of security. If on an incoming
> > migration I'm able to match the source provided e1000.03.0/vmstate
> > against the target registered e1000.03.0/vmstate and hand off to the
> > e1000 driver to check version ids, you bet I'm feeling a lot more secure
> > than if I'm handing off to whatever happened to register 03.0/vmstate on
> > the target.
>
> I still say it should be the migration code that checks that both vmstate
> structures are for the same type of device. i.e. if necessary the device name
> should be embedded in the device state, not the device path.
I not sure how that fixes the ramblock issue that started this whole
discussion. It's not part of device's vmstate, it goes w/ ram. I think
I'm missing a piece of the puzzle here?
thanks,
-chris
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-16 0:25 ` Chris Wright
@ 2010-06-16 0:30 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 0:30 UTC (permalink / raw)
To: Chris Wright
Cc: Alex Williamson, Jan Kiszka, Markus Armbruster, kvm, qemu-devel,
avi, kraxel
> * Paul Brook (paul@codesourcery.com) wrote:
> > > > I find this argument contradictory. The migration code already needs
> > > > to check whether a device is compatible before it allows migration.
> > > > The driver name is not sufficient to ensure compatibility, so I see
> > > > no benefit in including it in the device address.
> > >
> > > See my comment above, I'm not seeing a sufficient argument about why
> > > driver name matching is a false sense of security. If on an incoming
> > > migration I'm able to match the source provided e1000.03.0/vmstate
> > > against the target registered e1000.03.0/vmstate and hand off to the
> > > e1000 driver to check version ids, you bet I'm feeling a lot more
> > > secure than if I'm handing off to whatever happened to register
> > > 03.0/vmstate on the target.
> >
> > I still say it should be the migration code that checks that both vmstate
> > structures are for the same type of device. i.e. if necessary the device
> > name should be embedded in the device state, not the device path.
>
> I not sure how that fixes the ramblock issue that started this whole
> discussion. It's not part of device's vmstate, it goes w/ ram. I think
> I'm missing a piece of the puzzle here?
My main point there was that ram blocks should be associated with a device
state. Once you do this it should just work as we already know how to match
device states.
It you're trying to transfer ram blocks before matching up the rest of the
state then you're likely to loose in all kinds of different ways.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-16 0:30 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 0:30 UTC (permalink / raw)
To: Chris Wright
Cc: kvm, Jan Kiszka, Markus Armbruster, qemu-devel, Alex Williamson,
avi, kraxel
> * Paul Brook (paul@codesourcery.com) wrote:
> > > > I find this argument contradictory. The migration code already needs
> > > > to check whether a device is compatible before it allows migration.
> > > > The driver name is not sufficient to ensure compatibility, so I see
> > > > no benefit in including it in the device address.
> > >
> > > See my comment above, I'm not seeing a sufficient argument about why
> > > driver name matching is a false sense of security. If on an incoming
> > > migration I'm able to match the source provided e1000.03.0/vmstate
> > > against the target registered e1000.03.0/vmstate and hand off to the
> > > e1000 driver to check version ids, you bet I'm feeling a lot more
> > > secure than if I'm handing off to whatever happened to register
> > > 03.0/vmstate on the target.
> >
> > I still say it should be the migration code that checks that both vmstate
> > structures are for the same type of device. i.e. if necessary the device
> > name should be embedded in the device state, not the device path.
>
> I not sure how that fixes the ramblock issue that started this whole
> discussion. It's not part of device's vmstate, it goes w/ ram. I think
> I'm missing a piece of the puzzle here?
My main point there was that ram blocks should be associated with a device
state. Once you do this it should just work as we already know how to match
device states.
It you're trying to transfer ram blocks before matching up the rest of the
state then you're likely to loose in all kinds of different ways.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-16 0:30 ` Paul Brook
@ 2010-06-16 0:35 ` Chris Wright
-1 siblings, 0 replies; 160+ messages in thread
From: Chris Wright @ 2010-06-16 0:35 UTC (permalink / raw)
To: Paul Brook
Cc: Chris Wright, Alex Williamson, Jan Kiszka, Markus Armbruster,
kvm, qemu-devel, avi, kraxel
* Paul Brook (paul@codesourcery.com) wrote:
> > * Paul Brook (paul@codesourcery.com) wrote:
> > > > > I find this argument contradictory. The migration code already needs
> > > > > to check whether a device is compatible before it allows migration.
> > > > > The driver name is not sufficient to ensure compatibility, so I see
> > > > > no benefit in including it in the device address.
> > > >
> > > > See my comment above, I'm not seeing a sufficient argument about why
> > > > driver name matching is a false sense of security. If on an incoming
> > > > migration I'm able to match the source provided e1000.03.0/vmstate
> > > > against the target registered e1000.03.0/vmstate and hand off to the
> > > > e1000 driver to check version ids, you bet I'm feeling a lot more
> > > > secure than if I'm handing off to whatever happened to register
> > > > 03.0/vmstate on the target.
> > >
> > > I still say it should be the migration code that checks that both vmstate
> > > structures are for the same type of device. i.e. if necessary the device
> > > name should be embedded in the device state, not the device path.
> >
> > I not sure how that fixes the ramblock issue that started this whole
> > discussion. It's not part of device's vmstate, it goes w/ ram. I think
> > I'm missing a piece of the puzzle here?
>
> My main point there was that ram blocks should be associated with a device
> state. Once you do this it should just work as we already know how to match
> device states.
>
> It you're trying to transfer ram blocks before matching up the rest of the
> state then you're likely to loose in all kinds of different ways.
Yes, I see, thanks for clarifying. I agree, ideally we'd create the
entire target image dynamically. It'd still need to know how to connect
all the guest devices to the host, but it makes more sense to me than
half building the system from cmdline on target, then rest filled in.
I think that level of work is a ways away though.
thanks,
-chris
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-16 0:35 ` Chris Wright
0 siblings, 0 replies; 160+ messages in thread
From: Chris Wright @ 2010-06-16 0:35 UTC (permalink / raw)
To: Paul Brook
Cc: Chris Wright, kvm, Jan Kiszka, Markus Armbruster, qemu-devel,
Alex Williamson, avi, kraxel
* Paul Brook (paul@codesourcery.com) wrote:
> > * Paul Brook (paul@codesourcery.com) wrote:
> > > > > I find this argument contradictory. The migration code already needs
> > > > > to check whether a device is compatible before it allows migration.
> > > > > The driver name is not sufficient to ensure compatibility, so I see
> > > > > no benefit in including it in the device address.
> > > >
> > > > See my comment above, I'm not seeing a sufficient argument about why
> > > > driver name matching is a false sense of security. If on an incoming
> > > > migration I'm able to match the source provided e1000.03.0/vmstate
> > > > against the target registered e1000.03.0/vmstate and hand off to the
> > > > e1000 driver to check version ids, you bet I'm feeling a lot more
> > > > secure than if I'm handing off to whatever happened to register
> > > > 03.0/vmstate on the target.
> > >
> > > I still say it should be the migration code that checks that both vmstate
> > > structures are for the same type of device. i.e. if necessary the device
> > > name should be embedded in the device state, not the device path.
> >
> > I not sure how that fixes the ramblock issue that started this whole
> > discussion. It's not part of device's vmstate, it goes w/ ram. I think
> > I'm missing a piece of the puzzle here?
>
> My main point there was that ram blocks should be associated with a device
> state. Once you do this it should just work as we already know how to match
> device states.
>
> It you're trying to transfer ram blocks before matching up the rest of the
> state then you're likely to loose in all kinds of different ways.
Yes, I see, thanks for clarifying. I agree, ideally we'd create the
entire target image dynamically. It'd still need to know how to connect
all the guest devices to the host, but it makes more sense to me than
half building the system from cmdline on target, then rest filled in.
I think that level of work is a ways away though.
thanks,
-chris
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-16 0:35 ` Chris Wright
@ 2010-06-16 1:30 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 1:30 UTC (permalink / raw)
To: Chris Wright
Cc: Alex Williamson, Jan Kiszka, Markus Armbruster, kvm, qemu-devel,
avi, kraxel
> > > > > See my comment above, I'm not seeing a sufficient argument about
> > > > > why driver name matching is a false sense of security.
> > > >
> > > > I still say it should be the migration code that checks that both
> > > > vmstate structures are for the same type of device. i.e. if
> > > > necessary the device name should be embedded in the device state,
> > > > not the device path.
> > >
> > > I not sure how that fixes the ramblock issue that started this whole
> > > discussion. It's not part of device's vmstate, it goes w/ ram. I
> > > think I'm missing a piece of the puzzle here?
> >
> > My main point there was that ram blocks should be associated with a
> > device state. Once you do this it should just work as we already know
> > how to match device states.
> >
> > It you're trying to transfer ram blocks before matching up the rest of
> > the state then you're likely to loose in all kinds of different ways.
... or not. See below.
> Yes, I see, thanks for clarifying. I agree, ideally we'd create the
> entire target image dynamically. It'd still need to know how to connect
> all the guest devices to the host, but it makes more sense to me than
> half building the system from cmdline on target, then rest filled in.
Transferring the machine description on migration is a separate problem.
Lets say we associate each RAM block with a device. Each ram block also has a
name. These names distinguish between blocks attached to a given device, but
need not be globally unique. i.e. devices A and B can both have block named
"foo". RAM block migration happens before device state migration (including
device properties).
There are three relevant migration failure modes:
(1) The same device is present, but has a different size property.
If the incoming block is larger than the allocated block then you loose.
(2) A different device is present, but does not have a ram block of the same
name.
This safely fails migration because of the block name mismatch.
(3) A different device is present, that happens to have a ram block of the
same name.
If the blocks are the same size then transferring the contents is harmless.
If they are different sizes then this will be caught by (1). Either way, the
migration will be failed once we get to the vmstate check.
Note how adding the device type to the canonical address does not effect the
outcome.
Going back to the original problem, (1) is the most interesting.
I suggest that the initial migration phase transfers a list of ram blocks.
Each entry in that list should be {canonical device path, name, size}. You
should lookup all these ram blocks, and fail migration if they are not present
with the correct size[1]. This list also gives you a convenient numeric index
to identify the block during RAM migration.
[1] In the future we may be able to resize blocks. However this is not safe
with the current API.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-16 1:30 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 1:30 UTC (permalink / raw)
To: Chris Wright
Cc: kvm, Jan Kiszka, Markus Armbruster, qemu-devel, Alex Williamson,
avi, kraxel
> > > > > See my comment above, I'm not seeing a sufficient argument about
> > > > > why driver name matching is a false sense of security.
> > > >
> > > > I still say it should be the migration code that checks that both
> > > > vmstate structures are for the same type of device. i.e. if
> > > > necessary the device name should be embedded in the device state,
> > > > not the device path.
> > >
> > > I not sure how that fixes the ramblock issue that started this whole
> > > discussion. It's not part of device's vmstate, it goes w/ ram. I
> > > think I'm missing a piece of the puzzle here?
> >
> > My main point there was that ram blocks should be associated with a
> > device state. Once you do this it should just work as we already know
> > how to match device states.
> >
> > It you're trying to transfer ram blocks before matching up the rest of
> > the state then you're likely to loose in all kinds of different ways.
... or not. See below.
> Yes, I see, thanks for clarifying. I agree, ideally we'd create the
> entire target image dynamically. It'd still need to know how to connect
> all the guest devices to the host, but it makes more sense to me than
> half building the system from cmdline on target, then rest filled in.
Transferring the machine description on migration is a separate problem.
Lets say we associate each RAM block with a device. Each ram block also has a
name. These names distinguish between blocks attached to a given device, but
need not be globally unique. i.e. devices A and B can both have block named
"foo". RAM block migration happens before device state migration (including
device properties).
There are three relevant migration failure modes:
(1) The same device is present, but has a different size property.
If the incoming block is larger than the allocated block then you loose.
(2) A different device is present, but does not have a ram block of the same
name.
This safely fails migration because of the block name mismatch.
(3) A different device is present, that happens to have a ram block of the
same name.
If the blocks are the same size then transferring the contents is harmless.
If they are different sizes then this will be caught by (1). Either way, the
migration will be failed once we get to the vmstate check.
Note how adding the device type to the canonical address does not effect the
outcome.
Going back to the original problem, (1) is the most interesting.
I suggest that the initial migration phase transfers a list of ram blocks.
Each entry in that list should be {canonical device path, name, size}. You
should lookup all these ram blocks, and fail migration if they are not present
with the correct size[1]. This list also gives you a convenient numeric index
to identify the block during RAM migration.
[1] In the future we may be able to resize blocks. However this is not safe
with the current API.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-16 1:30 ` Paul Brook
@ 2010-06-16 2:55 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-16 2:55 UTC (permalink / raw)
To: Paul Brook
Cc: Chris Wright, Jan Kiszka, Markus Armbruster, kvm, qemu-devel,
avi, kraxel
On Wed, 2010-06-16 at 02:30 +0100, Paul Brook wrote:
> Transferring the machine description on migration is a separate problem.
>
> Lets say we associate each RAM block with a device. Each ram block also has a
> name. These names distinguish between blocks attached to a given device, but
> need not be globally unique. i.e. devices A and B can both have block named
> "foo". RAM block migration happens before device state migration (including
> device properties).
>
> There are three relevant migration failure modes:
>
> (1) The same device is present, but has a different size property.
> If the incoming block is larger than the allocated block then you loose.
> (2) A different device is present, but does not have a ram block of the same
> name.
> This safely fails migration because of the block name mismatch.
> (3) A different device is present, that happens to have a ram block of the
> same name.
> If the blocks are the same size then transferring the contents is harmless.
> If they are different sizes then this will be caught by (1). Either way, the
> migration will be failed once we get to the vmstate check.
>
> Note how adding the device type to the canonical address does not effect the
> outcome.
>
> Going back to the original problem, (1) is the most interesting.
>
> I suggest that the initial migration phase transfers a list of ram blocks.
> Each entry in that list should be {canonical device path, name, size}. You
> should lookup all these ram blocks, and fail migration if they are not present
> with the correct size[1]. This list also gives you a convenient numeric index
> to identify the block during RAM migration.
>
> [1] In the future we may be able to resize blocks. However this is not safe
> with the current API.
I think for the most part, you've just described the RAMBlock series of
patches I sent out last week. I'll note that that series creates ram
blocks on the target if they aren't present because of the technicality
that we currently do not have a qemu_ram_free() to cleanup the list when
things go away. Once we have that and cleanup drivers to use it, I
agree we should fail the migration if it occurs, or at least print out a
big warning so we can go fix the driver. If I'm missing where else it's
significantly different please let me know.
Yes, case (3) would fail in the vmstate code without driver name in the
canonical path... or at least we hope it would. But with the driver
name in the canonical path, we can avoid doing a useless operation, fail
earlier, and provide the vmstate with a key piece of information it can
use to help ensure that the incoming state information belongs to the
driver it thinks it does. Seems like a win to me. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-16 2:55 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-16 2:55 UTC (permalink / raw)
To: Paul Brook
Cc: Chris Wright, kvm, Jan Kiszka, Markus Armbruster, qemu-devel,
avi, kraxel
On Wed, 2010-06-16 at 02:30 +0100, Paul Brook wrote:
> Transferring the machine description on migration is a separate problem.
>
> Lets say we associate each RAM block with a device. Each ram block also has a
> name. These names distinguish between blocks attached to a given device, but
> need not be globally unique. i.e. devices A and B can both have block named
> "foo". RAM block migration happens before device state migration (including
> device properties).
>
> There are three relevant migration failure modes:
>
> (1) The same device is present, but has a different size property.
> If the incoming block is larger than the allocated block then you loose.
> (2) A different device is present, but does not have a ram block of the same
> name.
> This safely fails migration because of the block name mismatch.
> (3) A different device is present, that happens to have a ram block of the
> same name.
> If the blocks are the same size then transferring the contents is harmless.
> If they are different sizes then this will be caught by (1). Either way, the
> migration will be failed once we get to the vmstate check.
>
> Note how adding the device type to the canonical address does not effect the
> outcome.
>
> Going back to the original problem, (1) is the most interesting.
>
> I suggest that the initial migration phase transfers a list of ram blocks.
> Each entry in that list should be {canonical device path, name, size}. You
> should lookup all these ram blocks, and fail migration if they are not present
> with the correct size[1]. This list also gives you a convenient numeric index
> to identify the block during RAM migration.
>
> [1] In the future we may be able to resize blocks. However this is not safe
> with the current API.
I think for the most part, you've just described the RAMBlock series of
patches I sent out last week. I'll note that that series creates ram
blocks on the target if they aren't present because of the technicality
that we currently do not have a qemu_ram_free() to cleanup the list when
things go away. Once we have that and cleanup drivers to use it, I
agree we should fail the migration if it occurs, or at least print out a
big warning so we can go fix the driver. If I'm missing where else it's
significantly different please let me know.
Yes, case (3) would fail in the vmstate code without driver name in the
canonical path... or at least we hope it would. But with the driver
name in the canonical path, we can avoid doing a useless operation, fail
earlier, and provide the vmstate with a key piece of information it can
use to help ensure that the incoming state information belongs to the
driver it thinks it does. Seems like a win to me. Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 20:53 ` Alex Williamson
@ 2010-06-16 8:23 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 8:23 UTC (permalink / raw)
To: Alex Williamson
Cc: Paul Brook, chrisw, kvm, Jan Kiszka, qemu-devel, avi, kraxel
Alex Williamson <alex.williamson@redhat.com> writes:
> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>> > > Alex proposed to disambiguate by adding "identified properties of the
>> > > immediate parent bus and device" to the path component. For PCI, these
>> > > are dev.fn. Likewise for any other bus where devices have unambigous
>> > > bus address. The driver name carries no information!
>> >
>> > From user POV, driver names are very handly to address a device
>> > intuitively - except for the case you have tones of devices on the same
>> > bus that are handled by the same driver. For that case we need to
>> > augment the device name with a useful per-bus ID, derived from the bus
>> > address where available, otherwise based on instance numbers.
>>
>> This is where I think you're missing a trick. We don't need to augment the
>> name, we just need to allow the bus id to be used instead.
>
> For the case of a hot remove, I agree. If the user specifies "pci_del
> pci.0/03.0", that's completely sufficient because we don't care what's
> in that slot, just remove it. However, I still see some use cases for
> device names in the path. Take for example:
>
> (A): /i440FX-pcihost/pci.0/e1000.05.0
>
> vs
>
> (B): /pci.0/05.0
>
> (removing both the root bridge driver name and the device driver name)
/ is the main system bus. System bus defines no bus address at the
moment. Therefore, you have to use the driver name i440FX-pcihost.
/i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
dev.fn. Therefore, you can either use the bus address @05.0, or the
driver name e1000.
We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
> If we attach a pci option rom to the device, create some ram to store
> the option rom and name the ram block $(PATH)/rom, with (A) we know more
> about the hierarchy to get to the actual devfn device, and we know the
> type of device that's in the slot. With (B), there's no robustness. If
> we migrated using (B), we could be stuffing a pc e1000 option rom into a
> ppc lsi895, just because it happened to live that the same place and
> have a ram block named rom. Including driver names increases the
> uniqueness of the path.
>
> Another example; if we have two drivers that create a vmstate with name
> "foo", plug one driver into slot 03.0 on the migration source, the other
> into slot 03.0 on the migration destination, what happens? It seems
> likely that the destination will try to load the vmstate from a
> different driver and fail in wonderful and bizarre ways. If we use (A),
> each path automatically has it's own namespace.
>
> ISA is also a good example even though it doesn't do hotplug. Given
> this set:
>
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/ne2k_isa.0x300
>
> versus this set:
>
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0/0x3f8
> /pci.0.01.0/isa.0/0x378
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0/0x300
>
> Which one has devices that are easier to uniquely identify?
>
>> > > For other buses, we need to make something up.
>> > >
>> > > Note that addressing by bus address rather than name is generally
>> > > useful, not just in the context of savevm. For instance, I'd appreciate
>> > > being able to say something like "device_del pci.0/04.0".
>> >
>> > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>> > the bus first before you can identify which device you want to remove.
>>
>> We can allow both.
>>
>> A bus address is sufficient to uniquely identify a device.
>
> A bus address (assuming it exists) is sufficient to uniquely identify a
> device, on a given VM. A bus address only identifies a location when
> comparing two separate VMs.
Identifying a device on a given VM is all a qdev path does.
If you want to check two VMs have the same device in the same slot, then
you need to compare *devices*, not their names. You propose to encode
*one* property of the device in the name, namely its driver. This is
far from sufficient. If you tell me you need it anyway for migration,
I'll have to take that at face value (I'm not an expert there). But
please do not call it "qdev path", because it ain't.
>> I see no reason to
>> require the driver name, or to include it in the canonical device address.
>
> Migration. Including the driver name extends our ability to uniquely
> identify a device across separate VMs. It's then up to the vmstate code
> to figure out whether the device are compatible for migrate state.
Migration needs to recreate the same qdev tree on the destination.
Driver name is just *one* property of a device. Migration needs to
transfer *all* properties. Why encode driver name in the path, but not
the rest? Why can't you put the driver name wherever you put the rest?
>> > > An easy way to get that is to reserve part of the name space for bus
>> > > addresses. If the path component starts with a letter, it's an ID or
>> > > driver name. If it starts with say '@', it's a bus address in
>> > > bus-specific syntax. The bus provides a method to look it up.
>> >
>> > I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>> > set for buses that implement some to-be-defined device addressing
>> > service, the latter is the default on buses where that service is not
>> > available.
>>
>> If we have bus-address then I see no good reason to also add instance-no.
>> For busses that no natural address, we can define the address to be an
>> instance number.
>
> I agree, it should be a bug for any device with a bus address to have an
> instance number other than zero. Anything without a bus number can make
> use of instance numbers, and hopefully will never be hotplugged.
>
>> > > That way, we gain a useful feature, and avoid having an savevm-specific
>> > > "device path" that isn't recognized anywhere else.
>> >
>> > Agreed, we should find one solution for all use cases.
>>
>> I wasn't aware that there was any suggestion of a separate savevm-specific
>> path. The whole point of a device path is to uniquely identify a device
>> within a machine. There may be many different paths that identify the same
>> device. When given a device and asked to generate path, the result should be
>> the canonical address. IMO this should be the least volatile, and avoid
>> redundant information.
Agree.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-16 8:23 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 8:23 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kraxel, kvm, Jan Kiszka, qemu-devel, avi, Paul Brook
Alex Williamson <alex.williamson@redhat.com> writes:
> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>> > > Alex proposed to disambiguate by adding "identified properties of the
>> > > immediate parent bus and device" to the path component. For PCI, these
>> > > are dev.fn. Likewise for any other bus where devices have unambigous
>> > > bus address. The driver name carries no information!
>> >
>> > From user POV, driver names are very handly to address a device
>> > intuitively - except for the case you have tones of devices on the same
>> > bus that are handled by the same driver. For that case we need to
>> > augment the device name with a useful per-bus ID, derived from the bus
>> > address where available, otherwise based on instance numbers.
>>
>> This is where I think you're missing a trick. We don't need to augment the
>> name, we just need to allow the bus id to be used instead.
>
> For the case of a hot remove, I agree. If the user specifies "pci_del
> pci.0/03.0", that's completely sufficient because we don't care what's
> in that slot, just remove it. However, I still see some use cases for
> device names in the path. Take for example:
>
> (A): /i440FX-pcihost/pci.0/e1000.05.0
>
> vs
>
> (B): /pci.0/05.0
>
> (removing both the root bridge driver name and the device driver name)
/ is the main system bus. System bus defines no bus address at the
moment. Therefore, you have to use the driver name i440FX-pcihost.
/i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
dev.fn. Therefore, you can either use the bus address @05.0, or the
driver name e1000.
We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
> If we attach a pci option rom to the device, create some ram to store
> the option rom and name the ram block $(PATH)/rom, with (A) we know more
> about the hierarchy to get to the actual devfn device, and we know the
> type of device that's in the slot. With (B), there's no robustness. If
> we migrated using (B), we could be stuffing a pc e1000 option rom into a
> ppc lsi895, just because it happened to live that the same place and
> have a ram block named rom. Including driver names increases the
> uniqueness of the path.
>
> Another example; if we have two drivers that create a vmstate with name
> "foo", plug one driver into slot 03.0 on the migration source, the other
> into slot 03.0 on the migration destination, what happens? It seems
> likely that the destination will try to load the vmstate from a
> different driver and fail in wonderful and bizarre ways. If we use (A),
> each path automatically has it's own namespace.
>
> ISA is also a good example even though it doesn't do hotplug. Given
> this set:
>
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/mc146818rtc
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-serial.0x3f8
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-parallel.0x378
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/i8042
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/isa-fdc
> /i440FX-pcihost/pci.0/PIIX3.01.0/isa.0/ne2k_isa.0x300
>
> versus this set:
>
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0/0x3f8
> /pci.0.01.0/isa.0/0x378
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0
> /pci.0.01.0/isa.0/0x300
>
> Which one has devices that are easier to uniquely identify?
>
>> > > For other buses, we need to make something up.
>> > >
>> > > Note that addressing by bus address rather than name is generally
>> > > useful, not just in the context of savevm. For instance, I'd appreciate
>> > > being able to say something like "device_del pci.0/04.0".
>> >
>> > And I prefer "device_del [.../]pci.0/e1000". Otherwise you need to dump
>> > the bus first before you can identify which device you want to remove.
>>
>> We can allow both.
>>
>> A bus address is sufficient to uniquely identify a device.
>
> A bus address (assuming it exists) is sufficient to uniquely identify a
> device, on a given VM. A bus address only identifies a location when
> comparing two separate VMs.
Identifying a device on a given VM is all a qdev path does.
If you want to check two VMs have the same device in the same slot, then
you need to compare *devices*, not their names. You propose to encode
*one* property of the device in the name, namely its driver. This is
far from sufficient. If you tell me you need it anyway for migration,
I'll have to take that at face value (I'm not an expert there). But
please do not call it "qdev path", because it ain't.
>> I see no reason to
>> require the driver name, or to include it in the canonical device address.
>
> Migration. Including the driver name extends our ability to uniquely
> identify a device across separate VMs. It's then up to the vmstate code
> to figure out whether the device are compatible for migrate state.
Migration needs to recreate the same qdev tree on the destination.
Driver name is just *one* property of a device. Migration needs to
transfer *all* properties. Why encode driver name in the path, but not
the rest? Why can't you put the driver name wherever you put the rest?
>> > > An easy way to get that is to reserve part of the name space for bus
>> > > addresses. If the path component starts with a letter, it's an ID or
>> > > driver name. If it starts with say '@', it's a bus address in
>> > > bus-specific syntax. The bus provides a method to look it up.
>> >
>> > I would prefer <driver>[@<bus-address>|.<instance-no>]. The former is
>> > set for buses that implement some to-be-defined device addressing
>> > service, the latter is the default on buses where that service is not
>> > available.
>>
>> If we have bus-address then I see no good reason to also add instance-no.
>> For busses that no natural address, we can define the address to be an
>> instance number.
>
> I agree, it should be a bug for any device with a bus address to have an
> instance number other than zero. Anything without a bus number can make
> use of instance numbers, and hopefully will never be hotplugged.
>
>> > > That way, we gain a useful feature, and avoid having an savevm-specific
>> > > "device path" that isn't recognized anywhere else.
>> >
>> > Agreed, we should find one solution for all use cases.
>>
>> I wasn't aware that there was any suggestion of a separate savevm-specific
>> path. The whole point of a device path is to uniquely identify a device
>> within a machine. There may be many different paths that identify the same
>> device. When given a device and asked to generate path, the result should be
>> the canonical address. IMO this should be the least volatile, and avoid
>> redundant information.
Agree.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
2010-06-15 18:01 ` Alex Williamson
(?)
@ 2010-06-16 8:34 ` Markus Armbruster
2010-06-16 8:36 ` Markus Armbruster
-1 siblings, 1 reply; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 8:34 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, Gerd Hoffmann, kvm, qemu-devel, paul, avi
Alex Williamson <alex.williamson@redhat.com> writes:
> On Tue, 2010-06-15 at 10:53 +0200, Markus Armbruster wrote:
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>> > On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
>> >> Hi,
>> >>
>> >> > 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.
>> >>
>> >> You'll need that for every bus along the way down to the device. Create
>> >> a virtual machine with two lsi scsi host adapters, then attach a disk
>> >> with scsi id 0 to each. Just the scsi id isn't good enougth to identify
>> >> the device. You'll need the lsi pci address too.
>> >
>> > Yep, see below.
>> >
>> >> > For now, the only properties I've tagged as path
>> >> > properties are PCI bus addresses and MAC addresses.
>> >>
>> >> mac address isn't needed here. You need the property which specifies
>> >> the bus address. For PCI this obviously is the PCI address. For scsi
>> >> the scsi id. For ISA you can use the I/O port base. virtio-serial the
>> >> port number, ...
>> >
>> > PCI: addr
>> > SCSI: scsi-id
>> > ISA: serial/parallel = iobase, others??
>>
>> If there's no iobase (pathological case), require ID.
>>
>> > ide-drive: unit
>>
>> Bus name is IDE, but it's clear enough what you mean :)
>
> I put ide-drive here because the unit is a property of the device, not
> the bus.
I consider that a (very minor) bug.
>> > I2C: address
>> >
>> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
>> > can be skipped.
>>
>> Really?
>>
>> Anyway, its port number should do as bus address.
>
> Maybe I'm not specifying it correctly. I see a max_nr_ports property,
> but I don't see that each port is a separate qdev.
I see property "nr" in virtconsole_info and virtserialport_info. I
can't see any other virtio-serial devices.
>> > I'm sure I'm still missing some...
>>
>> s390-virtio
>> SSI
>> System
>
> I'll need some help coming up with useful properties to key on for
> these. I had hoped there's only one System bus.
>
>> USB
>
> usb-storage seems to have a useful drive property that lets me
> distinguish these devices:
>
> /i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0/scsi.0/scsi-disk.0
> /i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb1/scsi.0/scsi-disk.0
> ^^^^ drive
>
> But otherwise USB is disappointingly devoid of useful properties at the
> bus level.
Paul suggested physical ports. Doesn't look like we have them, but that
should be fixable.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string
2010-06-16 8:34 ` Markus Armbruster
@ 2010-06-16 8:36 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 8:36 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, Gerd Hoffmann, kvm, qemu-devel, paul, avi
Markus Armbruster <armbru@redhat.com> writes:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
>> On Tue, 2010-06-15 at 10:53 +0200, Markus Armbruster wrote:
>>> Alex Williamson <alex.williamson@redhat.com> writes:
[...]
>>> > virtio-serial doesn't seem to make a DeviceState per port, so I think it
>>> > can be skipped.
>>>
>>> Really?
>>>
>>> Anyway, its port number should do as bus address.
>>
>> Maybe I'm not specifying it correctly. I see a max_nr_ports property,
>> but I don't see that each port is a separate qdev.
>
> I see property "nr" in virtconsole_info and virtserialport_info. I
> can't see any other virtio-serial devices.
Same issue as with ide-drive's unit: should be a bus property.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string)
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
@ 2010-06-16 9:46 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 9:46 UTC (permalink / raw)
To: Alex Williamson; +Cc: qemu-devel, chrisw, kvm, paul, kraxel, avi
A number of changes to qdev paths have been proposed in various threads.
It's becoming harder to keep track of them, so let me sum them up in one
place. Please correct me if I misrepresent your ideas.
I'm going to describe the current state of things, and the proposed
changes (marked with ###).
The device tree has the main system bus as root. A child of a bus is a
device. A child of a device is a bus.
A qdev path consists of qdev path components separated by '/'. It
resolves to a node in the device tree, either bus or device.
The qdev path "/" resolves to the root, i.e. the main system bus.
The qdev path IDENT, where IDENT is an identifier, resolves to the
device whose id is IDENT.
If PATH resolves to device DEV, and a child of DEV has the name IDENT,
then we resolve to that bus.
Bus names are chosen by the system as follows:
* If the driver of the parent device model provides a name, use that.
* Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
number, counting from zero in creation order.
* Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
is the bus number, as above.
### Paul proposes to drop ID.NUM.
### Paul proposes to either drop TYPE.NUM (and require drivers to
provide bus names), or make NUM count separately for each bus type.
If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows:
* If a child of BUS has id IDENT, then we resolve to that device.
### Jan proposes to drop this rule.
* Else, if a child of BUS has a driver with name IDENT, then we resolve
to that device.
If more than one exist, resolve to the first one. This assumes
children are ordered. Order is the same as in "info qtree".
Currently, it's reverse creation order.
This is *not* a stable address.
* Else, if a child of BUS has a driver with alias name IDENT, then we
resolve to that device.
If more than one exist, resolve to the first one. This assumes
children are ordered. Order is the same as in "info qtree".
Currently, it's reverse creation order.
This is *not* a stable address.
### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus
address BUS-ADDR, if devices on this type of bus have bus addresses.
The format of BUS-ADDR depends on the bus.
### Paul proposes to require all buses to define bus addresses. Make
one up if necessary.
### Jan proposes: we resolve PATH/IDENT.NUM as follows:
* If a child of BUS has a driver with name IDENT and an instance
number NUM, then we resolve to that device.
Need a suitable definition of "instance number".
Jan proposes to number devices with the same driver on the same
bus. This assumes children are ordered, see above.
This is *not* a stable address if the bus supports hot-plug.
I propose to us bus-address as instance number. Works best
together with Paul's proposal to define bus addresses. Syntax
IDENT@BUS-ADDR makes more sense then.
* Else, same with driver alias name.
### Here's a possible synthesis of the above three proposals: require
bus addresses, and permit any of
PATH/IDENT
PATH/@BUS-ADDR
PATH/IDENT@BUS-ADDR
PATH/IDENT can't address instances that don't come first.
IDENT in PATH/IDENT@BUS-ADDR is redundant. Therefore, it can't be
the canonical qdev path. That's fine, PATH/@BUS-ADDR serves.
If the above rules resolve PATH to a device in a context where we expect
a bus, and the device has exactly one bus, resolve it to that bus
instead.
### Jan and I propose to drop this rule.
^ permalink raw reply [flat|nested] 160+ messages in thread
* RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string)
@ 2010-06-16 9:46 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 9:46 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, paul, qemu-devel, avi, kraxel
A number of changes to qdev paths have been proposed in various threads.
It's becoming harder to keep track of them, so let me sum them up in one
place. Please correct me if I misrepresent your ideas.
I'm going to describe the current state of things, and the proposed
changes (marked with ###).
The device tree has the main system bus as root. A child of a bus is a
device. A child of a device is a bus.
A qdev path consists of qdev path components separated by '/'. It
resolves to a node in the device tree, either bus or device.
The qdev path "/" resolves to the root, i.e. the main system bus.
The qdev path IDENT, where IDENT is an identifier, resolves to the
device whose id is IDENT.
If PATH resolves to device DEV, and a child of DEV has the name IDENT,
then we resolve to that bus.
Bus names are chosen by the system as follows:
* If the driver of the parent device model provides a name, use that.
* Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
number, counting from zero in creation order.
* Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
is the bus number, as above.
### Paul proposes to drop ID.NUM.
### Paul proposes to either drop TYPE.NUM (and require drivers to
provide bus names), or make NUM count separately for each bus type.
If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows:
* If a child of BUS has id IDENT, then we resolve to that device.
### Jan proposes to drop this rule.
* Else, if a child of BUS has a driver with name IDENT, then we resolve
to that device.
If more than one exist, resolve to the first one. This assumes
children are ordered. Order is the same as in "info qtree".
Currently, it's reverse creation order.
This is *not* a stable address.
* Else, if a child of BUS has a driver with alias name IDENT, then we
resolve to that device.
If more than one exist, resolve to the first one. This assumes
children are ordered. Order is the same as in "info qtree".
Currently, it's reverse creation order.
This is *not* a stable address.
### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus
address BUS-ADDR, if devices on this type of bus have bus addresses.
The format of BUS-ADDR depends on the bus.
### Paul proposes to require all buses to define bus addresses. Make
one up if necessary.
### Jan proposes: we resolve PATH/IDENT.NUM as follows:
* If a child of BUS has a driver with name IDENT and an instance
number NUM, then we resolve to that device.
Need a suitable definition of "instance number".
Jan proposes to number devices with the same driver on the same
bus. This assumes children are ordered, see above.
This is *not* a stable address if the bus supports hot-plug.
I propose to us bus-address as instance number. Works best
together with Paul's proposal to define bus addresses. Syntax
IDENT@BUS-ADDR makes more sense then.
* Else, same with driver alias name.
### Here's a possible synthesis of the above three proposals: require
bus addresses, and permit any of
PATH/IDENT
PATH/@BUS-ADDR
PATH/IDENT@BUS-ADDR
PATH/IDENT can't address instances that don't come first.
IDENT in PATH/IDENT@BUS-ADDR is redundant. Therefore, it can't be
the canonical qdev path. That's fine, PATH/@BUS-ADDR serves.
If the above rules resolve PATH to a device in a context where we expect
a bus, and the device has exactly one bus, resolve it to that bus
instead.
### Jan and I propose to drop this rule.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string)
2010-06-16 9:46 ` Markus Armbruster
@ 2010-06-16 10:40 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 10:40 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Alex Williamson, qemu-devel, chrisw, kvm, kraxel, avi
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
I revised this proposal: Drop the .NUM part, and require drivers provide a bus
name if TYPE would result in ambiguous names.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string)
@ 2010-06-16 10:40 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 10:40 UTC (permalink / raw)
To: Markus Armbruster; +Cc: chrisw, kvm, qemu-devel, Alex Williamson, avi, kraxel
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
I revised this proposal: Drop the .NUM part, and require drivers provide a bus
name if TYPE would result in ambiguous names.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-16 9:46 ` Markus Armbruster
@ 2010-06-16 11:37 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-16 11:37 UTC (permalink / raw)
To: Markus Armbruster
Cc: Alex Williamson, qemu-devel, chrisw, kvm, paul, kraxel, avi
Markus Armbruster wrote:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>
> I'm going to describe the current state of things, and the proposed
> changes (marked with ###).
>
>
> The device tree has the main system bus as root. A child of a bus is a
> device. A child of a device is a bus.
>
> A qdev path consists of qdev path components separated by '/'. It
> resolves to a node in the device tree, either bus or device.
>
> The qdev path "/" resolves to the root, i.e. the main system bus.
Another aspect: A path may start with an arbitrary bus name, not only
the system bus. Although this is ambiguous, we need to keep it for
addressing the bus itself due to existing client use. But, IMO, we
should at least start deprecating this for addressing elements below
that bus (e.g. "pci.0/e1000").
And besides specifying devices via absolute qdev paths, we also support
addressing them via their ID if present. I checked if ID/BUS[/...] was
supported so far, but it wasn't. So I did not propose this yet although
it might be a useful abbreviation.
>
> The qdev path IDENT, where IDENT is an identifier, resolves to the
> device whose id is IDENT.
>
> If PATH resolves to device DEV, and a child of DEV has the name IDENT,
> then we resolve to that bus.
>
> Bus names are chosen by the system as follows:
>
> * If the driver of the parent device model provides a name, use that.
>
> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> number, counting from zero in creation order.
>
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to drop ID.NUM.
>
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
>
> If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows:
>
> * If a child of BUS has id IDENT, then we resolve to that device.
>
> ### Jan proposes to drop this rule.
>
> * Else, if a child of BUS has a driver with name IDENT, then we resolve
> to that device.
>
> If more than one exist, resolve to the first one. This assumes
> children are ordered. Order is the same as in "info qtree".
> Currently, it's reverse creation order.
>
> This is *not* a stable address.
>
> * Else, if a child of BUS has a driver with alias name IDENT, then we
> resolve to that device.
>
> If more than one exist, resolve to the first one. This assumes
> children are ordered. Order is the same as in "info qtree".
> Currently, it's reverse creation order.
>
> This is *not* a stable address.
>
> ### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus
> address BUS-ADDR, if devices on this type of bus have bus addresses.
> The format of BUS-ADDR depends on the bus.
>
> ### Paul proposes to require all buses to define bus addresses. Make
> one up if necessary.
>
> ### Jan proposes: we resolve PATH/IDENT.NUM as follows:
>
> * If a child of BUS has a driver with name IDENT and an instance
> number NUM, then we resolve to that device.
>
> Need a suitable definition of "instance number".
>
> Jan proposes to number devices with the same driver on the same
> bus. This assumes children are ordered, see above.
>
> This is *not* a stable address if the bus supports hot-plug.
>
> I propose to us bus-address as instance number. Works best
> together with Paul's proposal to define bus addresses. Syntax
> IDENT@BUS-ADDR makes more sense then.
I would be fine with this scheme, but I assume we still need instance
numbers as fallback for buses without any usable addressing. Example: I
have a patch queued that uses this for internal addressing of all hpet
devices on the system bus (to connect them to the ISA IRQs).
>
> * Else, same with driver alias name.
>
> ### Here's a possible synthesis of the above three proposals: require
> bus addresses, and permit any of
>
> PATH/IDENT
> PATH/@BUS-ADDR
> PATH/IDENT@BUS-ADDR
>
> PATH/IDENT can't address instances that don't come first.
PATH/IDENT[.INSTANCE] would resolve the addressability.
>
> IDENT in PATH/IDENT@BUS-ADDR is redundant. Therefore, it can't be
> the canonical qdev path. That's fine, PATH/@BUS-ADDR serves.
>
> If the above rules resolve PATH to a device in a context where we expect
> a bus, and the device has exactly one bus, resolve it to that bus
> instead.
>
> ### Jan and I propose to drop this rule.
Thanks for this summary!
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-16 11:37 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-16 11:37 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kvm, qemu-devel, Alex Williamson, kraxel, avi, paul
Markus Armbruster wrote:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>
> I'm going to describe the current state of things, and the proposed
> changes (marked with ###).
>
>
> The device tree has the main system bus as root. A child of a bus is a
> device. A child of a device is a bus.
>
> A qdev path consists of qdev path components separated by '/'. It
> resolves to a node in the device tree, either bus or device.
>
> The qdev path "/" resolves to the root, i.e. the main system bus.
Another aspect: A path may start with an arbitrary bus name, not only
the system bus. Although this is ambiguous, we need to keep it for
addressing the bus itself due to existing client use. But, IMO, we
should at least start deprecating this for addressing elements below
that bus (e.g. "pci.0/e1000").
And besides specifying devices via absolute qdev paths, we also support
addressing them via their ID if present. I checked if ID/BUS[/...] was
supported so far, but it wasn't. So I did not propose this yet although
it might be a useful abbreviation.
>
> The qdev path IDENT, where IDENT is an identifier, resolves to the
> device whose id is IDENT.
>
> If PATH resolves to device DEV, and a child of DEV has the name IDENT,
> then we resolve to that bus.
>
> Bus names are chosen by the system as follows:
>
> * If the driver of the parent device model provides a name, use that.
>
> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> number, counting from zero in creation order.
>
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to drop ID.NUM.
>
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
>
> If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows:
>
> * If a child of BUS has id IDENT, then we resolve to that device.
>
> ### Jan proposes to drop this rule.
>
> * Else, if a child of BUS has a driver with name IDENT, then we resolve
> to that device.
>
> If more than one exist, resolve to the first one. This assumes
> children are ordered. Order is the same as in "info qtree".
> Currently, it's reverse creation order.
>
> This is *not* a stable address.
>
> * Else, if a child of BUS has a driver with alias name IDENT, then we
> resolve to that device.
>
> If more than one exist, resolve to the first one. This assumes
> children are ordered. Order is the same as in "info qtree".
> Currently, it's reverse creation order.
>
> This is *not* a stable address.
>
> ### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus
> address BUS-ADDR, if devices on this type of bus have bus addresses.
> The format of BUS-ADDR depends on the bus.
>
> ### Paul proposes to require all buses to define bus addresses. Make
> one up if necessary.
>
> ### Jan proposes: we resolve PATH/IDENT.NUM as follows:
>
> * If a child of BUS has a driver with name IDENT and an instance
> number NUM, then we resolve to that device.
>
> Need a suitable definition of "instance number".
>
> Jan proposes to number devices with the same driver on the same
> bus. This assumes children are ordered, see above.
>
> This is *not* a stable address if the bus supports hot-plug.
>
> I propose to us bus-address as instance number. Works best
> together with Paul's proposal to define bus addresses. Syntax
> IDENT@BUS-ADDR makes more sense then.
I would be fine with this scheme, but I assume we still need instance
numbers as fallback for buses without any usable addressing. Example: I
have a patch queued that uses this for internal addressing of all hpet
devices on the system bus (to connect them to the ISA IRQs).
>
> * Else, same with driver alias name.
>
> ### Here's a possible synthesis of the above three proposals: require
> bus addresses, and permit any of
>
> PATH/IDENT
> PATH/@BUS-ADDR
> PATH/IDENT@BUS-ADDR
>
> PATH/IDENT can't address instances that don't come first.
PATH/IDENT[.INSTANCE] would resolve the addressability.
>
> IDENT in PATH/IDENT@BUS-ADDR is redundant. Therefore, it can't be
> the canonical qdev path. That's fine, PATH/@BUS-ADDR serves.
>
> If the above rules resolve PATH to a device in a context where we expect
> a bus, and the device has exactly one bus, resolve it to that bus
> instead.
>
> ### Jan and I propose to drop this rule.
Thanks for this summary!
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-16 11:37 ` [Qemu-devel] " Jan Kiszka
@ 2010-06-16 11:45 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 11:45 UTC (permalink / raw)
To: Jan Kiszka
Cc: Markus Armbruster, Alex Williamson, qemu-devel, chrisw, kvm, kraxel, avi
> Markus Armbruster wrote:
> > A number of changes to qdev paths have been proposed in various threads.
> > It's becoming harder to keep track of them, so let me sum them up in one
> > place. Please correct me if I misrepresent your ideas.
> >
> > I'm going to describe the current state of things, and the proposed
> > changes (marked with ###).
> >
> >
> > The device tree has the main system bus as root. A child of a bus is a
> > device. A child of a device is a bus.
> >
> > A qdev path consists of qdev path components separated by '/'. It
> > resolves to a node in the device tree, either bus or device.
> >
> > The qdev path "/" resolves to the root, i.e. the main system bus.
>
> Another aspect: A path may start with an arbitrary bus name, not only
> the system bus. Although this is ambiguous, we need to keep it for
> addressing the bus itself due to existing client use. But, IMO, we
> should at least start deprecating this for addressing elements below
> that bus (e.g. "pci.0/e1000").
I think this would be better served by adding explicit aliases/IDs for those
use-cases. i.e. define the global ID "pci.0" to be an alias for
/i440FX-pcihost/pci
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-16 11:45 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 11:45 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, Markus Armbruster, qemu-devel, Alex Williamson, kraxel, avi
> Markus Armbruster wrote:
> > A number of changes to qdev paths have been proposed in various threads.
> > It's becoming harder to keep track of them, so let me sum them up in one
> > place. Please correct me if I misrepresent your ideas.
> >
> > I'm going to describe the current state of things, and the proposed
> > changes (marked with ###).
> >
> >
> > The device tree has the main system bus as root. A child of a bus is a
> > device. A child of a device is a bus.
> >
> > A qdev path consists of qdev path components separated by '/'. It
> > resolves to a node in the device tree, either bus or device.
> >
> > The qdev path "/" resolves to the root, i.e. the main system bus.
>
> Another aspect: A path may start with an arbitrary bus name, not only
> the system bus. Although this is ambiguous, we need to keep it for
> addressing the bus itself due to existing client use. But, IMO, we
> should at least start deprecating this for addressing elements below
> that bus (e.g. "pci.0/e1000").
I think this would be better served by adding explicit aliases/IDs for those
use-cases. i.e. define the global ID "pci.0" to be an alias for
/i440FX-pcihost/pci
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-16 11:45 ` [Qemu-devel] " Paul Brook
@ 2010-06-16 12:01 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-16 12:01 UTC (permalink / raw)
To: Paul Brook
Cc: Markus Armbruster, Alex Williamson, qemu-devel, chrisw, kvm, kraxel, avi
Paul Brook wrote:
>> Markus Armbruster wrote:
>>> A number of changes to qdev paths have been proposed in various threads.
>>> It's becoming harder to keep track of them, so let me sum them up in one
>>> place. Please correct me if I misrepresent your ideas.
>>>
>>> I'm going to describe the current state of things, and the proposed
>>> changes (marked with ###).
>>>
>>>
>>> The device tree has the main system bus as root. A child of a bus is a
>>> device. A child of a device is a bus.
>>>
>>> A qdev path consists of qdev path components separated by '/'. It
>>> resolves to a node in the device tree, either bus or device.
>>>
>>> The qdev path "/" resolves to the root, i.e. the main system bus.
>> Another aspect: A path may start with an arbitrary bus name, not only
>> the system bus. Although this is ambiguous, we need to keep it for
>> addressing the bus itself due to existing client use. But, IMO, we
>> should at least start deprecating this for addressing elements below
>> that bus (e.g. "pci.0/e1000").
>
> I think this would be better served by adding explicit aliases/IDs for those
> use-cases. i.e. define the global ID "pci.0" to be an alias for
> /i440FX-pcihost/pci
Makes sense. We could attach this ID to the BusState (corresponding to
DeviceState:id) and manually set it during machine init.
qbus_find_recursive would then look for a matching ID instead of a name.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-16 12:01 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-16 12:01 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, Markus Armbruster, qemu-devel, Alex Williamson, kraxel, avi
Paul Brook wrote:
>> Markus Armbruster wrote:
>>> A number of changes to qdev paths have been proposed in various threads.
>>> It's becoming harder to keep track of them, so let me sum them up in one
>>> place. Please correct me if I misrepresent your ideas.
>>>
>>> I'm going to describe the current state of things, and the proposed
>>> changes (marked with ###).
>>>
>>>
>>> The device tree has the main system bus as root. A child of a bus is a
>>> device. A child of a device is a bus.
>>>
>>> A qdev path consists of qdev path components separated by '/'. It
>>> resolves to a node in the device tree, either bus or device.
>>>
>>> The qdev path "/" resolves to the root, i.e. the main system bus.
>> Another aspect: A path may start with an arbitrary bus name, not only
>> the system bus. Although this is ambiguous, we need to keep it for
>> addressing the bus itself due to existing client use. But, IMO, we
>> should at least start deprecating this for addressing elements below
>> that bus (e.g. "pci.0/e1000").
>
> I think this would be better served by adding explicit aliases/IDs for those
> use-cases. i.e. define the global ID "pci.0" to be an alias for
> /i440FX-pcihost/pci
Makes sense. We could attach this ID to the BusState (corresponding to
DeviceState:id) and manually set it during machine init.
qbus_find_recursive would then look for a matching ID instead of a name.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: RFC qdev path semantics
2010-06-16 12:01 ` [Qemu-devel] " Jan Kiszka
@ 2010-06-16 12:21 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 12:21 UTC (permalink / raw)
To: qemu-devel
Cc: Jan Kiszka, chrisw, kvm, Markus Armbruster, Alex Williamson, kraxel, avi
> > I think this would be better served by adding explicit aliases/IDs for
> > those use-cases. i.e. define the global ID "pci.0" to be an alias for
> >
> > /i440FX-pcihost/pci
>
> Makes sense. We could attach this ID to the BusState (corresponding to
> DeviceState:id) and manually set it during machine init.
> qbus_find_recursive would then look for a matching ID instead of a name.
If we accept your proposal that global ids are not accepted as local device
identifiers, then these probably shouldn't be stored in the device tree at
all.
Allowing at most one global ID per node also seems like a rather arbitrary
limitation.
How about having a global alias table that maps an ID to a devtree path?
The code to handle these becomes a straight string substitution followed by a
normal path lookup. We don't need separate code for device v.s. bus, and
"global_device_id/busname" just works.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-16 12:21 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 12:21 UTC (permalink / raw)
To: qemu-devel
Cc: chrisw, kvm, Jan Kiszka, Markus Armbruster, Alex Williamson, kraxel, avi
> > I think this would be better served by adding explicit aliases/IDs for
> > those use-cases. i.e. define the global ID "pci.0" to be an alias for
> >
> > /i440FX-pcihost/pci
>
> Makes sense. We could attach this ID to the BusState (corresponding to
> DeviceState:id) and manually set it during machine init.
> qbus_find_recursive would then look for a matching ID instead of a name.
If we accept your proposal that global ids are not accepted as local device
identifiers, then these probably shouldn't be stored in the device tree at
all.
Allowing at most one global ID per node also seems like a rather arbitrary
limitation.
How about having a global alias table that maps an ID to a devtree path?
The code to handle these becomes a straight string substitution followed by a
normal path lookup. We don't need separate code for device v.s. bus, and
"global_device_id/busname" just works.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-15 15:08 ` Jan Kiszka
@ 2010-06-16 13:02 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 13:02 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kraxel, kvm, qemu-devel, Alex Williamson, avi, Paul Brook
Jan Kiszka <jan.kiszka@siemens.com> writes:
> Markus Armbruster wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
[...]
>>> The format I will propose is "global-ID|/absolute/path", no more
>>> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
>>> bus-local name of a device).
>>
>> Doesn't this break existing usage?
>
> Please name one. It could only be weird corner cases like "device_add
> driver,bus=bus1/ID/bus2" or "bus=ID/bus". But given that we always
> allowed to address "bus2" directly (and this is something I cannot and
> will not change), does this really matter? Maybe allowing paths to start
> with an ID is something worth considering, will think about this again.
I checked with Dan: libvirt doesn't care. So I don't either.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-16 13:02 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 13:02 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kvm, Paul Brook, qemu-devel, Alex Williamson, avi, kraxel
Jan Kiszka <jan.kiszka@siemens.com> writes:
> Markus Armbruster wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
[...]
>>> The format I will propose is "global-ID|/absolute/path", no more
>>> /path/global-ID as this comes with the risk of ambiguity (ID may shadow
>>> bus-local name of a device).
>>
>> Doesn't this break existing usage?
>
> Please name one. It could only be weird corner cases like "device_add
> driver,bus=bus1/ID/bus2" or "bus=ID/bus". But given that we always
> allowed to address "bus2" directly (and this is something I cannot and
> will not change), does this really matter? Maybe allowing paths to start
> with an ID is something worth considering, will think about this again.
I checked with Dan: libvirt doesn't care. So I don't either.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-16 9:46 ` Markus Armbruster
@ 2010-06-16 13:05 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 13:05 UTC (permalink / raw)
To: Alex Williamson; +Cc: qemu-devel, chrisw, kvm, paul, kraxel, avi
Markus Armbruster <armbru@redhat.com> writes:
[...]
> Bus names are chosen by the system as follows:
>
> * If the driver of the parent device model provides a name, use that.
>
> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> number, counting from zero in creation order.
>
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to drop ID.NUM.
ABI change: "-device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0" no
longer works.
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
Likewise.
I'm not saying we can't do this, just that we need to consider backward
compatibility.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-16 13:05 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 13:05 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, paul, qemu-devel, avi, kraxel
Markus Armbruster <armbru@redhat.com> writes:
[...]
> Bus names are chosen by the system as follows:
>
> * If the driver of the parent device model provides a name, use that.
>
> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> number, counting from zero in creation order.
>
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to drop ID.NUM.
ABI change: "-device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0" no
longer works.
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
Likewise.
I'm not saying we can't do this, just that we need to consider backward
compatibility.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-16 13:05 ` [Qemu-devel] " Markus Armbruster
@ 2010-06-16 13:23 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 13:23 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Alex Williamson, qemu-devel, chrisw, kvm, kraxel, avi
> > Bus names are chosen by the system as follows:
> >
> > * If the driver of the parent device model provides a name, use that.
> >
> > * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> >
> > number, counting from zero in creation order.
> >
> > * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> >
> > is the bus number, as above.
> >
> > ### Paul proposes to drop ID.NUM.
>
> ABI change: "-device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0" no
> longer works.
IMO this is a fundamentally broken ABI, so I don't care.
> > ### Paul proposes to either drop TYPE.NUM (and require drivers to
> > provide bus names), or make NUM count separately for each bus type.
>
> Likewise.
I'd be surprised if anyone actually uses absolute device paths at this time,
and they're probably going to be broken by other changes.
Using these default bus names as global identifiers is fixable using aliases
(e.g. -device lsi,bus=pci.0). I'd expect this to cover most interesting uses.
See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02149.html
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-16 13:23 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-16 13:23 UTC (permalink / raw)
To: Markus Armbruster; +Cc: chrisw, kvm, qemu-devel, Alex Williamson, avi, kraxel
> > Bus names are chosen by the system as follows:
> >
> > * If the driver of the parent device model provides a name, use that.
> >
> > * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> >
> > number, counting from zero in creation order.
> >
> > * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> >
> > is the bus number, as above.
> >
> > ### Paul proposes to drop ID.NUM.
>
> ABI change: "-device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0" no
> longer works.
IMO this is a fundamentally broken ABI, so I don't care.
> > ### Paul proposes to either drop TYPE.NUM (and require drivers to
> > provide bus names), or make NUM count separately for each bus type.
>
> Likewise.
I'd be surprised if anyone actually uses absolute device paths at this time,
and they're probably going to be broken by other changes.
Using these default bus names as global identifiers is fixable using aliases
(e.g. -device lsi,bus=pci.0). I'd expect this to cover most interesting uses.
See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02149.html
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: RFC qdev path semantics
2010-06-16 12:21 ` Paul Brook
@ 2010-06-16 13:50 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-16 13:50 UTC (permalink / raw)
To: Paul Brook
Cc: qemu-devel, chrisw, kvm, Markus Armbruster, Alex Williamson, kraxel, avi
Paul Brook wrote:
>>> I think this would be better served by adding explicit aliases/IDs for
>>> those use-cases. i.e. define the global ID "pci.0" to be an alias for
>>>
>>> /i440FX-pcihost/pci
>> Makes sense. We could attach this ID to the BusState (corresponding to
>> DeviceState:id) and manually set it during machine init.
>> qbus_find_recursive would then look for a matching ID instead of a name.
>
> If we accept your proposal that global ids are not accepted as local device
> identifiers, then these probably shouldn't be stored in the device tree at
> all.
>
> Allowing at most one global ID per node also seems like a rather arbitrary
> limitation.
>
> How about having a global alias table that maps an ID to a devtree path?
> The code to handle these becomes a straight string substitution followed by a
> normal path lookup. We don't need separate code for device v.s. bus, and
> "global_device_id/busname" just works.
No principle concerns about such a table. It should nevertheless be
reference-based to assist lifetime management of aliases that are
created together with the devices they point to.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-16 13:50 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-16 13:50 UTC (permalink / raw)
To: Paul Brook
Cc: chrisw, kvm, qemu-devel, Markus Armbruster, Alex Williamson, kraxel, avi
Paul Brook wrote:
>>> I think this would be better served by adding explicit aliases/IDs for
>>> those use-cases. i.e. define the global ID "pci.0" to be an alias for
>>>
>>> /i440FX-pcihost/pci
>> Makes sense. We could attach this ID to the BusState (corresponding to
>> DeviceState:id) and manually set it during machine init.
>> qbus_find_recursive would then look for a matching ID instead of a name.
>
> If we accept your proposal that global ids are not accepted as local device
> identifiers, then these probably shouldn't be stored in the device tree at
> all.
>
> Allowing at most one global ID per node also seems like a rather arbitrary
> limitation.
>
> How about having a global alias table that maps an ID to a devtree path?
> The code to handle these becomes a straight string substitution followed by a
> normal path lookup. We don't need separate code for device v.s. bus, and
> "global_device_id/busname" just works.
No principle concerns about such a table. It should nevertheless be
reference-based to assist lifetime management of aliases that are
created together with the devices they point to.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: RFC qdev path semantics
2010-06-16 13:23 ` [Qemu-devel] " Paul Brook
@ 2010-06-16 14:31 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 14:31 UTC (permalink / raw)
To: Paul Brook; +Cc: chrisw, kvm, qemu-devel, Alex Williamson, avi, kraxel
Paul Brook <paul@codesourcery.com> writes:
>> > Bus names are chosen by the system as follows:
>> >
>> > * If the driver of the parent device model provides a name, use that.
>> >
>> > * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
>> >
>> > number, counting from zero in creation order.
>> >
>> > * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
>> >
>> > is the bus number, as above.
>> >
>> > ### Paul proposes to drop ID.NUM.
>>
>> ABI change: "-device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0" no
>> longer works.
>
> IMO this is a fundamentally broken ABI, so I don't care.
Users of this ABI won't appreciate that attitude.
I do support dropping ID.NUM, but we owe our users due ABI diligence.
>> > ### Paul proposes to either drop TYPE.NUM (and require drivers to
>> > provide bus names), or make NUM count separately for each bus type.
>>
>> Likewise.
>
> I'd be surprised if anyone actually uses absolute device paths at this time,
> and they're probably going to be broken by other changes.
Yes.
> Using these default bus names as global identifiers is fixable using aliases
> (e.g. -device lsi,bus=pci.0). I'd expect this to cover most interesting uses.
> See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02149.html
Keeping the old bus names work for the buses we create automatically
shouldn't be hard. Only a few, and no ID.NUM there. It's the
user-created buses that worry me.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-16 14:31 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-16 14:31 UTC (permalink / raw)
To: Paul Brook; +Cc: chrisw, kvm, qemu-devel, Alex Williamson, kraxel, avi
Paul Brook <paul@codesourcery.com> writes:
>> > Bus names are chosen by the system as follows:
>> >
>> > * If the driver of the parent device model provides a name, use that.
>> >
>> > * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
>> >
>> > number, counting from zero in creation order.
>> >
>> > * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
>> >
>> > is the bus number, as above.
>> >
>> > ### Paul proposes to drop ID.NUM.
>>
>> ABI change: "-device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0" no
>> longer works.
>
> IMO this is a fundamentally broken ABI, so I don't care.
Users of this ABI won't appreciate that attitude.
I do support dropping ID.NUM, but we owe our users due ABI diligence.
>> > ### Paul proposes to either drop TYPE.NUM (and require drivers to
>> > provide bus names), or make NUM count separately for each bus type.
>>
>> Likewise.
>
> I'd be surprised if anyone actually uses absolute device paths at this time,
> and they're probably going to be broken by other changes.
Yes.
> Using these default bus names as global identifiers is fixable using aliases
> (e.g. -device lsi,bus=pci.0). I'd expect this to cover most interesting uses.
> See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02149.html
Keeping the old bus names work for the buses we create automatically
shouldn't be hard. Only a few, and no ID.NUM there. It's the
user-created buses that worry me.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-16 9:46 ` Markus Armbruster
@ 2010-06-17 21:43 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-17 21:43 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-devel, chrisw, kvm, paul, kraxel, avi
I'm a little bit lost at how to implement something to print these
semantics, but a couple comments below...
On Wed, 2010-06-16 at 11:46 +0200, Markus Armbruster wrote:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>
> I'm going to describe the current state of things, and the proposed
> changes (marked with ###).
>
>
> The device tree has the main system bus as root. A child of a bus is a
> device. A child of a device is a bus.
>
> A qdev path consists of qdev path components separated by '/'. It
> resolves to a node in the device tree, either bus or device.
>
> The qdev path "/" resolves to the root, i.e. the main system bus.
>
> The qdev path IDENT, where IDENT is an identifier, resolves to the
> device whose id is IDENT.
>
> If PATH resolves to device DEV, and a child of DEV has the name IDENT,
> then we resolve to that bus.
>
> Bus names are chosen by the system as follows:
>
> * If the driver of the parent device model provides a name, use that.
>
> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> number, counting from zero in creation order.
>
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to drop ID.NUM.
>
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
I agree, instance numbers are not stable. Would it be reasonable to
outlaw instance numbers of any kind for devices that are children of
buses with BusState.allow_hotplug == 1?
> If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows:
>
> * If a child of BUS has id IDENT, then we resolve to that device.
>
> ### Jan proposes to drop this rule.
>
> * Else, if a child of BUS has a driver with name IDENT, then we resolve
> to that device.
>
> If more than one exist, resolve to the first one. This assumes
> children are ordered. Order is the same as in "info qtree".
> Currently, it's reverse creation order.
>
> This is *not* a stable address.
>
> * Else, if a child of BUS has a driver with alias name IDENT, then we
> resolve to that device.
>
> If more than one exist, resolve to the first one. This assumes
> children are ordered. Order is the same as in "info qtree".
> Currently, it's reverse creation order.
>
> This is *not* a stable address.
>
> ### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus
> address BUS-ADDR, if devices on this type of bus have bus addresses.
> The format of BUS-ADDR depends on the bus.
>
> ### Paul proposes to require all buses to define bus addresses. Make
> one up if necessary.
That seems arbitrary and prone to breakage. How do we handle a subtle
change in device instantiation order and still allow migration? If by
code change or command line ordering my frobnitz moves from:
/i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0
to
/i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1
and it has a vmstate or ramblock associated with it, how do we match
those up?
> ### Jan proposes: we resolve PATH/IDENT.NUM as follows:
This isn't stable. Same as above. I don't think we can allow this on
buses support hotplug.
> * If a child of BUS has a driver with name IDENT and an instance
> number NUM, then we resolve to that device.
>
> Need a suitable definition of "instance number".
>
> Jan proposes to number devices with the same driver on the same
> bus. This assumes children are ordered, see above.
>
> This is *not* a stable address if the bus supports hot-plug.
>
> I propose to us bus-address as instance number. Works best
> together with Paul's proposal to define bus addresses. Syntax
> IDENT@BUS-ADDR makes more sense then.
>
> * Else, same with driver alias name.
>
> ### Here's a possible synthesis of the above three proposals: require
> bus addresses, and permit any of
>
> PATH/IDENT
> PATH/@BUS-ADDR
> PATH/IDENT@BUS-ADDR
>
> PATH/IDENT can't address instances that don't come first.
>
> IDENT in PATH/IDENT@BUS-ADDR is redundant. Therefore, it can't be
> the canonical qdev path. That's fine, PATH/@BUS-ADDR serves.
I can live with PATH/@BUS-ADDR if it's still felt that
PATH/IDENT@BUS-ADDR isn't canonical. What that means is that I'll
probably code up vmstate and ramblocks to append IDENT themselves to
keep all the goodness of having per PATH/IDENT namespaces. Do we want
to settle on a standard end of path delineation? Should I use
PATH/@BUS-ADDR$IDENT.foo
?
Alex
> If the above rules resolve PATH to a device in a context where we expect
> a bus, and the device has exactly one bus, resolve it to that bus
> instead.
>
> ### Jan and I propose to drop this rule.
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-17 21:43 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-17 21:43 UTC (permalink / raw)
To: Markus Armbruster; +Cc: chrisw, kvm, paul, qemu-devel, avi, kraxel
I'm a little bit lost at how to implement something to print these
semantics, but a couple comments below...
On Wed, 2010-06-16 at 11:46 +0200, Markus Armbruster wrote:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>
> I'm going to describe the current state of things, and the proposed
> changes (marked with ###).
>
>
> The device tree has the main system bus as root. A child of a bus is a
> device. A child of a device is a bus.
>
> A qdev path consists of qdev path components separated by '/'. It
> resolves to a node in the device tree, either bus or device.
>
> The qdev path "/" resolves to the root, i.e. the main system bus.
>
> The qdev path IDENT, where IDENT is an identifier, resolves to the
> device whose id is IDENT.
>
> If PATH resolves to device DEV, and a child of DEV has the name IDENT,
> then we resolve to that bus.
>
> Bus names are chosen by the system as follows:
>
> * If the driver of the parent device model provides a name, use that.
>
> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> number, counting from zero in creation order.
>
> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
> is the bus number, as above.
>
> ### Paul proposes to drop ID.NUM.
>
> ### Paul proposes to either drop TYPE.NUM (and require drivers to
> provide bus names), or make NUM count separately for each bus type.
I agree, instance numbers are not stable. Would it be reasonable to
outlaw instance numbers of any kind for devices that are children of
buses with BusState.allow_hotplug == 1?
> If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows:
>
> * If a child of BUS has id IDENT, then we resolve to that device.
>
> ### Jan proposes to drop this rule.
>
> * Else, if a child of BUS has a driver with name IDENT, then we resolve
> to that device.
>
> If more than one exist, resolve to the first one. This assumes
> children are ordered. Order is the same as in "info qtree".
> Currently, it's reverse creation order.
>
> This is *not* a stable address.
>
> * Else, if a child of BUS has a driver with alias name IDENT, then we
> resolve to that device.
>
> If more than one exist, resolve to the first one. This assumes
> children are ordered. Order is the same as in "info qtree".
> Currently, it's reverse creation order.
>
> This is *not* a stable address.
>
> ### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus
> address BUS-ADDR, if devices on this type of bus have bus addresses.
> The format of BUS-ADDR depends on the bus.
>
> ### Paul proposes to require all buses to define bus addresses. Make
> one up if necessary.
That seems arbitrary and prone to breakage. How do we handle a subtle
change in device instantiation order and still allow migration? If by
code change or command line ordering my frobnitz moves from:
/i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0
to
/i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1
and it has a vmstate or ramblock associated with it, how do we match
those up?
> ### Jan proposes: we resolve PATH/IDENT.NUM as follows:
This isn't stable. Same as above. I don't think we can allow this on
buses support hotplug.
> * If a child of BUS has a driver with name IDENT and an instance
> number NUM, then we resolve to that device.
>
> Need a suitable definition of "instance number".
>
> Jan proposes to number devices with the same driver on the same
> bus. This assumes children are ordered, see above.
>
> This is *not* a stable address if the bus supports hot-plug.
>
> I propose to us bus-address as instance number. Works best
> together with Paul's proposal to define bus addresses. Syntax
> IDENT@BUS-ADDR makes more sense then.
>
> * Else, same with driver alias name.
>
> ### Here's a possible synthesis of the above three proposals: require
> bus addresses, and permit any of
>
> PATH/IDENT
> PATH/@BUS-ADDR
> PATH/IDENT@BUS-ADDR
>
> PATH/IDENT can't address instances that don't come first.
>
> IDENT in PATH/IDENT@BUS-ADDR is redundant. Therefore, it can't be
> the canonical qdev path. That's fine, PATH/@BUS-ADDR serves.
I can live with PATH/@BUS-ADDR if it's still felt that
PATH/IDENT@BUS-ADDR isn't canonical. What that means is that I'll
probably code up vmstate and ramblocks to append IDENT themselves to
keep all the goodness of having per PATH/IDENT namespaces. Do we want
to settle on a standard end of path delineation? Should I use
PATH/@BUS-ADDR$IDENT.foo
?
Alex
> If the above rules resolve PATH to a device in a context where we expect
> a bus, and the device has exactly one bus, resolve it to that bus
> instead.
>
> ### Jan and I propose to drop this rule.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-17 21:43 ` [Qemu-devel] " Alex Williamson
@ 2010-06-17 22:01 ` Paul Brook
-1 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-17 22:01 UTC (permalink / raw)
To: Alex Williamson; +Cc: Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
> > ### Paul proposes to require all buses to define bus addresses. Make
> > one up if necessary.
>
> That seems arbitrary and prone to breakage. How do we handle a subtle
> change in device instantiation order and still allow migration? If by
> code change or command line ordering my frobnitz moves from:
>
> /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0
>
> to
>
> /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1
Two things are apparent here.
(a) You've clearly misunderstood the proposals. The paths above make no sense.
(b) You've picked a particularly poor definition of device address for the ISA
bus. We can do much better than device creation order.
> ...
> I can live with PATH/@BUS-ADDR if it's still felt that
> PATH/IDENT@BUS-ADDR isn't canonical. What that means is that I'll
> probably code up vmstate and ramblocks to append IDENT themselves to
> keep all the goodness of having per PATH/IDENT namespaces.
As discussed elsewhere in this thread, addition of IDENT to the device path is
neither necessary nor sufficient for migration.
I really feel like we're going round in circles here.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-17 22:01 ` Paul Brook
0 siblings, 0 replies; 160+ messages in thread
From: Paul Brook @ 2010-06-17 22:01 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, Markus Armbruster, qemu-devel, avi, kraxel
> > ### Paul proposes to require all buses to define bus addresses. Make
> > one up if necessary.
>
> That seems arbitrary and prone to breakage. How do we handle a subtle
> change in device instantiation order and still allow migration? If by
> code change or command line ordering my frobnitz moves from:
>
> /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0
>
> to
>
> /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1
Two things are apparent here.
(a) You've clearly misunderstood the proposals. The paths above make no sense.
(b) You've picked a particularly poor definition of device address for the ISA
bus. We can do much better than device creation order.
> ...
> I can live with PATH/@BUS-ADDR if it's still felt that
> PATH/IDENT@BUS-ADDR isn't canonical. What that means is that I'll
> probably code up vmstate and ramblocks to append IDENT themselves to
> keep all the goodness of having per PATH/IDENT namespaces.
As discussed elsewhere in this thread, addition of IDENT to the device path is
neither necessary nor sufficient for migration.
I really feel like we're going round in circles here.
Paul
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-16 8:23 ` Markus Armbruster
@ 2010-06-17 22:25 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-17 22:25 UTC (permalink / raw)
To: Markus Armbruster
Cc: Paul Brook, chrisw, kvm, Jan Kiszka, qemu-devel, avi, kraxel
On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> >> > > Alex proposed to disambiguate by adding "identified properties of the
> >> > > immediate parent bus and device" to the path component. For PCI, these
> >> > > are dev.fn. Likewise for any other bus where devices have unambigous
> >> > > bus address. The driver name carries no information!
> >> >
> >> > From user POV, driver names are very handly to address a device
> >> > intuitively - except for the case you have tones of devices on the same
> >> > bus that are handled by the same driver. For that case we need to
> >> > augment the device name with a useful per-bus ID, derived from the bus
> >> > address where available, otherwise based on instance numbers.
> >>
> >> This is where I think you're missing a trick. We don't need to augment the
> >> name, we just need to allow the bus id to be used instead.
> >
> > For the case of a hot remove, I agree. If the user specifies "pci_del
> > pci.0/03.0", that's completely sufficient because we don't care what's
> > in that slot, just remove it. However, I still see some use cases for
> > device names in the path. Take for example:
> >
> > (A): /i440FX-pcihost/pci.0/e1000.05.0
> >
> > vs
> >
> > (B): /pci.0/05.0
> >
> > (removing both the root bridge driver name and the device driver name)
>
> / is the main system bus. System bus defines no bus address at the
> moment. Therefore, you have to use the driver name i440FX-pcihost.
So is the general rule "If a device's parent bus does not provide an
address, print device name"?
> /i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
> dev.fn. Therefore, you can either use the bus address @05.0, or the
> driver name e1000.
>
> We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
I object to being able to use anything but an address under a bus that
supports hotplug, but that aside, I think the paths for my example
system look like below. Note that anything behind and including the $
is not the canonical path, that begins the free form, usage specific
string, here filled by missing device names (open to suggestions other
than $ here). Note that were isa devices do not have a bus identifier,
I'm using the device name, which I think follows the same rule as
i440FX-pcihost. Can we agree this is the goal? Thanks,
Alex
/i440FX-pcihost/pci.0/@00.0$i440FX
/i440FX-pcihost/pci.0/@01.0$PIIX3
/i440FX-pcihost/pci.0/@02.0$cirrus-vga
/i440FX-pcihost/pci.0/@01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/@01.0/isa.0/@0x3f8$isa-serial
/i440FX-pcihost/pci.0/@01.0/isa.0/@0x378$isa-parallel
/i440FX-pcihost/pci.0/@01.0/isa.0/i8042
/i440FX-pcihost/pci.0/@01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/@03.0$i82551
/i440FX-pcihost/pci.0/@04.0$virtio-net-pci
/i440FX-pcihost/pci.0/@05.0$e1000
/i440FX-pcihost/pci.0/@06.0$rtl8139
/i440FX-pcihost/pci.0/@07.0$pcnet
/i440FX-pcihost/pci.0/@01.0/isa.0/@0x300$ne2k_isa
/i440FX-pcihost/pci.0/@01.1$piix3-ide
/i440FX-pcihost/pci.0/@01.1/ide.0/@0$ide-drive
/i440FX-pcihost/pci.0/@01.1/ide.1/@0$ide-drive
/i440FX-pcihost/pci.0/@01.2$piix3-usb-uhci
/i440FX-pcihost/pci.0/@01.3$PIIX4_PM
/i440FX-pcihost/pci.0/@01.3/i2c/@80$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@81$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@82$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@83$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@84$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@85$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@86$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@87$smbus-eeprom
/i440FX-pcihost/pci.0/@08.0/scsi.0/@0$scsi-disk
/i440FX-pcihost/pci.0/@08.0/scsi.0/@3$scsi-disk
/i440FX-pcihost/pci.0/@08.0$lsi53c895a
/i440FX-pcihost/pci.0/@01.2/usb.0/@usb0/scsi.0/@0$scsi-disk
/i440FX-pcihost/pci.0/@01.2/usb.0/@usb0$usb-storage
/i440FX-pcihost/pci.0/@09.0$virtio-blk-pci
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-17 22:25 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-17 22:25 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kraxel, kvm, Jan Kiszka, qemu-devel, avi, Paul Brook
On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> >> > > Alex proposed to disambiguate by adding "identified properties of the
> >> > > immediate parent bus and device" to the path component. For PCI, these
> >> > > are dev.fn. Likewise for any other bus where devices have unambigous
> >> > > bus address. The driver name carries no information!
> >> >
> >> > From user POV, driver names are very handly to address a device
> >> > intuitively - except for the case you have tones of devices on the same
> >> > bus that are handled by the same driver. For that case we need to
> >> > augment the device name with a useful per-bus ID, derived from the bus
> >> > address where available, otherwise based on instance numbers.
> >>
> >> This is where I think you're missing a trick. We don't need to augment the
> >> name, we just need to allow the bus id to be used instead.
> >
> > For the case of a hot remove, I agree. If the user specifies "pci_del
> > pci.0/03.0", that's completely sufficient because we don't care what's
> > in that slot, just remove it. However, I still see some use cases for
> > device names in the path. Take for example:
> >
> > (A): /i440FX-pcihost/pci.0/e1000.05.0
> >
> > vs
> >
> > (B): /pci.0/05.0
> >
> > (removing both the root bridge driver name and the device driver name)
>
> / is the main system bus. System bus defines no bus address at the
> moment. Therefore, you have to use the driver name i440FX-pcihost.
So is the general rule "If a device's parent bus does not provide an
address, print device name"?
> /i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
> dev.fn. Therefore, you can either use the bus address @05.0, or the
> driver name e1000.
>
> We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
I object to being able to use anything but an address under a bus that
supports hotplug, but that aside, I think the paths for my example
system look like below. Note that anything behind and including the $
is not the canonical path, that begins the free form, usage specific
string, here filled by missing device names (open to suggestions other
than $ here). Note that were isa devices do not have a bus identifier,
I'm using the device name, which I think follows the same rule as
i440FX-pcihost. Can we agree this is the goal? Thanks,
Alex
/i440FX-pcihost/pci.0/@00.0$i440FX
/i440FX-pcihost/pci.0/@01.0$PIIX3
/i440FX-pcihost/pci.0/@02.0$cirrus-vga
/i440FX-pcihost/pci.0/@01.0/isa.0/mc146818rtc
/i440FX-pcihost/pci.0/@01.0/isa.0/@0x3f8$isa-serial
/i440FX-pcihost/pci.0/@01.0/isa.0/@0x378$isa-parallel
/i440FX-pcihost/pci.0/@01.0/isa.0/i8042
/i440FX-pcihost/pci.0/@01.0/isa.0/isa-fdc
/i440FX-pcihost/pci.0/@03.0$i82551
/i440FX-pcihost/pci.0/@04.0$virtio-net-pci
/i440FX-pcihost/pci.0/@05.0$e1000
/i440FX-pcihost/pci.0/@06.0$rtl8139
/i440FX-pcihost/pci.0/@07.0$pcnet
/i440FX-pcihost/pci.0/@01.0/isa.0/@0x300$ne2k_isa
/i440FX-pcihost/pci.0/@01.1$piix3-ide
/i440FX-pcihost/pci.0/@01.1/ide.0/@0$ide-drive
/i440FX-pcihost/pci.0/@01.1/ide.1/@0$ide-drive
/i440FX-pcihost/pci.0/@01.2$piix3-usb-uhci
/i440FX-pcihost/pci.0/@01.3$PIIX4_PM
/i440FX-pcihost/pci.0/@01.3/i2c/@80$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@81$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@82$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@83$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@84$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@85$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@86$smbus-eeprom
/i440FX-pcihost/pci.0/@01.3/i2c/@87$smbus-eeprom
/i440FX-pcihost/pci.0/@08.0/scsi.0/@0$scsi-disk
/i440FX-pcihost/pci.0/@08.0/scsi.0/@3$scsi-disk
/i440FX-pcihost/pci.0/@08.0$lsi53c895a
/i440FX-pcihost/pci.0/@01.2/usb.0/@usb0/scsi.0/@0$scsi-disk
/i440FX-pcihost/pci.0/@01.2/usb.0/@usb0$usb-storage
/i440FX-pcihost/pci.0/@09.0$virtio-blk-pci
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-17 22:01 ` [Qemu-devel] " Paul Brook
@ 2010-06-17 22:34 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-17 22:34 UTC (permalink / raw)
To: Paul Brook; +Cc: Markus Armbruster, qemu-devel, chrisw, kvm, kraxel, avi
On Thu, 2010-06-17 at 23:01 +0100, Paul Brook wrote:
> > > ### Paul proposes to require all buses to define bus addresses. Make
> > > one up if necessary.
> >
> > That seems arbitrary and prone to breakage. How do we handle a subtle
> > change in device instantiation order and still allow migration? If by
> > code change or command line ordering my frobnitz moves from:
> >
> > /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0
> >
> > to
> >
> > /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1
>
> Two things are apparent here.
> (a) You've clearly misunderstood the proposals. The paths above make no sense.
Sorry, hastily created paths. Though yes, I am a little unclear of the
proposal, feel free to code up how it should work. I hope the other
follow-up I just sent is more correct.
> (b) You've picked a particularly poor definition of device address for the ISA
> bus. We can do much better than device creation order.
Ok, how?
> > ...
> > I can live with PATH/@BUS-ADDR if it's still felt that
> > PATH/IDENT@BUS-ADDR isn't canonical. What that means is that I'll
> > probably code up vmstate and ramblocks to append IDENT themselves to
> > keep all the goodness of having per PATH/IDENT namespaces.
>
> As discussed elsewhere in this thread, addition of IDENT to the device path is
> neither necessary nor sufficient for migration.
>
> I really feel like we're going round in circles here.
Um, I believe I just agreed to remove IDENT from the canonical path and
append it in a usage specific way. I think I've cited a couple relevant
examples of how this can improve the robustness of migration and I have
yet to hear anything but conjecture that this is only a false sense of
security.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-17 22:34 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-17 22:34 UTC (permalink / raw)
To: Paul Brook; +Cc: chrisw, kvm, Markus Armbruster, qemu-devel, avi, kraxel
On Thu, 2010-06-17 at 23:01 +0100, Paul Brook wrote:
> > > ### Paul proposes to require all buses to define bus addresses. Make
> > > one up if necessary.
> >
> > That seems arbitrary and prone to breakage. How do we handle a subtle
> > change in device instantiation order and still allow migration? If by
> > code change or command line ordering my frobnitz moves from:
> >
> > /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0
> >
> > to
> >
> > /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1
>
> Two things are apparent here.
> (a) You've clearly misunderstood the proposals. The paths above make no sense.
Sorry, hastily created paths. Though yes, I am a little unclear of the
proposal, feel free to code up how it should work. I hope the other
follow-up I just sent is more correct.
> (b) You've picked a particularly poor definition of device address for the ISA
> bus. We can do much better than device creation order.
Ok, how?
> > ...
> > I can live with PATH/@BUS-ADDR if it's still felt that
> > PATH/IDENT@BUS-ADDR isn't canonical. What that means is that I'll
> > probably code up vmstate and ramblocks to append IDENT themselves to
> > keep all the goodness of having per PATH/IDENT namespaces.
>
> As discussed elsewhere in this thread, addition of IDENT to the device path is
> neither necessary nor sufficient for migration.
>
> I really feel like we're going round in circles here.
Um, I believe I just agreed to remove IDENT from the canonical path and
append it in a usage specific way. I think I've cited a couple relevant
examples of how this can improve the robustness of migration and I have
yet to hear anything but conjecture that this is only a false sense of
security.
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-17 21:43 ` [Qemu-devel] " Alex Williamson
@ 2010-06-18 7:52 ` Gerd Hoffmann
-1 siblings, 0 replies; 160+ messages in thread
From: Gerd Hoffmann @ 2010-06-18 7:52 UTC (permalink / raw)
To: Alex Williamson; +Cc: Markus Armbruster, qemu-devel, chrisw, kvm, paul, avi
Hi,
>> Bus names are chosen by the system as follows:
>>
>> * If the driver of the parent device model provides a name, use that.
>>
>> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
>> number, counting from zero in creation order.
>>
>> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
>> is the bus number, as above.
>>
>> ### Paul proposes to drop ID.NUM.
>>
>> ### Paul proposes to either drop TYPE.NUM (and require drivers to
>> provide bus names), or make NUM count separately for each bus type.
>
> I agree, instance numbers are not stable.
NUM in the child bus name has *nothing* to do with the savevm instance
number.
cheers,
Gerd
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-18 7:52 ` Gerd Hoffmann
0 siblings, 0 replies; 160+ messages in thread
From: Gerd Hoffmann @ 2010-06-18 7:52 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, Markus Armbruster, qemu-devel, paul, avi
Hi,
>> Bus names are chosen by the system as follows:
>>
>> * If the driver of the parent device model provides a name, use that.
>>
>> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
>> number, counting from zero in creation order.
>>
>> * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
>> is the bus number, as above.
>>
>> ### Paul proposes to drop ID.NUM.
>>
>> ### Paul proposes to either drop TYPE.NUM (and require drivers to
>> provide bus names), or make NUM count separately for each bus type.
>
> I agree, instance numbers are not stable.
NUM in the child bus name has *nothing* to do with the savevm instance
number.
cheers,
Gerd
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-17 22:25 ` Alex Williamson
@ 2010-06-18 9:16 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-18 9:16 UTC (permalink / raw)
To: Alex Williamson
Cc: Markus Armbruster, Paul Brook, chrisw, kvm, qemu-devel, avi, kraxel
Alex Williamson wrote:
> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>>> immediate parent bus and device" to the path component. For PCI, these
>>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>>>> bus address. The driver name carries no information!
>>>>> From user POV, driver names are very handly to address a device
>>>>> intuitively - except for the case you have tones of devices on the same
>>>>> bus that are handled by the same driver. For that case we need to
>>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>>> address where available, otherwise based on instance numbers.
>>>> This is where I think you're missing a trick. We don't need to augment the
>>>> name, we just need to allow the bus id to be used instead.
>>> For the case of a hot remove, I agree. If the user specifies "pci_del
>>> pci.0/03.0", that's completely sufficient because we don't care what's
>>> in that slot, just remove it. However, I still see some use cases for
>>> device names in the path. Take for example:
>>>
>>> (A): /i440FX-pcihost/pci.0/e1000.05.0
>>>
>>> vs
>>>
>>> (B): /pci.0/05.0
>>>
>>> (removing both the root bridge driver name and the device driver name)
>> / is the main system bus. System bus defines no bus address at the
>> moment. Therefore, you have to use the driver name i440FX-pcihost.
>
> So is the general rule "If a device's parent bus does not provide an
> address, print device name"?
What is the device name?
>
>> /i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
>> dev.fn. Therefore, you can either use the bus address @05.0, or the
>> driver name e1000.
>>
>> We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
>
> I object to being able to use anything but an address under a bus that
> supports hotplug, but that aside, I think the paths for my example
> system look like below. Note that anything behind and including the $
> is not the canonical path, that begins the free form, usage specific
> string, here filled by missing device names (open to suggestions other
> than $ here).
What about ":" instead of "$"? Visually more appealing IMO.
> Note that were isa devices do not have a bus identifier,
> I'm using the device name,
Don't understand. Why don't they have their I/O base as prefix? This is
inconsistent, and if we consider anything behind "$" (or ":")
informative, the bus address is mandatory for any device (on a bus with
an addressing scheme).
> which I think follows the same rule as
> i440FX-pcihost. Can we agree this is the goal? Thanks,
It looks almost acceptable from my POV. We just need to define how to
get hold of devices on buses without an addressing scheme (e.g. the
system bus). Using the driver name is insufficient once you have > 1
devices of the same type. Introducing device instance numbers to those
buses would be straightforward IMO.
Once this is done, the next step should be a specification for later use
in docs/qdev-device-use.txt.
Jan
>
> Alex
>
> /i440FX-pcihost/pci.0/@00.0$i440FX
> /i440FX-pcihost/pci.0/@01.0$PIIX3
> /i440FX-pcihost/pci.0/@02.0$cirrus-vga
> /i440FX-pcihost/pci.0/@01.0/isa.0/mc146818rtc
> /i440FX-pcihost/pci.0/@01.0/isa.0/@0x3f8$isa-serial
> /i440FX-pcihost/pci.0/@01.0/isa.0/@0x378$isa-parallel
> /i440FX-pcihost/pci.0/@01.0/isa.0/i8042
> /i440FX-pcihost/pci.0/@01.0/isa.0/isa-fdc
> /i440FX-pcihost/pci.0/@03.0$i82551
> /i440FX-pcihost/pci.0/@04.0$virtio-net-pci
> /i440FX-pcihost/pci.0/@05.0$e1000
> /i440FX-pcihost/pci.0/@06.0$rtl8139
> /i440FX-pcihost/pci.0/@07.0$pcnet
> /i440FX-pcihost/pci.0/@01.0/isa.0/@0x300$ne2k_isa
> /i440FX-pcihost/pci.0/@01.1$piix3-ide
> /i440FX-pcihost/pci.0/@01.1/ide.0/@0$ide-drive
> /i440FX-pcihost/pci.0/@01.1/ide.1/@0$ide-drive
> /i440FX-pcihost/pci.0/@01.2$piix3-usb-uhci
> /i440FX-pcihost/pci.0/@01.3$PIIX4_PM
> /i440FX-pcihost/pci.0/@01.3/i2c/@80$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@81$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@82$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@83$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@84$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@85$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@86$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@87$smbus-eeprom
> /i440FX-pcihost/pci.0/@08.0/scsi.0/@0$scsi-disk
> /i440FX-pcihost/pci.0/@08.0/scsi.0/@3$scsi-disk
> /i440FX-pcihost/pci.0/@08.0$lsi53c895a
> /i440FX-pcihost/pci.0/@01.2/usb.0/@usb0/scsi.0/@0$scsi-disk
> /i440FX-pcihost/pci.0/@01.2/usb.0/@usb0$usb-storage
> /i440FX-pcihost/pci.0/@09.0$virtio-blk-pci
>
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-18 9:16 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-18 9:16 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kraxel, kvm, qemu-devel, Markus Armbruster, avi, Paul Brook
Alex Williamson wrote:
> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>>> immediate parent bus and device" to the path component. For PCI, these
>>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>>>> bus address. The driver name carries no information!
>>>>> From user POV, driver names are very handly to address a device
>>>>> intuitively - except for the case you have tones of devices on the same
>>>>> bus that are handled by the same driver. For that case we need to
>>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>>> address where available, otherwise based on instance numbers.
>>>> This is where I think you're missing a trick. We don't need to augment the
>>>> name, we just need to allow the bus id to be used instead.
>>> For the case of a hot remove, I agree. If the user specifies "pci_del
>>> pci.0/03.0", that's completely sufficient because we don't care what's
>>> in that slot, just remove it. However, I still see some use cases for
>>> device names in the path. Take for example:
>>>
>>> (A): /i440FX-pcihost/pci.0/e1000.05.0
>>>
>>> vs
>>>
>>> (B): /pci.0/05.0
>>>
>>> (removing both the root bridge driver name and the device driver name)
>> / is the main system bus. System bus defines no bus address at the
>> moment. Therefore, you have to use the driver name i440FX-pcihost.
>
> So is the general rule "If a device's parent bus does not provide an
> address, print device name"?
What is the device name?
>
>> /i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
>> dev.fn. Therefore, you can either use the bus address @05.0, or the
>> driver name e1000.
>>
>> We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
>
> I object to being able to use anything but an address under a bus that
> supports hotplug, but that aside, I think the paths for my example
> system look like below. Note that anything behind and including the $
> is not the canonical path, that begins the free form, usage specific
> string, here filled by missing device names (open to suggestions other
> than $ here).
What about ":" instead of "$"? Visually more appealing IMO.
> Note that were isa devices do not have a bus identifier,
> I'm using the device name,
Don't understand. Why don't they have their I/O base as prefix? This is
inconsistent, and if we consider anything behind "$" (or ":")
informative, the bus address is mandatory for any device (on a bus with
an addressing scheme).
> which I think follows the same rule as
> i440FX-pcihost. Can we agree this is the goal? Thanks,
It looks almost acceptable from my POV. We just need to define how to
get hold of devices on buses without an addressing scheme (e.g. the
system bus). Using the driver name is insufficient once you have > 1
devices of the same type. Introducing device instance numbers to those
buses would be straightforward IMO.
Once this is done, the next step should be a specification for later use
in docs/qdev-device-use.txt.
Jan
>
> Alex
>
> /i440FX-pcihost/pci.0/@00.0$i440FX
> /i440FX-pcihost/pci.0/@01.0$PIIX3
> /i440FX-pcihost/pci.0/@02.0$cirrus-vga
> /i440FX-pcihost/pci.0/@01.0/isa.0/mc146818rtc
> /i440FX-pcihost/pci.0/@01.0/isa.0/@0x3f8$isa-serial
> /i440FX-pcihost/pci.0/@01.0/isa.0/@0x378$isa-parallel
> /i440FX-pcihost/pci.0/@01.0/isa.0/i8042
> /i440FX-pcihost/pci.0/@01.0/isa.0/isa-fdc
> /i440FX-pcihost/pci.0/@03.0$i82551
> /i440FX-pcihost/pci.0/@04.0$virtio-net-pci
> /i440FX-pcihost/pci.0/@05.0$e1000
> /i440FX-pcihost/pci.0/@06.0$rtl8139
> /i440FX-pcihost/pci.0/@07.0$pcnet
> /i440FX-pcihost/pci.0/@01.0/isa.0/@0x300$ne2k_isa
> /i440FX-pcihost/pci.0/@01.1$piix3-ide
> /i440FX-pcihost/pci.0/@01.1/ide.0/@0$ide-drive
> /i440FX-pcihost/pci.0/@01.1/ide.1/@0$ide-drive
> /i440FX-pcihost/pci.0/@01.2$piix3-usb-uhci
> /i440FX-pcihost/pci.0/@01.3$PIIX4_PM
> /i440FX-pcihost/pci.0/@01.3/i2c/@80$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@81$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@82$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@83$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@84$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@85$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@86$smbus-eeprom
> /i440FX-pcihost/pci.0/@01.3/i2c/@87$smbus-eeprom
> /i440FX-pcihost/pci.0/@08.0/scsi.0/@0$scsi-disk
> /i440FX-pcihost/pci.0/@08.0/scsi.0/@3$scsi-disk
> /i440FX-pcihost/pci.0/@08.0$lsi53c895a
> /i440FX-pcihost/pci.0/@01.2/usb.0/@usb0/scsi.0/@0$scsi-disk
> /i440FX-pcihost/pci.0/@01.2/usb.0/@usb0$usb-storage
> /i440FX-pcihost/pci.0/@09.0$virtio-blk-pci
>
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-17 22:25 ` Alex Williamson
@ 2010-06-18 14:03 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-18 14:03 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kraxel, kvm, Jan Kiszka, qemu-devel, avi, Paul Brook
Alex Williamson <alex.williamson@redhat.com> writes:
> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>> >> > > Alex proposed to disambiguate by adding "identified properties of the
>> >> > > immediate parent bus and device" to the path component. For PCI, these
>> >> > > are dev.fn. Likewise for any other bus where devices have unambigous
>> >> > > bus address. The driver name carries no information!
>> >> >
>> >> > From user POV, driver names are very handly to address a device
>> >> > intuitively - except for the case you have tones of devices on the same
>> >> > bus that are handled by the same driver. For that case we need to
>> >> > augment the device name with a useful per-bus ID, derived from the bus
>> >> > address where available, otherwise based on instance numbers.
>> >>
>> >> This is where I think you're missing a trick. We don't need to augment the
>> >> name, we just need to allow the bus id to be used instead.
>> >
>> > For the case of a hot remove, I agree. If the user specifies "pci_del
>> > pci.0/03.0", that's completely sufficient because we don't care what's
>> > in that slot, just remove it. However, I still see some use cases for
>> > device names in the path. Take for example:
>> >
>> > (A): /i440FX-pcihost/pci.0/e1000.05.0
>> >
>> > vs
>> >
>> > (B): /pci.0/05.0
>> >
>> > (removing both the root bridge driver name and the device driver name)
>>
>> / is the main system bus. System bus defines no bus address at the
>> moment. Therefore, you have to use the driver name i440FX-pcihost.
>
> So is the general rule "If a device's parent bus does not provide an
> address, print device name"?
I think the general rule for constructing a *canonical* qdev path should
be:
* If it's the main system bus, the path is /.
* If it's another bus, the path is P/B, where P is the canonical path of
the device providing the bus, and B is the bus name. Unambiguous,
since no device ever defines two buses with the same name.
* If it's a device, the path is P/D, where P is the canonical path of
the bus. If the bus defines bus addresses, then D is @A, where A is
the device's bus address.
We haven't made up our minds whether the else case exists, or what to
do if it does. The simple "else D is the device model driver's name"
works only if the bus can't take multiple device models with the same
driver.
The canonical path is not the only path. For instance, a qdev ID is a
valid path, but it's not canonical. /i440FX-pcihost/pci.0/e1000 is
another valid, non-canonical path.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-18 14:03 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-18 14:03 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kvm, Jan Kiszka, Paul Brook, qemu-devel, avi, kraxel
Alex Williamson <alex.williamson@redhat.com> writes:
> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>> Alex Williamson <alex.williamson@redhat.com> writes:
>>
>> > On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>> >> > > Alex proposed to disambiguate by adding "identified properties of the
>> >> > > immediate parent bus and device" to the path component. For PCI, these
>> >> > > are dev.fn. Likewise for any other bus where devices have unambigous
>> >> > > bus address. The driver name carries no information!
>> >> >
>> >> > From user POV, driver names are very handly to address a device
>> >> > intuitively - except for the case you have tones of devices on the same
>> >> > bus that are handled by the same driver. For that case we need to
>> >> > augment the device name with a useful per-bus ID, derived from the bus
>> >> > address where available, otherwise based on instance numbers.
>> >>
>> >> This is where I think you're missing a trick. We don't need to augment the
>> >> name, we just need to allow the bus id to be used instead.
>> >
>> > For the case of a hot remove, I agree. If the user specifies "pci_del
>> > pci.0/03.0", that's completely sufficient because we don't care what's
>> > in that slot, just remove it. However, I still see some use cases for
>> > device names in the path. Take for example:
>> >
>> > (A): /i440FX-pcihost/pci.0/e1000.05.0
>> >
>> > vs
>> >
>> > (B): /pci.0/05.0
>> >
>> > (removing both the root bridge driver name and the device driver name)
>>
>> / is the main system bus. System bus defines no bus address at the
>> moment. Therefore, you have to use the driver name i440FX-pcihost.
>
> So is the general rule "If a device's parent bus does not provide an
> address, print device name"?
I think the general rule for constructing a *canonical* qdev path should
be:
* If it's the main system bus, the path is /.
* If it's another bus, the path is P/B, where P is the canonical path of
the device providing the bus, and B is the bus name. Unambiguous,
since no device ever defines two buses with the same name.
* If it's a device, the path is P/D, where P is the canonical path of
the bus. If the bus defines bus addresses, then D is @A, where A is
the device's bus address.
We haven't made up our minds whether the else case exists, or what to
do if it does. The simple "else D is the device model driver's name"
works only if the bus can't take multiple device models with the same
driver.
The canonical path is not the only path. For instance, a qdev ID is a
valid path, but it's not canonical. /i440FX-pcihost/pci.0/e1000 is
another valid, non-canonical path.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-18 14:03 ` Markus Armbruster
@ 2010-06-18 14:14 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-18 14:14 UTC (permalink / raw)
To: Markus Armbruster
Cc: Alex Williamson, chrisw, kraxel, kvm, qemu-devel, avi, Paul Brook
Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
>> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>
>>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>>>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>>>> immediate parent bus and device" to the path component. For PCI, these
>>>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>>>>> bus address. The driver name carries no information!
>>>>>> From user POV, driver names are very handly to address a device
>>>>>> intuitively - except for the case you have tones of devices on the same
>>>>>> bus that are handled by the same driver. For that case we need to
>>>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>>>> address where available, otherwise based on instance numbers.
>>>>> This is where I think you're missing a trick. We don't need to augment the
>>>>> name, we just need to allow the bus id to be used instead.
>>>> For the case of a hot remove, I agree. If the user specifies "pci_del
>>>> pci.0/03.0", that's completely sufficient because we don't care what's
>>>> in that slot, just remove it. However, I still see some use cases for
>>>> device names in the path. Take for example:
>>>>
>>>> (A): /i440FX-pcihost/pci.0/e1000.05.0
>>>>
>>>> vs
>>>>
>>>> (B): /pci.0/05.0
>>>>
>>>> (removing both the root bridge driver name and the device driver name)
>>> / is the main system bus. System bus defines no bus address at the
>>> moment. Therefore, you have to use the driver name i440FX-pcihost.
>> So is the general rule "If a device's parent bus does not provide an
>> address, print device name"?
>
> I think the general rule for constructing a *canonical* qdev path should
> be:
>
> * If it's the main system bus, the path is /.
>
> * If it's another bus, the path is P/B, where P is the canonical path of
> the device providing the bus, and B is the bus name. Unambiguous,
> since no device ever defines two buses with the same name.
>
> * If it's a device, the path is P/D, where P is the canonical path of
> the bus. If the bus defines bus addresses, then D is @A, where A is
> the device's bus address.
>
> We haven't made up our minds whether the else case exists, or what to
> do if it does. The simple "else D is the device model driver's name"
> works only if the bus can't take multiple device models with the same
> driver.
...which is already on x86 the case with multiple APICs or HPETs on the
system bus.
>
> The canonical path is not the only path. For instance, a qdev ID is a
> valid path, but it's not canonical. /i440FX-pcihost/pci.0/e1000 is
> another valid, non-canonical path.
Not only canonical paths need to be specified, also alias like the
above. We should limit those alias to a required minimum ("required"
means to me: improves human-friendliness compared to canonical form and
preserves backward compatibility where relevant).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-18 14:14 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-18 14:14 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kvm, Paul Brook, qemu-devel, Alex Williamson, avi, kraxel
Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
>
>> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>
>>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>>>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>>>> immediate parent bus and device" to the path component. For PCI, these
>>>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>>>>> bus address. The driver name carries no information!
>>>>>> From user POV, driver names are very handly to address a device
>>>>>> intuitively - except for the case you have tones of devices on the same
>>>>>> bus that are handled by the same driver. For that case we need to
>>>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>>>> address where available, otherwise based on instance numbers.
>>>>> This is where I think you're missing a trick. We don't need to augment the
>>>>> name, we just need to allow the bus id to be used instead.
>>>> For the case of a hot remove, I agree. If the user specifies "pci_del
>>>> pci.0/03.0", that's completely sufficient because we don't care what's
>>>> in that slot, just remove it. However, I still see some use cases for
>>>> device names in the path. Take for example:
>>>>
>>>> (A): /i440FX-pcihost/pci.0/e1000.05.0
>>>>
>>>> vs
>>>>
>>>> (B): /pci.0/05.0
>>>>
>>>> (removing both the root bridge driver name and the device driver name)
>>> / is the main system bus. System bus defines no bus address at the
>>> moment. Therefore, you have to use the driver name i440FX-pcihost.
>> So is the general rule "If a device's parent bus does not provide an
>> address, print device name"?
>
> I think the general rule for constructing a *canonical* qdev path should
> be:
>
> * If it's the main system bus, the path is /.
>
> * If it's another bus, the path is P/B, where P is the canonical path of
> the device providing the bus, and B is the bus name. Unambiguous,
> since no device ever defines two buses with the same name.
>
> * If it's a device, the path is P/D, where P is the canonical path of
> the bus. If the bus defines bus addresses, then D is @A, where A is
> the device's bus address.
>
> We haven't made up our minds whether the else case exists, or what to
> do if it does. The simple "else D is the device model driver's name"
> works only if the bus can't take multiple device models with the same
> driver.
...which is already on x86 the case with multiple APICs or HPETs on the
system bus.
>
> The canonical path is not the only path. For instance, a qdev ID is a
> valid path, but it's not canonical. /i440FX-pcihost/pci.0/e1000 is
> another valid, non-canonical path.
Not only canonical paths need to be specified, also alias like the
above. We should limit those alias to a required minimum ("required"
means to me: improves human-friendliness compared to canonical form and
preserves backward compatibility where relevant).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-16 9:46 ` Markus Armbruster
@ 2010-06-18 14:58 ` Markus Armbruster
-1 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-18 14:58 UTC (permalink / raw)
To: Alex Williamson; +Cc: qemu-devel, chrisw, kvm, paul, kraxel, avi
Markus Armbruster <armbru@redhat.com> writes:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>
> I'm going to describe the current state of things, and the proposed
> changes (marked with ###).
>
>
> The device tree has the main system bus as root. A child of a bus is a
> device. A child of a device is a bus.
>
> A qdev path consists of qdev path components separated by '/'. It
> resolves to a node in the device tree, either bus or device.
>
> The qdev path "/" resolves to the root, i.e. the main system bus.
>
> The qdev path IDENT, where IDENT is an identifier, resolves to the
> device whose id is IDENT.
Err, this is not what the current code does. IDENT resolves to the
*bus* whose name is IDENT. Device IDs don't come into play. Yes, bus
names need not be globally unique. We use whichever bus we find first.
We should really support device IDs as anchor of relative paths.
As far as I can see, we don't currently support paths when we look for a
device, only device IDs. But we'd like to change that. Say we extend
device_del to accept a path, not just a device ID. But how to interpret
an identifier argument then? Backward compatibility and common sense
say it's a device ID. But it's also a relative qdev path with just one
path component, a bus name.
What a mess!
> If PATH resolves to device DEV, and a child of DEV has the name IDENT,
> then we resolve to that bus.
then we resolve PATH/IDENT to that bus.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-18 14:58 ` Markus Armbruster
0 siblings, 0 replies; 160+ messages in thread
From: Markus Armbruster @ 2010-06-18 14:58 UTC (permalink / raw)
To: Alex Williamson; +Cc: chrisw, kvm, paul, qemu-devel, avi, kraxel
Markus Armbruster <armbru@redhat.com> writes:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>
> I'm going to describe the current state of things, and the proposed
> changes (marked with ###).
>
>
> The device tree has the main system bus as root. A child of a bus is a
> device. A child of a device is a bus.
>
> A qdev path consists of qdev path components separated by '/'. It
> resolves to a node in the device tree, either bus or device.
>
> The qdev path "/" resolves to the root, i.e. the main system bus.
>
> The qdev path IDENT, where IDENT is an identifier, resolves to the
> device whose id is IDENT.
Err, this is not what the current code does. IDENT resolves to the
*bus* whose name is IDENT. Device IDs don't come into play. Yes, bus
names need not be globally unique. We use whichever bus we find first.
We should really support device IDs as anchor of relative paths.
As far as I can see, we don't currently support paths when we look for a
device, only device IDs. But we'd like to change that. Say we extend
device_del to accept a path, not just a device ID. But how to interpret
an identifier argument then? Backward compatibility and common sense
say it's a device ID. But it's also a relative qdev path with just one
path component, a bus name.
What a mess!
> If PATH resolves to device DEV, and a child of DEV has the name IDENT,
> then we resolve to that bus.
then we resolve PATH/IDENT to that bus.
[...]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-18 9:16 ` Jan Kiszka
@ 2010-06-18 15:01 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-18 15:01 UTC (permalink / raw)
To: Jan Kiszka
Cc: Markus Armbruster, Paul Brook, chrisw, kvm, qemu-devel, avi, kraxel
On Fri, 2010-06-18 at 11:16 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> >> Alex Williamson <alex.williamson@redhat.com> writes:
> >>
> >>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> >>>>>> Alex proposed to disambiguate by adding "identified properties of the
> >>>>>> immediate parent bus and device" to the path component. For PCI, these
> >>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
> >>>>>> bus address. The driver name carries no information!
> >>>>> From user POV, driver names are very handly to address a device
> >>>>> intuitively - except for the case you have tones of devices on the same
> >>>>> bus that are handled by the same driver. For that case we need to
> >>>>> augment the device name with a useful per-bus ID, derived from the bus
> >>>>> address where available, otherwise based on instance numbers.
> >>>> This is where I think you're missing a trick. We don't need to augment the
> >>>> name, we just need to allow the bus id to be used instead.
> >>> For the case of a hot remove, I agree. If the user specifies "pci_del
> >>> pci.0/03.0", that's completely sufficient because we don't care what's
> >>> in that slot, just remove it. However, I still see some use cases for
> >>> device names in the path. Take for example:
> >>>
> >>> (A): /i440FX-pcihost/pci.0/e1000.05.0
> >>>
> >>> vs
> >>>
> >>> (B): /pci.0/05.0
> >>>
> >>> (removing both the root bridge driver name and the device driver name)
> >> / is the main system bus. System bus defines no bus address at the
> >> moment. Therefore, you have to use the driver name i440FX-pcihost.
> >
> > So is the general rule "If a device's parent bus does not provide an
> > address, print device name"?
>
> What is the device name?
dev->info->name
> >
> >> /i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
> >> dev.fn. Therefore, you can either use the bus address @05.0, or the
> >> driver name e1000.
> >>
> >> We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
> >
> > I object to being able to use anything but an address under a bus that
> > supports hotplug, but that aside, I think the paths for my example
> > system look like below. Note that anything behind and including the $
> > is not the canonical path, that begins the free form, usage specific
> > string, here filled by missing device names (open to suggestions other
> > than $ here).
>
> What about ":" instead of "$"? Visually more appealing IMO.
Sure, that works.
> > Note that were isa devices do not have a bus identifier,
> > I'm using the device name,
>
> Don't understand. Why don't they have their I/O base as prefix? This is
> inconsistent, and if we consider anything behind "$" (or ":")
> informative, the bus address is mandatory for any device (on a bus with
> an addressing scheme).
Not all isa devices expose an iobase property. isa doesn't have an
addressing scheme, it's basically a free for all of grabbing addresses
and interrupts and hoping they don't conflict with no means to uniquely
address a specific device. That's why isa cards are loaded with jumpers
so you can try to move them around.
> > which I think follows the same rule as
> > i440FX-pcihost. Can we agree this is the goal? Thanks,
>
> It looks almost acceptable from my POV. We just need to define how to
> get hold of devices on buses without an addressing scheme (e.g. the
> system bus). Using the driver name is insufficient once you have > 1
> devices of the same type. Introducing device instance numbers to those
> buses would be straightforward IMO.
Yep, as I mentioned, I can live with instance numbers for devices that
do not live on a hotpluggable bus. Where will the instance number go?
A property on the parent bus, the device, field in the DeviceState?
Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-18 15:01 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-18 15:01 UTC (permalink / raw)
To: Jan Kiszka
Cc: chrisw, kraxel, kvm, qemu-devel, Markus Armbruster, avi, Paul Brook
On Fri, 2010-06-18 at 11:16 +0200, Jan Kiszka wrote:
> Alex Williamson wrote:
> > On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> >> Alex Williamson <alex.williamson@redhat.com> writes:
> >>
> >>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
> >>>>>> Alex proposed to disambiguate by adding "identified properties of the
> >>>>>> immediate parent bus and device" to the path component. For PCI, these
> >>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
> >>>>>> bus address. The driver name carries no information!
> >>>>> From user POV, driver names are very handly to address a device
> >>>>> intuitively - except for the case you have tones of devices on the same
> >>>>> bus that are handled by the same driver. For that case we need to
> >>>>> augment the device name with a useful per-bus ID, derived from the bus
> >>>>> address where available, otherwise based on instance numbers.
> >>>> This is where I think you're missing a trick. We don't need to augment the
> >>>> name, we just need to allow the bus id to be used instead.
> >>> For the case of a hot remove, I agree. If the user specifies "pci_del
> >>> pci.0/03.0", that's completely sufficient because we don't care what's
> >>> in that slot, just remove it. However, I still see some use cases for
> >>> device names in the path. Take for example:
> >>>
> >>> (A): /i440FX-pcihost/pci.0/e1000.05.0
> >>>
> >>> vs
> >>>
> >>> (B): /pci.0/05.0
> >>>
> >>> (removing both the root bridge driver name and the device driver name)
> >> / is the main system bus. System bus defines no bus address at the
> >> moment. Therefore, you have to use the driver name i440FX-pcihost.
> >
> > So is the general rule "If a device's parent bus does not provide an
> > address, print device name"?
>
> What is the device name?
dev->info->name
> >
> >> /i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
> >> dev.fn. Therefore, you can either use the bus address @05.0, or the
> >> driver name e1000.
> >>
> >> We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
> >
> > I object to being able to use anything but an address under a bus that
> > supports hotplug, but that aside, I think the paths for my example
> > system look like below. Note that anything behind and including the $
> > is not the canonical path, that begins the free form, usage specific
> > string, here filled by missing device names (open to suggestions other
> > than $ here).
>
> What about ":" instead of "$"? Visually more appealing IMO.
Sure, that works.
> > Note that were isa devices do not have a bus identifier,
> > I'm using the device name,
>
> Don't understand. Why don't they have their I/O base as prefix? This is
> inconsistent, and if we consider anything behind "$" (or ":")
> informative, the bus address is mandatory for any device (on a bus with
> an addressing scheme).
Not all isa devices expose an iobase property. isa doesn't have an
addressing scheme, it's basically a free for all of grabbing addresses
and interrupts and hoping they don't conflict with no means to uniquely
address a specific device. That's why isa cards are loaded with jumpers
so you can try to move them around.
> > which I think follows the same rule as
> > i440FX-pcihost. Can we agree this is the goal? Thanks,
>
> It looks almost acceptable from my POV. We just need to define how to
> get hold of devices on buses without an addressing scheme (e.g. the
> system bus). Using the driver name is insufficient once you have > 1
> devices of the same type. Introducing device instance numbers to those
> buses would be straightforward IMO.
Yep, as I mentioned, I can live with instance numbers for devices that
do not live on a hotpluggable bus. Where will the instance number go?
A property on the parent bus, the device, field in the DeviceState?
Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-18 14:03 ` Markus Armbruster
@ 2010-06-18 15:21 ` Alex Williamson
-1 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-18 15:21 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kraxel, kvm, Jan Kiszka, qemu-devel, avi, Paul Brook
On Fri, 2010-06-18 at 16:03 +0200, Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
> > On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> >> Alex Williamson <alex.williamson@redhat.com> writes:
> >> >
> >> > (A): /i440FX-pcihost/pci.0/e1000.05.0
> >> >
> >> > vs
> >> >
> >> > (B): /pci.0/05.0
> >> >
> >> > (removing both the root bridge driver name and the device driver name)
> >>
> >> / is the main system bus. System bus defines no bus address at the
> >> moment. Therefore, you have to use the driver name i440FX-pcihost.
> >
> > So is the general rule "If a device's parent bus does not provide an
> > address, print device name"?
>
> I think the general rule for constructing a *canonical* qdev path should
> be:
>
> * If it's the main system bus, the path is /.
>
> * If it's another bus, the path is P/B, where P is the canonical path of
> the device providing the bus, and B is the bus name. Unambiguous,
> since no device ever defines two buses with the same name.
>
> * If it's a device, the path is P/D, where P is the canonical path of
> the bus. If the bus defines bus addresses, then D is @A, where A is
> the device's bus address.
>
> We haven't made up our minds whether the else case exists, or what to
> do if it does. The simple "else D is the device model driver's name"
> works only if the bus can't take multiple device models with the same
> driver.
It certainly exists today, so do we make up bus addresses, do we use
driver name + instance number, or ...? Both of these cases need to make
sure they're not artificially imposing a creation order than we can't
guarantee across migration. Hopefully Paul has a better suggestion than
creation order.
> The canonical path is not the only path. For instance, a qdev ID is a
> valid path, but it's not canonical. /i440FX-pcihost/pci.0/e1000 is
> another valid, non-canonical path.
Is it not canonical because of "e1000" or because or "i440FX-pcihost".
It seems like both to me with the nuance that i440FX-pcihost doesn't
support multiple instances, so we know which one it is. Is the correct
canonical path for this then:
/<TBD>/pci.0/@d.f
How do we make progress on defining that TBD and all the ones under isa
buses? Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-18 15:21 ` Alex Williamson
0 siblings, 0 replies; 160+ messages in thread
From: Alex Williamson @ 2010-06-18 15:21 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kvm, Jan Kiszka, Paul Brook, qemu-devel, avi, kraxel
On Fri, 2010-06-18 at 16:03 +0200, Markus Armbruster wrote:
> Alex Williamson <alex.williamson@redhat.com> writes:
> > On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
> >> Alex Williamson <alex.williamson@redhat.com> writes:
> >> >
> >> > (A): /i440FX-pcihost/pci.0/e1000.05.0
> >> >
> >> > vs
> >> >
> >> > (B): /pci.0/05.0
> >> >
> >> > (removing both the root bridge driver name and the device driver name)
> >>
> >> / is the main system bus. System bus defines no bus address at the
> >> moment. Therefore, you have to use the driver name i440FX-pcihost.
> >
> > So is the general rule "If a device's parent bus does not provide an
> > address, print device name"?
>
> I think the general rule for constructing a *canonical* qdev path should
> be:
>
> * If it's the main system bus, the path is /.
>
> * If it's another bus, the path is P/B, where P is the canonical path of
> the device providing the bus, and B is the bus name. Unambiguous,
> since no device ever defines two buses with the same name.
>
> * If it's a device, the path is P/D, where P is the canonical path of
> the bus. If the bus defines bus addresses, then D is @A, where A is
> the device's bus address.
>
> We haven't made up our minds whether the else case exists, or what to
> do if it does. The simple "else D is the device model driver's name"
> works only if the bus can't take multiple device models with the same
> driver.
It certainly exists today, so do we make up bus addresses, do we use
driver name + instance number, or ...? Both of these cases need to make
sure they're not artificially imposing a creation order than we can't
guarantee across migration. Hopefully Paul has a better suggestion than
creation order.
> The canonical path is not the only path. For instance, a qdev ID is a
> valid path, but it's not canonical. /i440FX-pcihost/pci.0/e1000 is
> another valid, non-canonical path.
Is it not canonical because of "e1000" or because or "i440FX-pcihost".
It seems like both to me with the nuance that i440FX-pcihost doesn't
support multiple instances, so we know which one it is. Is the correct
canonical path for this then:
/<TBD>/pci.0/@d.f
How do we make progress on defining that TBD and all the ones under isa
buses? Thanks,
Alex
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
2010-06-18 15:01 ` Alex Williamson
@ 2010-06-18 15:22 ` Jan Kiszka
-1 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-18 15:22 UTC (permalink / raw)
To: Alex Williamson
Cc: Markus Armbruster, Paul Brook, chrisw, kvm, qemu-devel, avi, kraxel
Alex Williamson wrote:
> On Fri, 2010-06-18 at 11:16 +0200, Jan Kiszka wrote:
>> Alex Williamson wrote:
>>> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>>
>>>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>>>>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>>>>> immediate parent bus and device" to the path component. For PCI, these
>>>>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>>>>>> bus address. The driver name carries no information!
>>>>>>> From user POV, driver names are very handly to address a device
>>>>>>> intuitively - except for the case you have tones of devices on the same
>>>>>>> bus that are handled by the same driver. For that case we need to
>>>>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>>>>> address where available, otherwise based on instance numbers.
>>>>>> This is where I think you're missing a trick. We don't need to augment the
>>>>>> name, we just need to allow the bus id to be used instead.
>>>>> For the case of a hot remove, I agree. If the user specifies "pci_del
>>>>> pci.0/03.0", that's completely sufficient because we don't care what's
>>>>> in that slot, just remove it. However, I still see some use cases for
>>>>> device names in the path. Take for example:
>>>>>
>>>>> (A): /i440FX-pcihost/pci.0/e1000.05.0
>>>>>
>>>>> vs
>>>>>
>>>>> (B): /pci.0/05.0
>>>>>
>>>>> (removing both the root bridge driver name and the device driver name)
>>>> / is the main system bus. System bus defines no bus address at the
>>>> moment. Therefore, you have to use the driver name i440FX-pcihost.
>>> So is the general rule "If a device's parent bus does not provide an
>>> address, print device name"?
>> What is the device name?
>
> dev->info->name
That's for me the driver name. However, this one needs extension by an
instance number.
>
>>>> /i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
>>>> dev.fn. Therefore, you can either use the bus address @05.0, or the
>>>> driver name e1000.
>>>>
>>>> We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
>>> I object to being able to use anything but an address under a bus that
>>> supports hotplug, but that aside, I think the paths for my example
>>> system look like below. Note that anything behind and including the $
>>> is not the canonical path, that begins the free form, usage specific
>>> string, here filled by missing device names (open to suggestions other
>>> than $ here).
>> What about ":" instead of "$"? Visually more appealing IMO.
>
> Sure, that works.
>
>>> Note that were isa devices do not have a bus identifier,
>>> I'm using the device name,
>> Don't understand. Why don't they have their I/O base as prefix? This is
>> inconsistent, and if we consider anything behind "$" (or ":")
>> informative, the bus address is mandatory for any device (on a bus with
>> an addressing scheme).
>
> Not all isa devices expose an iobase property. isa doesn't have an
> addressing scheme, it's basically a free for all of grabbing addresses
> and interrupts and hoping they don't conflict with no means to uniquely
> address a specific device. That's why isa cards are loaded with jumpers
> so you can try to move them around.
The question is if there are ISA devices that do not use io, thus have
no such property. Paul pointed out that this might be unrealistic, and
in fact we have no such devices in QEMU so far.
>
>>> which I think follows the same rule as
>>> i440FX-pcihost. Can we agree this is the goal? Thanks,
>> It looks almost acceptable from my POV. We just need to define how to
>> get hold of devices on buses without an addressing scheme (e.g. the
>> system bus). Using the driver name is insufficient once you have > 1
>> devices of the same type. Introducing device instance numbers to those
>> buses would be straightforward IMO.
>
> Yep, as I mentioned, I can live with instance numbers for devices that
> do not live on a hotpluggable bus. Where will the instance number go?
> A property on the parent bus, the device, field in the DeviceState?
So far I'm generating them on the fly. We could store them in the
DeviceState if aliases based on <driver-name>.<instance-no> shall be
forbidden on hotplug buses, i.e. the instance numbers will not change
during VM lifetime. but the question is if such a restriction of alias
(even if the are unstable) wouldn't make things too much asymmetric.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
@ 2010-06-18 15:22 ` Jan Kiszka
0 siblings, 0 replies; 160+ messages in thread
From: Jan Kiszka @ 2010-06-18 15:22 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, kraxel, kvm, qemu-devel, Markus Armbruster, avi, Paul Brook
Alex Williamson wrote:
> On Fri, 2010-06-18 at 11:16 +0200, Jan Kiszka wrote:
>> Alex Williamson wrote:
>>> On Wed, 2010-06-16 at 10:23 +0200, Markus Armbruster wrote:
>>>> Alex Williamson <alex.williamson@redhat.com> writes:
>>>>
>>>>> On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
>>>>>>>> Alex proposed to disambiguate by adding "identified properties of the
>>>>>>>> immediate parent bus and device" to the path component. For PCI, these
>>>>>>>> are dev.fn. Likewise for any other bus where devices have unambigous
>>>>>>>> bus address. The driver name carries no information!
>>>>>>> From user POV, driver names are very handly to address a device
>>>>>>> intuitively - except for the case you have tones of devices on the same
>>>>>>> bus that are handled by the same driver. For that case we need to
>>>>>>> augment the device name with a useful per-bus ID, derived from the bus
>>>>>>> address where available, otherwise based on instance numbers.
>>>>>> This is where I think you're missing a trick. We don't need to augment the
>>>>>> name, we just need to allow the bus id to be used instead.
>>>>> For the case of a hot remove, I agree. If the user specifies "pci_del
>>>>> pci.0/03.0", that's completely sufficient because we don't care what's
>>>>> in that slot, just remove it. However, I still see some use cases for
>>>>> device names in the path. Take for example:
>>>>>
>>>>> (A): /i440FX-pcihost/pci.0/e1000.05.0
>>>>>
>>>>> vs
>>>>>
>>>>> (B): /pci.0/05.0
>>>>>
>>>>> (removing both the root bridge driver name and the device driver name)
>>>> / is the main system bus. System bus defines no bus address at the
>>>> moment. Therefore, you have to use the driver name i440FX-pcihost.
>>> So is the general rule "If a device's parent bus does not provide an
>>> address, print device name"?
>> What is the device name?
>
> dev->info->name
That's for me the driver name. However, this one needs extension by an
instance number.
>
>>>> /i440FX-pcihost/pci.0 is the PCI bus. PCI bus defines a bus address:
>>>> dev.fn. Therefore, you can either use the bus address @05.0, or the
>>>> driver name e1000.
>>>>
>>>> We have "/i440FX-pcihost/pci.0/e1000" vs. "/i440FX-pcihost/pci.0/@05.0".
>>> I object to being able to use anything but an address under a bus that
>>> supports hotplug, but that aside, I think the paths for my example
>>> system look like below. Note that anything behind and including the $
>>> is not the canonical path, that begins the free form, usage specific
>>> string, here filled by missing device names (open to suggestions other
>>> than $ here).
>> What about ":" instead of "$"? Visually more appealing IMO.
>
> Sure, that works.
>
>>> Note that were isa devices do not have a bus identifier,
>>> I'm using the device name,
>> Don't understand. Why don't they have their I/O base as prefix? This is
>> inconsistent, and if we consider anything behind "$" (or ":")
>> informative, the bus address is mandatory for any device (on a bus with
>> an addressing scheme).
>
> Not all isa devices expose an iobase property. isa doesn't have an
> addressing scheme, it's basically a free for all of grabbing addresses
> and interrupts and hoping they don't conflict with no means to uniquely
> address a specific device. That's why isa cards are loaded with jumpers
> so you can try to move them around.
The question is if there are ISA devices that do not use io, thus have
no such property. Paul pointed out that this might be unrealistic, and
in fact we have no such devices in QEMU so far.
>
>>> which I think follows the same rule as
>>> i440FX-pcihost. Can we agree this is the goal? Thanks,
>> It looks almost acceptable from my POV. We just need to define how to
>> get hold of devices on buses without an addressing scheme (e.g. the
>> system bus). Using the driver name is insufficient once you have > 1
>> devices of the same type. Introducing device instance numbers to those
>> buses would be straightforward IMO.
>
> Yep, as I mentioned, I can live with instance numbers for devices that
> do not live on a hotpluggable bus. Where will the instance number go?
> A property on the parent bus, the device, field in the DeviceState?
So far I'm generating them on the fly. We could store them in the
DeviceState if aliases based on <driver-name>.<instance-no> shall be
forbidden on hotplug buses, i.e. the instance numbers will not change
during VM lifetime. but the question is if such a restriction of alias
(even if the are unstable) wouldn't make things too much asymmetric.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: RFC qdev path semantics
2010-06-16 9:46 ` Markus Armbruster
@ 2010-06-22 14:27 ` Anthony Liguori
-1 siblings, 0 replies; 160+ messages in thread
From: Anthony Liguori @ 2010-06-22 14:27 UTC (permalink / raw)
To: Markus Armbruster
Cc: Alex Williamson, qemu-devel, chrisw, kvm, paul, kraxel, avi
On 06/16/2010 04:46 AM, Markus Armbruster wrote:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>
Honestly, I think we've gone off the deep end here. Let's simplify.
We need to uniquely identify ram allocations for the purposes of
savevm. Let's do this:
qdev has a vmsd property. When the qdev device is initialized, it
invokes vmstate_register_with_alias_id.
Let's have vmstate_register_with_alias_id return a unique identifier.
Today, it should be derived from the section header. In the future, it
should be a qdev path (as should the section header).
We need have a qdev->vmsd_base. pci_add_option_rom() will pass
qdev->vmsd_base + a unique suffix to qemu_ram_alloc() which should be in
the form '/suffix'. This suffix only need to identify the ram area
uniquely for for pci_add_option_rom, it should probably be '/PCI-ROM'.
Today, this means that the ram allocations will be consistent with
VMState which is a good thing on the wire. In the future, when we have
full qdev conversion, we can easily switch to using qdev paths as the
vmsd_base with almost no code change.
Regards,
Anthony Liguori
^ permalink raw reply [flat|nested] 160+ messages in thread
* [Qemu-devel] Re: RFC qdev path semantics
@ 2010-06-22 14:27 ` Anthony Liguori
0 siblings, 0 replies; 160+ messages in thread
From: Anthony Liguori @ 2010-06-22 14:27 UTC (permalink / raw)
To: Markus Armbruster
Cc: chrisw, kvm, qemu-devel, Alex Williamson, kraxel, avi, paul
On 06/16/2010 04:46 AM, Markus Armbruster wrote:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>
Honestly, I think we've gone off the deep end here. Let's simplify.
We need to uniquely identify ram allocations for the purposes of
savevm. Let's do this:
qdev has a vmsd property. When the qdev device is initialized, it
invokes vmstate_register_with_alias_id.
Let's have vmstate_register_with_alias_id return a unique identifier.
Today, it should be derived from the section header. In the future, it
should be a qdev path (as should the section header).
We need have a qdev->vmsd_base. pci_add_option_rom() will pass
qdev->vmsd_base + a unique suffix to qemu_ram_alloc() which should be in
the form '/suffix'. This suffix only need to identify the ram area
uniquely for for pci_add_option_rom, it should probably be '/PCI-ROM'.
Today, this means that the ram allocations will be consistent with
VMState which is a good thing on the wire. In the future, when we have
full qdev conversion, we can easily switch to using qdev paths as the
vmsd_base with almost no code change.
Regards,
Anthony Liguori
^ permalink raw reply [flat|nested] 160+ messages in thread
end of thread, other threads:[~2010-06-22 14:27 UTC | newest]
Thread overview: 160+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-14 5:51 [RFC PATCH 0/5] Introduce canonical device hierarchy string Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
2010-06-14 5:51 ` [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
2010-06-14 6:39 ` Markus Armbruster
2010-06-14 6:39 ` Markus Armbruster
2010-06-14 12:52 ` Alex Williamson
2010-06-14 12:52 ` Alex Williamson
2010-06-14 13:00 ` Jan Kiszka
2010-06-14 13:00 ` Jan Kiszka
2010-06-14 13:09 ` Paul Brook
2010-06-14 13:09 ` Paul Brook
2010-06-14 15:29 ` Alex Williamson
2010-06-14 15:29 ` Alex Williamson
2010-06-14 15:42 ` Paul Brook
2010-06-14 15:42 ` Paul Brook
2010-06-14 16:00 ` Jan Kiszka
2010-06-14 16:00 ` Jan Kiszka
2010-06-14 16:38 ` Alex Williamson
2010-06-14 16:38 ` Alex Williamson
2010-06-14 16:49 ` Jan Kiszka
2010-06-14 16:49 ` Jan Kiszka
2010-06-14 18:35 ` Alex Williamson
2010-06-14 18:35 ` Alex Williamson
2010-06-14 21:43 ` Paul Brook
2010-06-14 21:43 ` Paul Brook
2010-06-14 22:11 ` Alex Williamson
2010-06-14 22:11 ` Alex Williamson
2010-06-14 22:46 ` Paul Brook
2010-06-14 22:46 ` Paul Brook
2010-06-15 1:14 ` Alex Williamson
2010-06-15 1:14 ` Alex Williamson
2010-06-15 11:24 ` Paul Brook
2010-06-15 11:24 ` Paul Brook
2010-06-15 8:47 ` Markus Armbruster
2010-06-15 8:47 ` Markus Armbruster
2010-06-15 9:34 ` Jan Kiszka
2010-06-15 9:34 ` Jan Kiszka
2010-06-15 11:28 ` Paul Brook
2010-06-15 11:28 ` Paul Brook
2010-06-15 11:45 ` Jan Kiszka
2010-06-15 11:45 ` Jan Kiszka
2010-06-15 12:04 ` Paul Brook
2010-06-15 12:04 ` Paul Brook
2010-06-15 12:16 ` Jan Kiszka
2010-06-15 12:16 ` Jan Kiszka
2010-06-15 12:39 ` Paul Brook
2010-06-15 12:39 ` Paul Brook
2010-06-15 13:00 ` Jan Kiszka
2010-06-15 13:00 ` Jan Kiszka
2010-06-15 13:14 ` Paul Brook
2010-06-15 13:14 ` Paul Brook
2010-06-15 13:16 ` Markus Armbruster
2010-06-15 13:16 ` Markus Armbruster
2010-06-15 13:32 ` Jan Kiszka
2010-06-15 13:32 ` Jan Kiszka
2010-06-15 20:53 ` Alex Williamson
2010-06-15 20:53 ` Alex Williamson
2010-06-15 21:55 ` Paul Brook
2010-06-15 21:55 ` Paul Brook
2010-06-15 22:33 ` Alex Williamson
2010-06-15 22:33 ` Alex Williamson
2010-06-15 23:01 ` Paul Brook
2010-06-15 23:01 ` Paul Brook
2010-06-15 23:10 ` Alex Williamson
2010-06-15 23:10 ` Alex Williamson
2010-06-16 0:25 ` Chris Wright
2010-06-16 0:25 ` Chris Wright
2010-06-16 0:30 ` Paul Brook
2010-06-16 0:30 ` Paul Brook
2010-06-16 0:35 ` Chris Wright
2010-06-16 0:35 ` Chris Wright
2010-06-16 1:30 ` Paul Brook
2010-06-16 1:30 ` Paul Brook
2010-06-16 2:55 ` Alex Williamson
2010-06-16 2:55 ` Alex Williamson
2010-06-16 8:23 ` Markus Armbruster
2010-06-16 8:23 ` Markus Armbruster
2010-06-17 22:25 ` Alex Williamson
2010-06-17 22:25 ` Alex Williamson
2010-06-18 9:16 ` Jan Kiszka
2010-06-18 9:16 ` Jan Kiszka
2010-06-18 15:01 ` Alex Williamson
2010-06-18 15:01 ` Alex Williamson
2010-06-18 15:22 ` Jan Kiszka
2010-06-18 15:22 ` Jan Kiszka
2010-06-18 14:03 ` Markus Armbruster
2010-06-18 14:03 ` Markus Armbruster
2010-06-18 14:14 ` Jan Kiszka
2010-06-18 14:14 ` Jan Kiszka
2010-06-18 15:21 ` Alex Williamson
2010-06-18 15:21 ` Alex Williamson
2010-06-15 11:42 ` Markus Armbruster
2010-06-15 11:42 ` Markus Armbruster
2010-06-15 11:59 ` Jan Kiszka
2010-06-15 11:59 ` Jan Kiszka
2010-06-15 13:07 ` Markus Armbruster
2010-06-15 13:07 ` Markus Armbruster
2010-06-15 13:19 ` Paul Brook
2010-06-15 13:19 ` Paul Brook
2010-06-15 13:32 ` Paul Brook
2010-06-15 13:32 ` Paul Brook
2010-06-15 15:08 ` Jan Kiszka
2010-06-15 15:08 ` Jan Kiszka
2010-06-16 13:02 ` Markus Armbruster
2010-06-16 13:02 ` Markus Armbruster
2010-06-14 5:51 ` [RFC PATCH 2/5] savevm: Add DeviceState param Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
2010-06-14 5:51 ` [RFC PATCH 3/5] savevm: Make use of the new " Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
2010-06-14 5:51 ` [RFC PATCH 4/5] eepro100: Add a dev field to eeprom new/free functions Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
2010-06-14 5:51 ` [RFC PATCH 5/5] virtio-net: Incorporate a DeviceState pointer and let savevm track instances Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] " Alex Williamson
2010-06-14 7:02 ` [RFC PATCH 0/5] Introduce canonical device hierarchy string Gerd Hoffmann
2010-06-14 7:02 ` [Qemu-devel] " Gerd Hoffmann
2010-06-14 19:56 ` Alex Williamson
2010-06-14 19:56 ` [Qemu-devel] " Alex Williamson
2010-06-15 8:53 ` Markus Armbruster
2010-06-15 8:53 ` Markus Armbruster
2010-06-15 18:01 ` Alex Williamson
2010-06-15 18:01 ` Alex Williamson
2010-06-16 8:34 ` Markus Armbruster
2010-06-16 8:36 ` Markus Armbruster
2010-06-15 9:12 ` Gerd Hoffmann
2010-06-15 9:12 ` [Qemu-devel] " Gerd Hoffmann
2010-06-15 18:03 ` Alex Williamson
2010-06-15 18:03 ` [Qemu-devel] " Alex Williamson
2010-06-16 9:46 ` RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string) Markus Armbruster
2010-06-16 9:46 ` Markus Armbruster
2010-06-16 10:40 ` Paul Brook
2010-06-16 10:40 ` Paul Brook
2010-06-16 11:37 ` RFC qdev path semantics Jan Kiszka
2010-06-16 11:37 ` [Qemu-devel] " Jan Kiszka
2010-06-16 11:45 ` Paul Brook
2010-06-16 11:45 ` [Qemu-devel] " Paul Brook
2010-06-16 12:01 ` Jan Kiszka
2010-06-16 12:01 ` [Qemu-devel] " Jan Kiszka
2010-06-16 12:21 ` Paul Brook
2010-06-16 12:21 ` Paul Brook
2010-06-16 13:50 ` Jan Kiszka
2010-06-16 13:50 ` Jan Kiszka
2010-06-16 13:05 ` Markus Armbruster
2010-06-16 13:05 ` [Qemu-devel] " Markus Armbruster
2010-06-16 13:23 ` Paul Brook
2010-06-16 13:23 ` [Qemu-devel] " Paul Brook
2010-06-16 14:31 ` Markus Armbruster
2010-06-16 14:31 ` Markus Armbruster
2010-06-17 21:43 ` Alex Williamson
2010-06-17 21:43 ` [Qemu-devel] " Alex Williamson
2010-06-17 22:01 ` Paul Brook
2010-06-17 22:01 ` [Qemu-devel] " Paul Brook
2010-06-17 22:34 ` Alex Williamson
2010-06-17 22:34 ` [Qemu-devel] " Alex Williamson
2010-06-18 7:52 ` Gerd Hoffmann
2010-06-18 7:52 ` [Qemu-devel] " Gerd Hoffmann
2010-06-18 14:58 ` Markus Armbruster
2010-06-18 14:58 ` [Qemu-devel] " Markus Armbruster
2010-06-22 14:27 ` Anthony Liguori
2010-06-22 14:27 ` [Qemu-devel] " Anthony Liguori
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.