[PATCHv2 0/8 RFC] boot order specification

[PATCHv2 0/8 RFC] boot order specification

[Gleb Natapov]

This is current sate of the patch series for people to comment on.
I tried to use open firmware naming scheme to specify device path names.

The patch series produce names like these:
for pci machine:
/pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@0
/pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@1
/pci@i0cf8/ata@1,1/ata-disk@1:0
/pci@i0cf8/ata@1,1/ata-disk@1:1
/pci@i0cf8/virtio-blk@3/virtio-disk@0
/pci@i0cf8/ethernet@4/ethernet-phy@0
/pci@i0cf8/ethernet@5/ethernet-phy@0

for isa machine:
adding '/isa/fdc@03f1/floppy@0' at index 2
adding '/isa/fdc@03f1/floppy@1' at index 1
adding '/isa/ata@0170/ata-disk@0:0' at index 0
adding '/isa/ata@0170/ata-disk@0:1' at index 3

Gleb Natapov (8):
  Introduce deriver_name field to DeviceInfo structure.
  Keep track of ISA ports ISA device is using in qdev.
  Add get_dev_path callback to ISA bus in qdev.
  Store IDE bus id in IDEBus structure for easy access.
  Add get_dev_path callback to IDE bus.
  Add get_dev_path callback for system bus.
  Change pci bus get_dev_path callback to print only slot and func
  Add bootindex parameter to net/block/fd device

 block_int.h       |    4 +++-
 hw/cs4231a.c      |    1 +
 hw/e1000.c        |    7 +++++++
 hw/fdc.c          |   17 +++++++++++++++++
 hw/gus.c          |    4 ++++
 hw/ide/cmd646.c   |    4 ++--
 hw/ide/internal.h |    3 ++-
 hw/ide/isa.c      |    5 ++++-
 hw/ide/piix.c     |    5 +++--
 hw/ide/qdev.c     |   24 +++++++++++++++++++++++-
 hw/ide/via.c      |    4 ++--
 hw/isa-bus.c      |   41 +++++++++++++++++++++++++++++++++++++++++
 hw/isa.h          |    4 ++++
 hw/m48t59.c       |    1 +
 hw/mc146818rtc.c  |    1 +
 hw/ne2000-isa.c   |    3 +++
 hw/parallel.c     |    5 +++++
 hw/pci.c          |   11 ++++++-----
 hw/pci_host.c     |    2 ++
 hw/pckbd.c        |    3 +++
 hw/piix_pci.c     |    2 ++
 hw/qdev.c         |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h         |    9 +++++++++
 hw/sb16.c         |    4 ++++
 hw/serial.c       |    1 +
 hw/sysbus.c       |   30 ++++++++++++++++++++++++++++++
 hw/sysbus.h       |    4 ++++
 hw/virtio-blk.c   |    4 ++++
 hw/virtio-net.c   |    4 ++++
 hw/virtio-pci.c   |    2 ++
 net.h             |    4 +++-
 sysemu.h          |    9 +++++++++
 vl.c              |   24 ++++++++++++++++++++++++
 33 files changed, 282 insertions(+), 16 deletions(-)

[Qemu-devel] [PATCHv2 0/8 RFC] boot order specification

[Gleb Natapov]

This is current sate of the patch series for people to comment on.
I tried to use open firmware naming scheme to specify device path names.

The patch series produce names like these:
for pci machine:
/pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@0
/pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@1
/pci@i0cf8/ata@1,1/ata-disk@1:0
/pci@i0cf8/ata@1,1/ata-disk@1:1
/pci@i0cf8/virtio-blk@3/virtio-disk@0
/pci@i0cf8/ethernet@4/ethernet-phy@0
/pci@i0cf8/ethernet@5/ethernet-phy@0

for isa machine:
adding '/isa/fdc@03f1/floppy@0' at index 2
adding '/isa/fdc@03f1/floppy@1' at index 1
adding '/isa/ata@0170/ata-disk@0:0' at index 0
adding '/isa/ata@0170/ata-disk@0:1' at index 3

Gleb Natapov (8):
  Introduce deriver_name field to DeviceInfo structure.
  Keep track of ISA ports ISA device is using in qdev.
  Add get_dev_path callback to ISA bus in qdev.
  Store IDE bus id in IDEBus structure for easy access.
  Add get_dev_path callback to IDE bus.
  Add get_dev_path callback for system bus.
  Change pci bus get_dev_path callback to print only slot and func
  Add bootindex parameter to net/block/fd device

 block_int.h       |    4 +++-
 hw/cs4231a.c      |    1 +
 hw/e1000.c        |    7 +++++++
 hw/fdc.c          |   17 +++++++++++++++++
 hw/gus.c          |    4 ++++
 hw/ide/cmd646.c   |    4 ++--
 hw/ide/internal.h |    3 ++-
 hw/ide/isa.c      |    5 ++++-
 hw/ide/piix.c     |    5 +++--
 hw/ide/qdev.c     |   24 +++++++++++++++++++++++-
 hw/ide/via.c      |    4 ++--
 hw/isa-bus.c      |   41 +++++++++++++++++++++++++++++++++++++++++
 hw/isa.h          |    4 ++++
 hw/m48t59.c       |    1 +
 hw/mc146818rtc.c  |    1 +
 hw/ne2000-isa.c   |    3 +++
 hw/parallel.c     |    5 +++++
 hw/pci.c          |   11 ++++++-----
 hw/pci_host.c     |    2 ++
 hw/pckbd.c        |    3 +++
 hw/piix_pci.c     |    2 ++
 hw/qdev.c         |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h         |    9 +++++++++
 hw/sb16.c         |    4 ++++
 hw/serial.c       |    1 +
 hw/sysbus.c       |   30 ++++++++++++++++++++++++++++++
 hw/sysbus.h       |    4 ++++
 hw/virtio-blk.c   |    4 ++++
 hw/virtio-net.c   |    4 ++++
 hw/virtio-pci.c   |    2 ++
 net.h             |    4 +++-
 sysemu.h          |    9 +++++++++
 vl.c              |   24 ++++++++++++++++++++++++
 33 files changed, 282 insertions(+), 16 deletions(-)

[PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Gleb Natapov]

Add "deriver_name" to DeviceInfo to use in device path building. In
contrast to "name" "driver_name" should refer to functionality device
provides instead of particular device model like "name" does.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/fdc.c        |    1 +
 hw/ide/isa.c    |    1 +
 hw/ide/piix.c   |    1 +
 hw/ide/qdev.c   |    1 +
 hw/isa-bus.c    |    1 +
 hw/piix_pci.c   |    2 ++
 hw/qdev.h       |    6 ++++++
 hw/virtio-pci.c |    2 ++
 8 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/hw/fdc.c b/hw/fdc.c
index c159dcb..b4217a3 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -2040,6 +2040,7 @@ static const VMStateDescription vmstate_isa_fdc ={
 static ISADeviceInfo isa_fdc_info = {
     .init = isabus_fdc_init1,
     .qdev.name  = "isa-fdc",
+    .qdev.driver_name  = "fdc",
     .qdev.size  = sizeof(FDCtrlISABus),
     .qdev.no_user = 1,
     .qdev.vmsd  = &vmstate_isa_fdc,
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 6b57e0d..489cc99 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -98,6 +98,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
 
 static ISADeviceInfo isa_ide_info = {
     .qdev.name  = "isa-ide",
+    .qdev.driver_name  = "ata",
     .qdev.size  = sizeof(ISAIDEState),
     .init       = isa_ide_initfn,
     .qdev.reset = isa_ide_reset,
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 07483e8..6206201 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -182,6 +182,7 @@ PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
 static PCIDeviceInfo piix_ide_info[] = {
     {
         .qdev.name    = "piix3-ide",
+        .qdev.driver_name    = "ata",
         .qdev.size    = sizeof(PCIIDEState),
         .qdev.no_user = 1,
         .init         = pci_piix3_ide_initfn,
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 0808760..341548e 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -134,6 +134,7 @@ static int ide_drive_initfn(IDEDevice *dev)
 
 static IDEDeviceInfo ide_drive_info = {
     .qdev.name  = "ide-drive",
+    .qdev.driver_name  = "ata-disk",
     .qdev.size  = sizeof(IDEDrive),
     .init       = ide_drive_initfn,
     .qdev.props = (Property[]) {
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 4e306de..2c42b80 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -153,6 +153,7 @@ static int isabus_bridge_init(SysBusDevice *dev)
 static SysBusDeviceInfo isabus_bridge_info = {
     .init = isabus_bridge_init,
     .qdev.name  = "isabus-bridge",
+    .qdev.driver_name  = "isa",
     .qdev.size  = sizeof(SysBusDevice),
     .qdev.no_user = 1,
 };
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 00060f3..4e5e5df 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -364,6 +364,7 @@ static PCIDeviceInfo i440fx_info[] = {
         .config_write = i440fx_write_config,
     },{
         .qdev.name    = "PIIX3",
+        .qdev.driver_name  = "pci-isa-bridge",
         .qdev.desc    = "ISA bridge",
         .qdev.size    = sizeof(PIIX3State),
         .qdev.vmsd    = &vmstate_piix3,
@@ -377,6 +378,7 @@ static PCIDeviceInfo i440fx_info[] = {
 static SysBusDeviceInfo i440fx_pcihost_info = {
     .init         = i440fx_pcihost_initfn,
     .qdev.name    = "i440FX-pcihost",
+    .qdev.driver_name = "pci",
     .qdev.size    = sizeof(I440FXState),
     .qdev.no_user = 1,
 };
diff --git a/hw/qdev.h b/hw/qdev.h
index 579328a..a9a98f8 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -139,6 +139,7 @@ typedef void (*qdev_resetfn)(DeviceState *dev);
 
 struct DeviceInfo {
     const char *name;
+    const char *driver_name;
     const char *alias;
     const char *desc;
     size_t size;
@@ -288,6 +289,11 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
 void qdev_prop_register_global_list(GlobalProperty *props);
 void qdev_prop_set_globals(DeviceState *dev);
 
+static inline const char *qdev_driver_name(DeviceState *dev)
+{
+    return dev->info->driver_name ? : dev->info->name;
+}
+
 /* This is a nasty hack to allow passing a NULL bus to qdev_create.  */
 extern struct BusInfo system_bus_info;
 
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 2d78ca6..b67ded6 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -769,6 +769,7 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
 static PCIDeviceInfo virtio_info[] = {
     {
         .qdev.name = "virtio-blk-pci",
+        .qdev.driver_name = "virtio-blk",
         .qdev.size = sizeof(VirtIOPCIProxy),
         .init      = virtio_blk_init_pci,
         .exit      = virtio_blk_exit_pci,
@@ -782,6 +783,7 @@ static PCIDeviceInfo virtio_info[] = {
         .qdev.reset = virtio_pci_reset,
     },{
         .qdev.name  = "virtio-net-pci",
+        .qdev.driver_name  = "ethernet",
         .qdev.size  = sizeof(VirtIOPCIProxy),
         .init       = virtio_net_init_pci,
         .exit       = virtio_net_exit_pci,
-- 
1.7.1

[Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Gleb Natapov]

Add "deriver_name" to DeviceInfo to use in device path building. In
contrast to "name" "driver_name" should refer to functionality device
provides instead of particular device model like "name" does.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/fdc.c        |    1 +
 hw/ide/isa.c    |    1 +
 hw/ide/piix.c   |    1 +
 hw/ide/qdev.c   |    1 +
 hw/isa-bus.c    |    1 +
 hw/piix_pci.c   |    2 ++
 hw/qdev.h       |    6 ++++++
 hw/virtio-pci.c |    2 ++
 8 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/hw/fdc.c b/hw/fdc.c
index c159dcb..b4217a3 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -2040,6 +2040,7 @@ static const VMStateDescription vmstate_isa_fdc ={
 static ISADeviceInfo isa_fdc_info = {
     .init = isabus_fdc_init1,
     .qdev.name  = "isa-fdc",
+    .qdev.driver_name  = "fdc",
     .qdev.size  = sizeof(FDCtrlISABus),
     .qdev.no_user = 1,
     .qdev.vmsd  = &vmstate_isa_fdc,
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 6b57e0d..489cc99 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -98,6 +98,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
 
 static ISADeviceInfo isa_ide_info = {
     .qdev.name  = "isa-ide",
+    .qdev.driver_name  = "ata",
     .qdev.size  = sizeof(ISAIDEState),
     .init       = isa_ide_initfn,
     .qdev.reset = isa_ide_reset,
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 07483e8..6206201 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -182,6 +182,7 @@ PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
 static PCIDeviceInfo piix_ide_info[] = {
     {
         .qdev.name    = "piix3-ide",
+        .qdev.driver_name    = "ata",
         .qdev.size    = sizeof(PCIIDEState),
         .qdev.no_user = 1,
         .init         = pci_piix3_ide_initfn,
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 0808760..341548e 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -134,6 +134,7 @@ static int ide_drive_initfn(IDEDevice *dev)
 
 static IDEDeviceInfo ide_drive_info = {
     .qdev.name  = "ide-drive",
+    .qdev.driver_name  = "ata-disk",
     .qdev.size  = sizeof(IDEDrive),
     .init       = ide_drive_initfn,
     .qdev.props = (Property[]) {
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 4e306de..2c42b80 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -153,6 +153,7 @@ static int isabus_bridge_init(SysBusDevice *dev)
 static SysBusDeviceInfo isabus_bridge_info = {
     .init = isabus_bridge_init,
     .qdev.name  = "isabus-bridge",
+    .qdev.driver_name  = "isa",
     .qdev.size  = sizeof(SysBusDevice),
     .qdev.no_user = 1,
 };
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 00060f3..4e5e5df 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -364,6 +364,7 @@ static PCIDeviceInfo i440fx_info[] = {
         .config_write = i440fx_write_config,
     },{
         .qdev.name    = "PIIX3",
+        .qdev.driver_name  = "pci-isa-bridge",
         .qdev.desc    = "ISA bridge",
         .qdev.size    = sizeof(PIIX3State),
         .qdev.vmsd    = &vmstate_piix3,
@@ -377,6 +378,7 @@ static PCIDeviceInfo i440fx_info[] = {
 static SysBusDeviceInfo i440fx_pcihost_info = {
     .init         = i440fx_pcihost_initfn,
     .qdev.name    = "i440FX-pcihost",
+    .qdev.driver_name = "pci",
     .qdev.size    = sizeof(I440FXState),
     .qdev.no_user = 1,
 };
diff --git a/hw/qdev.h b/hw/qdev.h
index 579328a..a9a98f8 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -139,6 +139,7 @@ typedef void (*qdev_resetfn)(DeviceState *dev);
 
 struct DeviceInfo {
     const char *name;
+    const char *driver_name;
     const char *alias;
     const char *desc;
     size_t size;
@@ -288,6 +289,11 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
 void qdev_prop_register_global_list(GlobalProperty *props);
 void qdev_prop_set_globals(DeviceState *dev);
 
+static inline const char *qdev_driver_name(DeviceState *dev)
+{
+    return dev->info->driver_name ? : dev->info->name;
+}
+
 /* This is a nasty hack to allow passing a NULL bus to qdev_create.  */
 extern struct BusInfo system_bus_info;
 
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 2d78ca6..b67ded6 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -769,6 +769,7 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
 static PCIDeviceInfo virtio_info[] = {
     {
         .qdev.name = "virtio-blk-pci",
+        .qdev.driver_name = "virtio-blk",
         .qdev.size = sizeof(VirtIOPCIProxy),
         .init      = virtio_blk_init_pci,
         .exit      = virtio_blk_exit_pci,
@@ -782,6 +783,7 @@ static PCIDeviceInfo virtio_info[] = {
         .qdev.reset = virtio_pci_reset,
     },{
         .qdev.name  = "virtio-net-pci",
+        .qdev.driver_name  = "ethernet",
         .qdev.size  = sizeof(VirtIOPCIProxy),
         .init       = virtio_net_init_pci,
         .exit       = virtio_net_exit_pci,
-- 
1.7.1

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> Add "deriver_name" to DeviceInfo to use in device path building. In

Typo "deriver".  Same in subject.

> contrast to "name" "driver_name" should refer to functionality device
> provides instead of particular device model like "name" does.

Why is that useful in a device path?

I'm afraid "driver_name" is too confusing, because we already use
"driver" and "name" for the name of the device model: DeviceInfo member
name, and qemu_device_opts option name "driver".

Perhaps something like "class"?

> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  hw/fdc.c        |    1 +
>  hw/ide/isa.c    |    1 +
>  hw/ide/piix.c   |    1 +
>  hw/ide/qdev.c   |    1 +
>  hw/isa-bus.c    |    1 +
>  hw/piix_pci.c   |    2 ++
>  hw/qdev.h       |    6 ++++++
>  hw/virtio-pci.c |    2 ++
>  8 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/hw/fdc.c b/hw/fdc.c
> index c159dcb..b4217a3 100644
> --- a/hw/fdc.c
> +++ b/hw/fdc.c
> @@ -2040,6 +2040,7 @@ static const VMStateDescription vmstate_isa_fdc ={
>  static ISADeviceInfo isa_fdc_info = {
>      .init = isabus_fdc_init1,
>      .qdev.name  = "isa-fdc",
> +    .qdev.driver_name  = "fdc",
>      .qdev.size  = sizeof(FDCtrlISABus),
>      .qdev.no_user = 1,
>      .qdev.vmsd  = &vmstate_isa_fdc,
> diff --git a/hw/ide/isa.c b/hw/ide/isa.c
> index 6b57e0d..489cc99 100644
> --- a/hw/ide/isa.c
> +++ b/hw/ide/isa.c
> @@ -98,6 +98,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
>  
>  static ISADeviceInfo isa_ide_info = {
>      .qdev.name  = "isa-ide",
> +    .qdev.driver_name  = "ata",
>      .qdev.size  = sizeof(ISAIDEState),
>      .init       = isa_ide_initfn,
>      .qdev.reset = isa_ide_reset,
> diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> index 07483e8..6206201 100644
> --- a/hw/ide/piix.c
> +++ b/hw/ide/piix.c
> @@ -182,6 +182,7 @@ PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
>  static PCIDeviceInfo piix_ide_info[] = {
>      {
>          .qdev.name    = "piix3-ide",
> +        .qdev.driver_name    = "ata",
>          .qdev.size    = sizeof(PCIIDEState),
>          .qdev.no_user = 1,
>          .init         = pci_piix3_ide_initfn,
> diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> index 0808760..341548e 100644
> --- a/hw/ide/qdev.c
> +++ b/hw/ide/qdev.c
> @@ -134,6 +134,7 @@ static int ide_drive_initfn(IDEDevice *dev)
>  
>  static IDEDeviceInfo ide_drive_info = {
>      .qdev.name  = "ide-drive",
> +    .qdev.driver_name  = "ata-disk",
>      .qdev.size  = sizeof(IDEDrive),
>      .init       = ide_drive_initfn,
>      .qdev.props = (Property[]) {

"ata-disk" is misleading, as it doesn't have to be a disk.  "ata-drive"?
Hmm, can't we stick to "ide-drive" just as well?

> diff --git a/hw/isa-bus.c b/hw/isa-bus.c
> index 4e306de..2c42b80 100644
> --- a/hw/isa-bus.c
> +++ b/hw/isa-bus.c
> @@ -153,6 +153,7 @@ static int isabus_bridge_init(SysBusDevice *dev)
>  static SysBusDeviceInfo isabus_bridge_info = {
>      .init = isabus_bridge_init,
>      .qdev.name  = "isabus-bridge",
> +    .qdev.driver_name  = "isa",
>      .qdev.size  = sizeof(SysBusDevice),
>      .qdev.no_user = 1,
>  };
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 00060f3..4e5e5df 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -364,6 +364,7 @@ static PCIDeviceInfo i440fx_info[] = {
>          .config_write = i440fx_write_config,
>      },{
>          .qdev.name    = "PIIX3",
> +        .qdev.driver_name  = "pci-isa-bridge",
>          .qdev.desc    = "ISA bridge",
>          .qdev.size    = sizeof(PIIX3State),
>          .qdev.vmsd    = &vmstate_piix3,
> @@ -377,6 +378,7 @@ static PCIDeviceInfo i440fx_info[] = {
>  static SysBusDeviceInfo i440fx_pcihost_info = {
>      .init         = i440fx_pcihost_initfn,
>      .qdev.name    = "i440FX-pcihost",
> +    .qdev.driver_name = "pci",
>      .qdev.size    = sizeof(I440FXState),
>      .qdev.no_user = 1,
>  };
> diff --git a/hw/qdev.h b/hw/qdev.h
> index 579328a..a9a98f8 100644
> --- a/hw/qdev.h
> +++ b/hw/qdev.h
> @@ -139,6 +139,7 @@ typedef void (*qdev_resetfn)(DeviceState *dev);
>  
>  struct DeviceInfo {
>      const char *name;
> +    const char *driver_name;
>      const char *alias;
>      const char *desc;
>      size_t size;
> @@ -288,6 +289,11 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
>  void qdev_prop_register_global_list(GlobalProperty *props);
>  void qdev_prop_set_globals(DeviceState *dev);
>  
> +static inline const char *qdev_driver_name(DeviceState *dev)
> +{
> +    return dev->info->driver_name ? : dev->info->name;
> +}
> +

Aha, it defaults to the device model name dev->info->name.  That's why
you get away with not defining it in most DeviceInfo.

>  /* This is a nasty hack to allow passing a NULL bus to qdev_create.  */
>  extern struct BusInfo system_bus_info;
>  
> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> index 2d78ca6..b67ded6 100644
> --- a/hw/virtio-pci.c
> +++ b/hw/virtio-pci.c
> @@ -769,6 +769,7 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
>  static PCIDeviceInfo virtio_info[] = {
>      {
>          .qdev.name = "virtio-blk-pci",
> +        .qdev.driver_name = "virtio-blk",
>          .qdev.size = sizeof(VirtIOPCIProxy),
>          .init      = virtio_blk_init_pci,
>          .exit      = virtio_blk_exit_pci,
> @@ -782,6 +783,7 @@ static PCIDeviceInfo virtio_info[] = {
>          .qdev.reset = virtio_pci_reset,
>      },{
>          .qdev.name  = "virtio-net-pci",
> +        .qdev.driver_name  = "ethernet",
>          .qdev.size  = sizeof(VirtIOPCIProxy),
>          .init       = virtio_net_init_pci,
>          .exit       = virtio_net_exit_pci,

Do we want a free-for-all ad hoc set of values for driver_name?  The
values become ABI instantly...  Can we adopt some existing set of names
for device classes?  Else, can we define our own with a bit more
control?

Note that a single device could implement more than one device class.  I
guess a sane PCI device would do that with a separate function each, so
we'd be fine there.  Do we want to hardcode "single class per qdev"?

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> Add "deriver_name" to DeviceInfo to use in device path building. In

Typo "deriver".  Same in subject.

> contrast to "name" "driver_name" should refer to functionality device
> provides instead of particular device model like "name" does.

Why is that useful in a device path?

I'm afraid "driver_name" is too confusing, because we already use
"driver" and "name" for the name of the device model: DeviceInfo member
name, and qemu_device_opts option name "driver".

Perhaps something like "class"?

> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  hw/fdc.c        |    1 +
>  hw/ide/isa.c    |    1 +
>  hw/ide/piix.c   |    1 +
>  hw/ide/qdev.c   |    1 +
>  hw/isa-bus.c    |    1 +
>  hw/piix_pci.c   |    2 ++
>  hw/qdev.h       |    6 ++++++
>  hw/virtio-pci.c |    2 ++
>  8 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/hw/fdc.c b/hw/fdc.c
> index c159dcb..b4217a3 100644
> --- a/hw/fdc.c
> +++ b/hw/fdc.c
> @@ -2040,6 +2040,7 @@ static const VMStateDescription vmstate_isa_fdc ={
>  static ISADeviceInfo isa_fdc_info = {
>      .init = isabus_fdc_init1,
>      .qdev.name  = "isa-fdc",
> +    .qdev.driver_name  = "fdc",
>      .qdev.size  = sizeof(FDCtrlISABus),
>      .qdev.no_user = 1,
>      .qdev.vmsd  = &vmstate_isa_fdc,
> diff --git a/hw/ide/isa.c b/hw/ide/isa.c
> index 6b57e0d..489cc99 100644
> --- a/hw/ide/isa.c
> +++ b/hw/ide/isa.c
> @@ -98,6 +98,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
>  
>  static ISADeviceInfo isa_ide_info = {
>      .qdev.name  = "isa-ide",
> +    .qdev.driver_name  = "ata",
>      .qdev.size  = sizeof(ISAIDEState),
>      .init       = isa_ide_initfn,
>      .qdev.reset = isa_ide_reset,
> diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> index 07483e8..6206201 100644
> --- a/hw/ide/piix.c
> +++ b/hw/ide/piix.c
> @@ -182,6 +182,7 @@ PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
>  static PCIDeviceInfo piix_ide_info[] = {
>      {
>          .qdev.name    = "piix3-ide",
> +        .qdev.driver_name    = "ata",
>          .qdev.size    = sizeof(PCIIDEState),
>          .qdev.no_user = 1,
>          .init         = pci_piix3_ide_initfn,
> diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> index 0808760..341548e 100644
> --- a/hw/ide/qdev.c
> +++ b/hw/ide/qdev.c
> @@ -134,6 +134,7 @@ static int ide_drive_initfn(IDEDevice *dev)
>  
>  static IDEDeviceInfo ide_drive_info = {
>      .qdev.name  = "ide-drive",
> +    .qdev.driver_name  = "ata-disk",
>      .qdev.size  = sizeof(IDEDrive),
>      .init       = ide_drive_initfn,
>      .qdev.props = (Property[]) {

"ata-disk" is misleading, as it doesn't have to be a disk.  "ata-drive"?
Hmm, can't we stick to "ide-drive" just as well?

> diff --git a/hw/isa-bus.c b/hw/isa-bus.c
> index 4e306de..2c42b80 100644
> --- a/hw/isa-bus.c
> +++ b/hw/isa-bus.c
> @@ -153,6 +153,7 @@ static int isabus_bridge_init(SysBusDevice *dev)
>  static SysBusDeviceInfo isabus_bridge_info = {
>      .init = isabus_bridge_init,
>      .qdev.name  = "isabus-bridge",
> +    .qdev.driver_name  = "isa",
>      .qdev.size  = sizeof(SysBusDevice),
>      .qdev.no_user = 1,
>  };
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 00060f3..4e5e5df 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -364,6 +364,7 @@ static PCIDeviceInfo i440fx_info[] = {
>          .config_write = i440fx_write_config,
>      },{
>          .qdev.name    = "PIIX3",
> +        .qdev.driver_name  = "pci-isa-bridge",
>          .qdev.desc    = "ISA bridge",
>          .qdev.size    = sizeof(PIIX3State),
>          .qdev.vmsd    = &vmstate_piix3,
> @@ -377,6 +378,7 @@ static PCIDeviceInfo i440fx_info[] = {
>  static SysBusDeviceInfo i440fx_pcihost_info = {
>      .init         = i440fx_pcihost_initfn,
>      .qdev.name    = "i440FX-pcihost",
> +    .qdev.driver_name = "pci",
>      .qdev.size    = sizeof(I440FXState),
>      .qdev.no_user = 1,
>  };
> diff --git a/hw/qdev.h b/hw/qdev.h
> index 579328a..a9a98f8 100644
> --- a/hw/qdev.h
> +++ b/hw/qdev.h
> @@ -139,6 +139,7 @@ typedef void (*qdev_resetfn)(DeviceState *dev);
>  
>  struct DeviceInfo {
>      const char *name;
> +    const char *driver_name;
>      const char *alias;
>      const char *desc;
>      size_t size;
> @@ -288,6 +289,11 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
>  void qdev_prop_register_global_list(GlobalProperty *props);
>  void qdev_prop_set_globals(DeviceState *dev);
>  
> +static inline const char *qdev_driver_name(DeviceState *dev)
> +{
> +    return dev->info->driver_name ? : dev->info->name;
> +}
> +

Aha, it defaults to the device model name dev->info->name.  That's why
you get away with not defining it in most DeviceInfo.

>  /* This is a nasty hack to allow passing a NULL bus to qdev_create.  */
>  extern struct BusInfo system_bus_info;
>  
> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> index 2d78ca6..b67ded6 100644
> --- a/hw/virtio-pci.c
> +++ b/hw/virtio-pci.c
> @@ -769,6 +769,7 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
>  static PCIDeviceInfo virtio_info[] = {
>      {
>          .qdev.name = "virtio-blk-pci",
> +        .qdev.driver_name = "virtio-blk",
>          .qdev.size = sizeof(VirtIOPCIProxy),
>          .init      = virtio_blk_init_pci,
>          .exit      = virtio_blk_exit_pci,
> @@ -782,6 +783,7 @@ static PCIDeviceInfo virtio_info[] = {
>          .qdev.reset = virtio_pci_reset,
>      },{
>          .qdev.name  = "virtio-net-pci",
> +        .qdev.driver_name  = "ethernet",
>          .qdev.size  = sizeof(VirtIOPCIProxy),
>          .init       = virtio_net_init_pci,
>          .exit       = virtio_net_exit_pci,

Do we want a free-for-all ad hoc set of values for driver_name?  The
values become ABI instantly...  Can we adopt some existing set of names
for device classes?  Else, can we define our own with a bit more
control?

Note that a single device could implement more than one device class.  I
guess a sane PCI device would do that with a separate function each, so
we'd be fine there.  Do we want to hardcode "single class per qdev"?

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Gleb Natapov]

On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > Add "deriver_name" to DeviceInfo to use in device path building. In
> 
> Typo "deriver".  Same in subject.
> 
Heh.

> > contrast to "name" "driver_name" should refer to functionality device
> > provides instead of particular device model like "name" does.
> 
> Why is that useful in a device path?
> 
Sometimes it is sometimes it is not. Lets look at path like that:
/pci@i0cf8/ethernet@4/ethernet-phy@0

It is important to have pci in the fist path element since it defines
what kind of bus addressing is used by next element ethernet@4. 4 is
slot number in case of pci bus. On the other hand ethernet part is not
important since OS can figure it out by looking in pci config space.

> I'm afraid "driver_name" is too confusing, because we already use
> "driver" and "name" for the name of the device model: DeviceInfo member
> name, and qemu_device_opts option name "driver".
I use "driver_name" here since I am coding to Open Firmware spec now
and this element in device path is called driver_name by the spec.

> 
> Perhaps something like "class"?
> 
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > ---
> >  hw/fdc.c        |    1 +
> >  hw/ide/isa.c    |    1 +
> >  hw/ide/piix.c   |    1 +
> >  hw/ide/qdev.c   |    1 +
> >  hw/isa-bus.c    |    1 +
> >  hw/piix_pci.c   |    2 ++
> >  hw/qdev.h       |    6 ++++++
> >  hw/virtio-pci.c |    2 ++
> >  8 files changed, 15 insertions(+), 0 deletions(-)
> >
> > diff --git a/hw/fdc.c b/hw/fdc.c
> > index c159dcb..b4217a3 100644
> > --- a/hw/fdc.c
> > +++ b/hw/fdc.c
> > @@ -2040,6 +2040,7 @@ static const VMStateDescription vmstate_isa_fdc ={
> >  static ISADeviceInfo isa_fdc_info = {
> >      .init = isabus_fdc_init1,
> >      .qdev.name  = "isa-fdc",
> > +    .qdev.driver_name  = "fdc",
> >      .qdev.size  = sizeof(FDCtrlISABus),
> >      .qdev.no_user = 1,
> >      .qdev.vmsd  = &vmstate_isa_fdc,
> > diff --git a/hw/ide/isa.c b/hw/ide/isa.c
> > index 6b57e0d..489cc99 100644
> > --- a/hw/ide/isa.c
> > +++ b/hw/ide/isa.c
> > @@ -98,6 +98,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
> >  
> >  static ISADeviceInfo isa_ide_info = {
> >      .qdev.name  = "isa-ide",
> > +    .qdev.driver_name  = "ata",
> >      .qdev.size  = sizeof(ISAIDEState),
> >      .init       = isa_ide_initfn,
> >      .qdev.reset = isa_ide_reset,
> > diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> > index 07483e8..6206201 100644
> > --- a/hw/ide/piix.c
> > +++ b/hw/ide/piix.c
> > @@ -182,6 +182,7 @@ PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
> >  static PCIDeviceInfo piix_ide_info[] = {
> >      {
> >          .qdev.name    = "piix3-ide",
> > +        .qdev.driver_name    = "ata",
> >          .qdev.size    = sizeof(PCIIDEState),
> >          .qdev.no_user = 1,
> >          .init         = pci_piix3_ide_initfn,
> > diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> > index 0808760..341548e 100644
> > --- a/hw/ide/qdev.c
> > +++ b/hw/ide/qdev.c
> > @@ -134,6 +134,7 @@ static int ide_drive_initfn(IDEDevice *dev)
> >  
> >  static IDEDeviceInfo ide_drive_info = {
> >      .qdev.name  = "ide-drive",
> > +    .qdev.driver_name  = "ata-disk",
> >      .qdev.size  = sizeof(IDEDrive),
> >      .init       = ide_drive_initfn,
> >      .qdev.props = (Property[]) {
> 
> "ata-disk" is misleading, as it doesn't have to be a disk.  "ata-drive"?
> Hmm, can't we stick to "ide-drive" just as well?
> 
IIRC I changed this to just "disk" already.

> > diff --git a/hw/isa-bus.c b/hw/isa-bus.c
> > index 4e306de..2c42b80 100644
> > --- a/hw/isa-bus.c
> > +++ b/hw/isa-bus.c
> > @@ -153,6 +153,7 @@ static int isabus_bridge_init(SysBusDevice *dev)
> >  static SysBusDeviceInfo isabus_bridge_info = {
> >      .init = isabus_bridge_init,
> >      .qdev.name  = "isabus-bridge",
> > +    .qdev.driver_name  = "isa",
> >      .qdev.size  = sizeof(SysBusDevice),
> >      .qdev.no_user = 1,
> >  };
> > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > index 00060f3..4e5e5df 100644
> > --- a/hw/piix_pci.c
> > +++ b/hw/piix_pci.c
> > @@ -364,6 +364,7 @@ static PCIDeviceInfo i440fx_info[] = {
> >          .config_write = i440fx_write_config,
> >      },{
> >          .qdev.name    = "PIIX3",
> > +        .qdev.driver_name  = "pci-isa-bridge",
> >          .qdev.desc    = "ISA bridge",
> >          .qdev.size    = sizeof(PIIX3State),
> >          .qdev.vmsd    = &vmstate_piix3,
> > @@ -377,6 +378,7 @@ static PCIDeviceInfo i440fx_info[] = {
> >  static SysBusDeviceInfo i440fx_pcihost_info = {
> >      .init         = i440fx_pcihost_initfn,
> >      .qdev.name    = "i440FX-pcihost",
> > +    .qdev.driver_name = "pci",
> >      .qdev.size    = sizeof(I440FXState),
> >      .qdev.no_user = 1,
> >  };
> > diff --git a/hw/qdev.h b/hw/qdev.h
> > index 579328a..a9a98f8 100644
> > --- a/hw/qdev.h
> > +++ b/hw/qdev.h
> > @@ -139,6 +139,7 @@ typedef void (*qdev_resetfn)(DeviceState *dev);
> >  
> >  struct DeviceInfo {
> >      const char *name;
> > +    const char *driver_name;
> >      const char *alias;
> >      const char *desc;
> >      size_t size;
> > @@ -288,6 +289,11 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
> >  void qdev_prop_register_global_list(GlobalProperty *props);
> >  void qdev_prop_set_globals(DeviceState *dev);
> >  
> > +static inline const char *qdev_driver_name(DeviceState *dev)
> > +{
> > +    return dev->info->driver_name ? : dev->info->name;
> > +}
> > +
> 
> Aha, it defaults to the device model name dev->info->name.  That's why
> you get away with not defining it in most DeviceInfo.
> 
> >  /* This is a nasty hack to allow passing a NULL bus to qdev_create.  */
> >  extern struct BusInfo system_bus_info;
> >  
> > diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> > index 2d78ca6..b67ded6 100644
> > --- a/hw/virtio-pci.c
> > +++ b/hw/virtio-pci.c
> > @@ -769,6 +769,7 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
> >  static PCIDeviceInfo virtio_info[] = {
> >      {
> >          .qdev.name = "virtio-blk-pci",
> > +        .qdev.driver_name = "virtio-blk",
> >          .qdev.size = sizeof(VirtIOPCIProxy),
> >          .init      = virtio_blk_init_pci,
> >          .exit      = virtio_blk_exit_pci,
> > @@ -782,6 +783,7 @@ static PCIDeviceInfo virtio_info[] = {
> >          .qdev.reset = virtio_pci_reset,
> >      },{
> >          .qdev.name  = "virtio-net-pci",
> > +        .qdev.driver_name  = "ethernet",
> >          .qdev.size  = sizeof(VirtIOPCIProxy),
> >          .init       = virtio_net_init_pci,
> >          .exit       = virtio_net_exit_pci,
> 
> Do we want a free-for-all ad hoc set of values for driver_name?  The
> values become ABI instantly...  Can we adopt some existing set of names
> for device classes?  Else, can we define our own with a bit more
> control?
> 
I am open to suggestion. Open firmware describes this field as:

  The driver name field is a sequence of between one and 31 letters, digits,
  and punctuation characters from the set “, . _ + - ”. Uppercase and
  lowercase characters are distinct. By convention, this name includes
  the name of the device’s manufacturer and the device’s model name
  separated by a “,”.  (See the definition of “name” in annex A.)
  Inclusion of the manufacturer name within driver name is especially
  important for devices intended to plug into standard buses, as this
  minimizes the risk of accidental name collisions. It is somewhat less
  important for devices that are permanently attached to a particular
  system.  If the manufacturer name component is omitted (i.e., there is
  no “,” within the driver name), the convention is to assume that
  the manufacturer name is the same as that of the nearest ancestor node
  (parent node, or grandparent node, etc.) that has an explicit manufacturer
  name component.


I am looking on existing implementations an copy what they do.

> Note that a single device could implement more than one device class.  I
> guess a sane PCI device would do that with a separate function each, so
> we'd be fine there.  Do we want to hardcode "single class per qdev"?
Isn't it already the case?

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Gleb Natapov]

On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > Add "deriver_name" to DeviceInfo to use in device path building. In
> 
> Typo "deriver".  Same in subject.
> 
Heh.

> > contrast to "name" "driver_name" should refer to functionality device
> > provides instead of particular device model like "name" does.
> 
> Why is that useful in a device path?
> 
Sometimes it is sometimes it is not. Lets look at path like that:
/pci@i0cf8/ethernet@4/ethernet-phy@0

It is important to have pci in the fist path element since it defines
what kind of bus addressing is used by next element ethernet@4. 4 is
slot number in case of pci bus. On the other hand ethernet part is not
important since OS can figure it out by looking in pci config space.

> I'm afraid "driver_name" is too confusing, because we already use
> "driver" and "name" for the name of the device model: DeviceInfo member
> name, and qemu_device_opts option name "driver".
I use "driver_name" here since I am coding to Open Firmware spec now
and this element in device path is called driver_name by the spec.

> 
> Perhaps something like "class"?
> 
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > ---
> >  hw/fdc.c        |    1 +
> >  hw/ide/isa.c    |    1 +
> >  hw/ide/piix.c   |    1 +
> >  hw/ide/qdev.c   |    1 +
> >  hw/isa-bus.c    |    1 +
> >  hw/piix_pci.c   |    2 ++
> >  hw/qdev.h       |    6 ++++++
> >  hw/virtio-pci.c |    2 ++
> >  8 files changed, 15 insertions(+), 0 deletions(-)
> >
> > diff --git a/hw/fdc.c b/hw/fdc.c
> > index c159dcb..b4217a3 100644
> > --- a/hw/fdc.c
> > +++ b/hw/fdc.c
> > @@ -2040,6 +2040,7 @@ static const VMStateDescription vmstate_isa_fdc ={
> >  static ISADeviceInfo isa_fdc_info = {
> >      .init = isabus_fdc_init1,
> >      .qdev.name  = "isa-fdc",
> > +    .qdev.driver_name  = "fdc",
> >      .qdev.size  = sizeof(FDCtrlISABus),
> >      .qdev.no_user = 1,
> >      .qdev.vmsd  = &vmstate_isa_fdc,
> > diff --git a/hw/ide/isa.c b/hw/ide/isa.c
> > index 6b57e0d..489cc99 100644
> > --- a/hw/ide/isa.c
> > +++ b/hw/ide/isa.c
> > @@ -98,6 +98,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
> >  
> >  static ISADeviceInfo isa_ide_info = {
> >      .qdev.name  = "isa-ide",
> > +    .qdev.driver_name  = "ata",
> >      .qdev.size  = sizeof(ISAIDEState),
> >      .init       = isa_ide_initfn,
> >      .qdev.reset = isa_ide_reset,
> > diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> > index 07483e8..6206201 100644
> > --- a/hw/ide/piix.c
> > +++ b/hw/ide/piix.c
> > @@ -182,6 +182,7 @@ PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
> >  static PCIDeviceInfo piix_ide_info[] = {
> >      {
> >          .qdev.name    = "piix3-ide",
> > +        .qdev.driver_name    = "ata",
> >          .qdev.size    = sizeof(PCIIDEState),
> >          .qdev.no_user = 1,
> >          .init         = pci_piix3_ide_initfn,
> > diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> > index 0808760..341548e 100644
> > --- a/hw/ide/qdev.c
> > +++ b/hw/ide/qdev.c
> > @@ -134,6 +134,7 @@ static int ide_drive_initfn(IDEDevice *dev)
> >  
> >  static IDEDeviceInfo ide_drive_info = {
> >      .qdev.name  = "ide-drive",
> > +    .qdev.driver_name  = "ata-disk",
> >      .qdev.size  = sizeof(IDEDrive),
> >      .init       = ide_drive_initfn,
> >      .qdev.props = (Property[]) {
> 
> "ata-disk" is misleading, as it doesn't have to be a disk.  "ata-drive"?
> Hmm, can't we stick to "ide-drive" just as well?
> 
IIRC I changed this to just "disk" already.

> > diff --git a/hw/isa-bus.c b/hw/isa-bus.c
> > index 4e306de..2c42b80 100644
> > --- a/hw/isa-bus.c
> > +++ b/hw/isa-bus.c
> > @@ -153,6 +153,7 @@ static int isabus_bridge_init(SysBusDevice *dev)
> >  static SysBusDeviceInfo isabus_bridge_info = {
> >      .init = isabus_bridge_init,
> >      .qdev.name  = "isabus-bridge",
> > +    .qdev.driver_name  = "isa",
> >      .qdev.size  = sizeof(SysBusDevice),
> >      .qdev.no_user = 1,
> >  };
> > diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> > index 00060f3..4e5e5df 100644
> > --- a/hw/piix_pci.c
> > +++ b/hw/piix_pci.c
> > @@ -364,6 +364,7 @@ static PCIDeviceInfo i440fx_info[] = {
> >          .config_write = i440fx_write_config,
> >      },{
> >          .qdev.name    = "PIIX3",
> > +        .qdev.driver_name  = "pci-isa-bridge",
> >          .qdev.desc    = "ISA bridge",
> >          .qdev.size    = sizeof(PIIX3State),
> >          .qdev.vmsd    = &vmstate_piix3,
> > @@ -377,6 +378,7 @@ static PCIDeviceInfo i440fx_info[] = {
> >  static SysBusDeviceInfo i440fx_pcihost_info = {
> >      .init         = i440fx_pcihost_initfn,
> >      .qdev.name    = "i440FX-pcihost",
> > +    .qdev.driver_name = "pci",
> >      .qdev.size    = sizeof(I440FXState),
> >      .qdev.no_user = 1,
> >  };
> > diff --git a/hw/qdev.h b/hw/qdev.h
> > index 579328a..a9a98f8 100644
> > --- a/hw/qdev.h
> > +++ b/hw/qdev.h
> > @@ -139,6 +139,7 @@ typedef void (*qdev_resetfn)(DeviceState *dev);
> >  
> >  struct DeviceInfo {
> >      const char *name;
> > +    const char *driver_name;
> >      const char *alias;
> >      const char *desc;
> >      size_t size;
> > @@ -288,6 +289,11 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
> >  void qdev_prop_register_global_list(GlobalProperty *props);
> >  void qdev_prop_set_globals(DeviceState *dev);
> >  
> > +static inline const char *qdev_driver_name(DeviceState *dev)
> > +{
> > +    return dev->info->driver_name ? : dev->info->name;
> > +}
> > +
> 
> Aha, it defaults to the device model name dev->info->name.  That's why
> you get away with not defining it in most DeviceInfo.
> 
> >  /* This is a nasty hack to allow passing a NULL bus to qdev_create.  */
> >  extern struct BusInfo system_bus_info;
> >  
> > diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> > index 2d78ca6..b67ded6 100644
> > --- a/hw/virtio-pci.c
> > +++ b/hw/virtio-pci.c
> > @@ -769,6 +769,7 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
> >  static PCIDeviceInfo virtio_info[] = {
> >      {
> >          .qdev.name = "virtio-blk-pci",
> > +        .qdev.driver_name = "virtio-blk",
> >          .qdev.size = sizeof(VirtIOPCIProxy),
> >          .init      = virtio_blk_init_pci,
> >          .exit      = virtio_blk_exit_pci,
> > @@ -782,6 +783,7 @@ static PCIDeviceInfo virtio_info[] = {
> >          .qdev.reset = virtio_pci_reset,
> >      },{
> >          .qdev.name  = "virtio-net-pci",
> > +        .qdev.driver_name  = "ethernet",
> >          .qdev.size  = sizeof(VirtIOPCIProxy),
> >          .init       = virtio_net_init_pci,
> >          .exit       = virtio_net_exit_pci,
> 
> Do we want a free-for-all ad hoc set of values for driver_name?  The
> values become ABI instantly...  Can we adopt some existing set of names
> for device classes?  Else, can we define our own with a bit more
> control?
> 
I am open to suggestion. Open firmware describes this field as:

  The driver name field is a sequence of between one and 31 letters, digits,
  and punctuation characters from the set “, . _ + - ”. Uppercase and
  lowercase characters are distinct. By convention, this name includes
  the name of the device’s manufacturer and the device’s model name
  separated by a “,”.  (See the definition of “name” in annex A.)
  Inclusion of the manufacturer name within driver name is especially
  important for devices intended to plug into standard buses, as this
  minimizes the risk of accidental name collisions. It is somewhat less
  important for devices that are permanently attached to a particular
  system.  If the manufacturer name component is omitted (i.e., there is
  no “,” within the driver name), the convention is to assume that
  the manufacturer name is the same as that of the nearest ancestor node
  (parent node, or grandparent node, etc.) that has an explicit manufacturer
  name component.


I am looking on existing implementations an copy what they do.

> Note that a single device could implement more than one device class.  I
> guess a sane PCI device would do that with a separate function each, so
> we'd be fine there.  Do we want to hardcode "single class per qdev"?
Isn't it already the case?

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > Add "deriver_name" to DeviceInfo to use in device path building. In
>> 
>> Typo "deriver".  Same in subject.
>> 
> Heh.
>
>> > contrast to "name" "driver_name" should refer to functionality device
>> > provides instead of particular device model like "name" does.
>> 
>> Why is that useful in a device path?
>> 
> Sometimes it is sometimes it is not. Lets look at path like that:
> /pci@i0cf8/ethernet@4/ethernet-phy@0
>
> It is important to have pci in the fist path element since it defines
> what kind of bus addressing is used by next element ethernet@4.

It is for consumers that don't know what's sitting at i0cf8 on the
system bus.

>                                                                 4 is
> slot number in case of pci bus. On the other hand ethernet part is not
> important since OS can figure it out by looking in pci config space.

The OS does know what's sitting in slot 4 on the PCI bus.

If the OS number doesn't know what's sitting at i0cf8, why is "pci"
sufficient information?  Why don't we have to distinguish between the
different PCI host bridges?

>> I'm afraid "driver_name" is too confusing, because we already use
>> "driver" and "name" for the name of the device model: DeviceInfo member
>> name, and qemu_device_opts option name "driver".
> I use "driver_name" here since I am coding to Open Firmware spec now
> and this element in device path is called driver_name by the spec.

Why is it different from our DeviceInfo member name?

We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
need a third?

Do you envisage different device models sharing the same driver_name?

[...]
>> Do we want a free-for-all ad hoc set of values for driver_name?  The
>> values become ABI instantly...  Can we adopt some existing set of names
>> for device classes?  Else, can we define our own with a bit more
>> control?
>> 
> I am open to suggestion. Open firmware describes this field as:
>
>   The driver name field is a sequence of between one and 31 letters, digits,
>   and punctuation characters from the set “, . _ + - ”. Uppercase and
>   lowercase characters are distinct. By convention, this name includes
>   the name of the device’s manufacturer and the device’s model name
>   separated by a “,”.  (See the definition of “name” in annex A.)
>   Inclusion of the manufacturer name within driver name is especially
>   important for devices intended to plug into standard buses, as this
>   minimizes the risk of accidental name collisions. It is somewhat less
>   important for devices that are permanently attached to a particular
>   system.  If the manufacturer name component is omitted (i.e., there is
>   no “,” within the driver name), the convention is to assume that
>   the manufacturer name is the same as that of the nearest ancestor node
>   (parent node, or grandparent node, etc.) that has an explicit manufacturer
>   name component.

I suspect that's exactly what DeviceInfo member name is.

> I am looking on existing implementations an copy what they do.
[...]

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Gleb Natapov]

On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
> >> Gleb Natapov <gleb@redhat.com> writes:
> >> 
> >> > Add "deriver_name" to DeviceInfo to use in device path building. In
> >> 
> >> Typo "deriver".  Same in subject.
> >> 
> > Heh.
> >
> >> > contrast to "name" "driver_name" should refer to functionality device
> >> > provides instead of particular device model like "name" does.
> >> 
> >> Why is that useful in a device path?
> >> 
> > Sometimes it is sometimes it is not. Lets look at path like that:
> > /pci@i0cf8/ethernet@4/ethernet-phy@0
> >
> > It is important to have pci in the fist path element since it defines
> > what kind of bus addressing is used by next element ethernet@4.
> 
> It is for consumers that don't know what's sitting at i0cf8 on the
> system bus.
Yes. Same firmware may support different boards that have same pci
controller but on different addresses. Device name may even contain
manufacturer ID, so firmware will be able to find matching driver and
support more board without recompiling.


> 
> >                                                                 4 is
> > slot number in case of pci bus. On the other hand ethernet part is not
> > important since OS can figure it out by looking in pci config space.
> 
> The OS does know what's sitting in slot 4 on the PCI bus.
> 
Yes, and? That what I wrote above. "ethernet" part is redundant in case
of PCI bus. A little bit of redundancy will not hurt and required by the
spec.

> If the OS number doesn't know what's sitting at i0cf8, why is "pci"
> sufficient information?  Why don't we have to distinguish between the
> different PCI host bridges?
Manufacturer ID may be put along with pci. Full FDT contains much more
information about each node though. It may even list compatible HW. Here
we are concerned with device paths only.

> 
> >> I'm afraid "driver_name" is too confusing, because we already use
> >> "driver" and "name" for the name of the device model: DeviceInfo member
> >> name, and qemu_device_opts option name "driver".
> > I use "driver_name" here since I am coding to Open Firmware spec now
> > and this element in device path is called driver_name by the spec.
> 
> Why is it different from our DeviceInfo member name?
> 
> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
> need a third?
I haven't noticed we have alias! What is it used for? I think I can use
it instead.

> 
> Do you envisage different device models sharing the same driver_name?
> 
Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.

> [...]
> >> Do we want a free-for-all ad hoc set of values for driver_name?  The
> >> values become ABI instantly...  Can we adopt some existing set of names
> >> for device classes?  Else, can we define our own with a bit more
> >> control?
> >> 
> > I am open to suggestion. Open firmware describes this field as:
> >
> >   The driver name field is a sequence of between one and 31 letters, digits,
> >   and punctuation characters from the set “, . _ + - ”. Uppercase and
> >   lowercase characters are distinct. By convention, this name includes
> >   the name of the device’s manufacturer and the device’s model name
> >   separated by a “,”.  (See the definition of “name” in annex A.)
> >   Inclusion of the manufacturer name within driver name is especially
> >   important for devices intended to plug into standard buses, as this
> >   minimizes the risk of accidental name collisions. It is somewhat less
> >   important for devices that are permanently attached to a particular
> >   system.  If the manufacturer name component is omitted (i.e., there is
> >   no “,” within the driver name), the convention is to assume that
> >   the manufacturer name is the same as that of the nearest ancestor node
> >   (parent node, or grandparent node, etc.) that has an explicit manufacturer
> >   name component.
> 
> I suspect that's exactly what DeviceInfo member name is.
> 
In cases where this is the case I just use "name".

> > I am looking on existing implementations an copy what they do.
> [...]

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> >> Gleb Natapov <gleb@redhat.com> writes:
>> >> 
>> >> > Add "deriver_name" to DeviceInfo to use in device path building. In
>> >> 
>> >> Typo "deriver".  Same in subject.
>> >> 
>> > Heh.
>> >
>> >> > contrast to "name" "driver_name" should refer to functionality device
>> >> > provides instead of particular device model like "name" does.
>> >> 
>> >> Why is that useful in a device path?
>> >> 
>> > Sometimes it is sometimes it is not. Lets look at path like that:
>> > /pci@i0cf8/ethernet@4/ethernet-phy@0
>> >
>> > It is important to have pci in the fist path element since it defines
>> > what kind of bus addressing is used by next element ethernet@4.
>> 
>> It is for consumers that don't know what's sitting at i0cf8 on the
>> system bus.
> Yes. Same firmware may support different boards that have same pci
> controller but on different addresses. Device name may even contain
> manufacturer ID, so firmware will be able to find matching driver and
> support more board without recompiling.

"pci" tells us it's some kind of PCI host bridge.  Why is that enough?
Why don't we have to identify the particular host bridge, such as
"i440FX-pcihost"?

>> >                                                                 4 is
>> > slot number in case of pci bus. On the other hand ethernet part is not
>> > important since OS can figure it out by looking in pci config space.
>> 
>> The OS does know what's sitting in slot 4 on the PCI bus.
>> 
> Yes, and? That what I wrote above. "ethernet" part is redundant in case
> of PCI bus. A little bit of redundancy will not hurt and required by the
> spec.
>
>> If the OS number doesn't know what's sitting at i0cf8, why is "pci"
>> sufficient information?  Why don't we have to distinguish between the
>> different PCI host bridges?
> Manufacturer ID may be put along with pci. Full FDT contains much more
> information about each node though. It may even list compatible HW. Here
> we are concerned with device paths only.
>
>> 
>> >> I'm afraid "driver_name" is too confusing, because we already use
>> >> "driver" and "name" for the name of the device model: DeviceInfo member
>> >> name, and qemu_device_opts option name "driver".
>> > I use "driver_name" here since I am coding to Open Firmware spec now
>> > and this element in device path is called driver_name by the spec.
>> 
>> Why is it different from our DeviceInfo member name?
>> 
>> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
>> need a third?
> I haven't noticed we have alias! What is it used for? I think I can use
> it instead.
>
>> 
>> Do you envisage different device models sharing the same driver_name?
>> 
> Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.

But they're different devices!  Isn't Open Firmware's "driver name"
meant to identify a device type unambigously?

Consider the case of an ISA soundcard providing an IDE channel.  Want to
call it "ata", too?

>> [...]
>> >> Do we want a free-for-all ad hoc set of values for driver_name?  The
>> >> values become ABI instantly...  Can we adopt some existing set of names
>> >> for device classes?  Else, can we define our own with a bit more
>> >> control?
>> >> 
>> > I am open to suggestion. Open firmware describes this field as:
>> >
>> >   The driver name field is a sequence of between one and 31 letters, digits,
>> >   and punctuation characters from the set “, . _ + - ”. Uppercase and
>> >   lowercase characters are distinct. By convention, this name includes
>> >   the name of the device’s manufacturer and the device’s model name
>> >   separated by a “,”.  (See the definition of “name” in annex A.)
>> >   Inclusion of the manufacturer name within driver name is especially
>> >   important for devices intended to plug into standard buses, as this
>> >   minimizes the risk of accidental name collisions. It is somewhat less
>> >   important for devices that are permanently attached to a particular
>> >   system.  If the manufacturer name component is omitted (i.e., there is
>> >   no “,” within the driver name), the convention is to assume that
>> >   the manufacturer name is the same as that of the nearest ancestor node
>> >   (parent node, or grandparent node, etc.) that has an explicit manufacturer
>> >   name component.
>> 
>> I suspect that's exactly what DeviceInfo member name is.
>> 
> In cases where this is the case I just use "name".
>
>> > I am looking on existing implementations an copy what they do.
>> [...]

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Gleb Natapov]

On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
> >> Gleb Natapov <gleb@redhat.com> writes:
> >> 
> >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
> >> >> Gleb Natapov <gleb@redhat.com> writes:
> >> >> 
> >> >> > Add "deriver_name" to DeviceInfo to use in device path building. In
> >> >> 
> >> >> Typo "deriver".  Same in subject.
> >> >> 
> >> > Heh.
> >> >
> >> >> > contrast to "name" "driver_name" should refer to functionality device
> >> >> > provides instead of particular device model like "name" does.
> >> >> 
> >> >> Why is that useful in a device path?
> >> >> 
> >> > Sometimes it is sometimes it is not. Lets look at path like that:
> >> > /pci@i0cf8/ethernet@4/ethernet-phy@0
> >> >
> >> > It is important to have pci in the fist path element since it defines
> >> > what kind of bus addressing is used by next element ethernet@4.
> >> 
> >> It is for consumers that don't know what's sitting at i0cf8 on the
> >> system bus.
> > Yes. Same firmware may support different boards that have same pci
> > controller but on different addresses. Device name may even contain
> > manufacturer ID, so firmware will be able to find matching driver and
> > support more board without recompiling.
> 
> "pci" tells us it's some kind of PCI host bridge.  Why is that enough?
> Why don't we have to identify the particular host bridge, such as
> "i440FX-pcihost"?
> 
As I said below manufacturer ID may be part of device name. It should be
separated by comma though. Something like "i440FX,pci". But for x86 qemu
emulation this is not needed since all chipsets implement essentially
the same pci controller. Other platforms qemu emulates may use more
elaborate names. Other platforms may want to get full FDT tree from
qemu anyway.

> >> >                                                                 4 is
> >> > slot number in case of pci bus. On the other hand ethernet part is not
> >> > important since OS can figure it out by looking in pci config space.
> >> 
> >> The OS does know what's sitting in slot 4 on the PCI bus.
> >> 
> > Yes, and? That what I wrote above. "ethernet" part is redundant in case
> > of PCI bus. A little bit of redundancy will not hurt and required by the
> > spec.
> >
> >> If the OS number doesn't know what's sitting at i0cf8, why is "pci"
> >> sufficient information?  Why don't we have to distinguish between the
> >> different PCI host bridges?
> > Manufacturer ID may be put along with pci. Full FDT contains much more
> > information about each node though. It may even list compatible HW. Here
> > we are concerned with device paths only.
Here I said it already :)

> >
> >> 
> >> >> I'm afraid "driver_name" is too confusing, because we already use
> >> >> "driver" and "name" for the name of the device model: DeviceInfo member
> >> >> name, and qemu_device_opts option name "driver".
> >> > I use "driver_name" here since I am coding to Open Firmware spec now
> >> > and this element in device path is called driver_name by the spec.
> >> 
> >> Why is it different from our DeviceInfo member name?
> >> 
> >> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
> >> need a third?
> > I haven't noticed we have alias! What is it used for? I think I can use
> > it instead.
> >
> >> 
> >> Do you envisage different device models sharing the same driver_name?
> >> 
> > Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.
> 
> But they're different devices!  Isn't Open Firmware's "driver name"
> meant to identify a device type unambigously?
> 
Not necessary as far as I see from examples. Full FDT contains more
info. In this case all of those different devices present exactly same
HW interface, so from FW point of view they are the same. To make FW
life more easy it is better to have one name for all of them.

> Consider the case of an ISA soundcard providing an IDE channel.  Want to
> call it "ata", too?
If it is exactly like interface provided by devices above why FW cares
that this is soundcard?

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
>> >> Gleb Natapov <gleb@redhat.com> writes:
>> >> 
>> >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> >> >> Gleb Natapov <gleb@redhat.com> writes:
>> >> >> 
>> >> >> > Add "deriver_name" to DeviceInfo to use in device path building. In
>> >> >> 
>> >> >> Typo "deriver".  Same in subject.
>> >> >> 
>> >> > Heh.
>> >> >
>> >> >> > contrast to "name" "driver_name" should refer to functionality device
>> >> >> > provides instead of particular device model like "name" does.
>> >> >> 
>> >> >> Why is that useful in a device path?
>> >> >> 
>> >> > Sometimes it is sometimes it is not. Lets look at path like that:
>> >> > /pci@i0cf8/ethernet@4/ethernet-phy@0
>> >> >
>> >> > It is important to have pci in the fist path element since it defines
>> >> > what kind of bus addressing is used by next element ethernet@4.
>> >> 
>> >> It is for consumers that don't know what's sitting at i0cf8 on the
>> >> system bus.
>> > Yes. Same firmware may support different boards that have same pci
>> > controller but on different addresses. Device name may even contain
>> > manufacturer ID, so firmware will be able to find matching driver and
>> > support more board without recompiling.
>> 
>> "pci" tells us it's some kind of PCI host bridge.  Why is that enough?
>> Why don't we have to identify the particular host bridge, such as
>> "i440FX-pcihost"?
>> 
> As I said below manufacturer ID may be part of device name. It should be
> separated by comma though. Something like "i440FX,pci".

I'd expect "intel,i440FX".

Note that comma makes for extremely user-hostile -device usage.  Right
now, it doesn't work at all.

>                                                         But for x86 qemu
> emulation this is not needed since all chipsets implement essentially
> the same pci controller.

Will it stay that way?  What about Isaku's q35 work?

>                          Other platforms qemu emulates may use more
> elaborate names. Other platforms may want to get full FDT tree from
> qemu anyway.
>
>> >> >                                                                 4 is
>> >> > slot number in case of pci bus. On the other hand ethernet part is not
>> >> > important since OS can figure it out by looking in pci config space.
>> >> 
>> >> The OS does know what's sitting in slot 4 on the PCI bus.
>> >> 
>> > Yes, and? That what I wrote above. "ethernet" part is redundant in case
>> > of PCI bus. A little bit of redundancy will not hurt and required by the
>> > spec.
>> >
>> >> If the OS number doesn't know what's sitting at i0cf8, why is "pci"
>> >> sufficient information?  Why don't we have to distinguish between the
>> >> different PCI host bridges?
>> > Manufacturer ID may be put along with pci. Full FDT contains much more
>> > information about each node though. It may even list compatible HW. Here
>> > we are concerned with device paths only.
> Here I said it already :)
>
>> >
>> >> 
>> >> >> I'm afraid "driver_name" is too confusing, because we already use
>> >> >> "driver" and "name" for the name of the device model: DeviceInfo member
>> >> >> name, and qemu_device_opts option name "driver".
>> >> > I use "driver_name" here since I am coding to Open Firmware spec now
>> >> > and this element in device path is called driver_name by the spec.
>> >> 
>> >> Why is it different from our DeviceInfo member name?
>> >> 
>> >> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
>> >> need a third?
>> > I haven't noticed we have alias! What is it used for? I think I can use
>> > it instead.
>> >
>> >> 
>> >> Do you envisage different device models sharing the same driver_name?
>> >> 
>> > Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.
>> 
>> But they're different devices!  Isn't Open Firmware's "driver name"
>> meant to identify a device type unambigously?
>> 
> Not necessary as far as I see from examples. Full FDT contains more
> info. In this case all of those different devices present exactly same
> HW interface, so from FW point of view they are the same. To make FW
> life more easy it is better to have one name for all of them.

Okay.  It's a name for a sufficiently compatible set of devices, where
"sufficient compatibility" is defined from the consumer's point of view.

The consumer here is SeaBios, right?  To be precise: the specific
version of SeaBios we ship together with QEMU, right?  Then why are our
existing driver names (DevinceInfo member name) not good enough?

>> Consider the case of an ISA soundcard providing an IDE channel.  Want to
>> call it "ata", too?
> If it is exactly like interface provided by devices above why FW cares
> that this is soundcard?

What if firmware cares about soundcards as well?

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Gleb Natapov]

On Fri, Nov 05, 2010 at 05:24:01PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote:
> >> Gleb Natapov <gleb@redhat.com> writes:
> >> 
> >> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
> >> >> Gleb Natapov <gleb@redhat.com> writes:
> >> >> 
> >> >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
> >> >> >> Gleb Natapov <gleb@redhat.com> writes:
> >> >> >> 
> >> >> >> > Add "deriver_name" to DeviceInfo to use in device path building. In
> >> >> >> 
> >> >> >> Typo "deriver".  Same in subject.
> >> >> >> 
> >> >> > Heh.
> >> >> >
> >> >> >> > contrast to "name" "driver_name" should refer to functionality device
> >> >> >> > provides instead of particular device model like "name" does.
> >> >> >> 
> >> >> >> Why is that useful in a device path?
> >> >> >> 
> >> >> > Sometimes it is sometimes it is not. Lets look at path like that:
> >> >> > /pci@i0cf8/ethernet@4/ethernet-phy@0
> >> >> >
> >> >> > It is important to have pci in the fist path element since it defines
> >> >> > what kind of bus addressing is used by next element ethernet@4.
> >> >> 
> >> >> It is for consumers that don't know what's sitting at i0cf8 on the
> >> >> system bus.
> >> > Yes. Same firmware may support different boards that have same pci
> >> > controller but on different addresses. Device name may even contain
> >> > manufacturer ID, so firmware will be able to find matching driver and
> >> > support more board without recompiling.
> >> 
> >> "pci" tells us it's some kind of PCI host bridge.  Why is that enough?
> >> Why don't we have to identify the particular host bridge, such as
> >> "i440FX-pcihost"?
> >> 
> > As I said below manufacturer ID may be part of device name. It should be
> > separated by comma though. Something like "i440FX,pci".
> 
> I'd expect "intel,i440FX".
> 
It is impossible to figure what i440FX is. Anyway as I said many times
already device path shouldn't contain full information about all devices
in the path but only enough information to find device the path points
to. FDT contains full information about device including all resources
it uses, full device name, compatible device list an so on. This patch
is not about passing FDT to FW, just about creating Open Firmware
complaint device path.

> Note that comma makes for extremely user-hostile -device usage.  Right
> now, it doesn't work at all.
> 
> >                                                         But for x86 qemu
> > emulation this is not needed since all chipsets implement essentially
> > the same pci controller.
> 
> Will it stay that way?  What about Isaku's q35 work?
> 
AFAIK all PC chipsets implement same PCI config interface accessible
through io ports 0cf8-0cff. Otherwise each OS will have to have support
for each chipset.

> >                          Other platforms qemu emulates may use more
> > elaborate names. Other platforms may want to get full FDT tree from
> > qemu anyway.
> >
> >> >> >                                                                 4 is
> >> >> > slot number in case of pci bus. On the other hand ethernet part is not
> >> >> > important since OS can figure it out by looking in pci config space.
> >> >> 
> >> >> The OS does know what's sitting in slot 4 on the PCI bus.
> >> >> 
> >> > Yes, and? That what I wrote above. "ethernet" part is redundant in case
> >> > of PCI bus. A little bit of redundancy will not hurt and required by the
> >> > spec.
> >> >
> >> >> If the OS number doesn't know what's sitting at i0cf8, why is "pci"
> >> >> sufficient information?  Why don't we have to distinguish between the
> >> >> different PCI host bridges?
> >> > Manufacturer ID may be put along with pci. Full FDT contains much more
> >> > information about each node though. It may even list compatible HW. Here
> >> > we are concerned with device paths only.
> > Here I said it already :)
> >
> >> >
> >> >> 
> >> >> >> I'm afraid "driver_name" is too confusing, because we already use
> >> >> >> "driver" and "name" for the name of the device model: DeviceInfo member
> >> >> >> name, and qemu_device_opts option name "driver".
> >> >> > I use "driver_name" here since I am coding to Open Firmware spec now
> >> >> > and this element in device path is called driver_name by the spec.
> >> >> 
> >> >> Why is it different from our DeviceInfo member name?
> >> >> 
> >> >> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
> >> >> need a third?
> >> > I haven't noticed we have alias! What is it used for? I think I can use
> >> > it instead.
> >> >
> >> >> 
> >> >> Do you envisage different device models sharing the same driver_name?
> >> >> 
> >> > Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.
> >> 
> >> But they're different devices!  Isn't Open Firmware's "driver name"
> >> meant to identify a device type unambigously?
> >> 
> > Not necessary as far as I see from examples. Full FDT contains more
> > info. In this case all of those different devices present exactly same
> > HW interface, so from FW point of view they are the same. To make FW
> > life more easy it is better to have one name for all of them.
> 
> Okay.  It's a name for a sufficiently compatible set of devices, where
> "sufficient compatibility" is defined from the consumer's point of view.
> 
> The consumer here is SeaBios, right?  To be precise: the specific
> version of SeaBios we ship together with QEMU, right?  Then why are our
> existing driver names (DevinceInfo member name) not good enough?
> 
Why should Seabios match against three (or even more) different type of
devices to detect ata interface? Why require Seabios changes when this
can be avoided (if new device that provide ata is added)? OpenBIOS also
supports qemu BTW (this is Open Firmware implementation for pc, you can
run and see what kind of device paths it generates). 

> >> Consider the case of an ISA soundcard providing an IDE channel.  Want to
> >> call it "ata", too?
> > If it is exactly like interface provided by devices above why FW cares
> > that this is soundcard?
> 
> What if firmware cares about soundcards as well?
Then I expect device hierarchy reflect the fact that one device provides
two different devices one of which is ata and another one is soundcard.
Or are you suggesting that the same ISA card provides ata and soundcard
functionality through the same IO ports? Then don't call it ata. Call is
something else like ACME,atablaster. It will have to have special
support in firmware anyway.

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Fri, Nov 05, 2010 at 05:24:01PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote:
>> >> Gleb Natapov <gleb@redhat.com> writes:
>> >> 
>> >> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
>> >> >> Gleb Natapov <gleb@redhat.com> writes:
>> >> >> 
>> >> >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> >> >> >> Gleb Natapov <gleb@redhat.com> writes:
>> >> >> >> 
>> >> >> >> > Add "deriver_name" to DeviceInfo to use in device path building. In
>> >> >> >> 
>> >> >> >> Typo "deriver".  Same in subject.
>> >> >> >> 
>> >> >> > Heh.
>> >> >> >
>> >> >> >> > contrast to "name" "driver_name" should refer to functionality device
>> >> >> >> > provides instead of particular device model like "name" does.
>> >> >> >> 
>> >> >> >> Why is that useful in a device path?
>> >> >> >> 
>> >> >> > Sometimes it is sometimes it is not. Lets look at path like that:
>> >> >> > /pci@i0cf8/ethernet@4/ethernet-phy@0
>> >> >> >
>> >> >> > It is important to have pci in the fist path element since it defines
>> >> >> > what kind of bus addressing is used by next element ethernet@4.
>> >> >> 
>> >> >> It is for consumers that don't know what's sitting at i0cf8 on the
>> >> >> system bus.
>> >> > Yes. Same firmware may support different boards that have same pci
>> >> > controller but on different addresses. Device name may even contain
>> >> > manufacturer ID, so firmware will be able to find matching driver and
>> >> > support more board without recompiling.
>> >> 
>> >> "pci" tells us it's some kind of PCI host bridge.  Why is that enough?
>> >> Why don't we have to identify the particular host bridge, such as
>> >> "i440FX-pcihost"?
>> >> 
>> > As I said below manufacturer ID may be part of device name. It should be
>> > separated by comma though. Something like "i440FX,pci".
>> 
>> I'd expect "intel,i440FX".
>> 
> It is impossible to figure what i440FX is. Anyway as I said many times
> already device path shouldn't contain full information about all devices
> in the path but only enough information to find device the path points
> to. FDT contains full information about device including all resources
> it uses, full device name, compatible device list an so on. This patch
> is not about passing FDT to FW, just about creating Open Firmware
> complaint device path.
>
>> Note that comma makes for extremely user-hostile -device usage.  Right
>> now, it doesn't work at all.
>> 
>> >                                                         But for x86 qemu
>> > emulation this is not needed since all chipsets implement essentially
>> > the same pci controller.
>> 
>> Will it stay that way?  What about Isaku's q35 work?
>> 
> AFAIK all PC chipsets implement same PCI config interface accessible
> through io ports 0cf8-0cff. Otherwise each OS will have to have support
> for each chipset.

Nice to have some compatibility, for once.

>> >                          Other platforms qemu emulates may use more
>> > elaborate names. Other platforms may want to get full FDT tree from
>> > qemu anyway.
>> >
>> >> >> >                                                                 4 is
>> >> >> > slot number in case of pci bus. On the other hand ethernet part is not
>> >> >> > important since OS can figure it out by looking in pci config space.
>> >> >> 
>> >> >> The OS does know what's sitting in slot 4 on the PCI bus.
>> >> >> 
>> >> > Yes, and? That what I wrote above. "ethernet" part is redundant in case
>> >> > of PCI bus. A little bit of redundancy will not hurt and required by the
>> >> > spec.
>> >> >
>> >> >> If the OS number doesn't know what's sitting at i0cf8, why is "pci"
>> >> >> sufficient information?  Why don't we have to distinguish between the
>> >> >> different PCI host bridges?
>> >> > Manufacturer ID may be put along with pci. Full FDT contains much more
>> >> > information about each node though. It may even list compatible HW. Here
>> >> > we are concerned with device paths only.
>> > Here I said it already :)
>> >
>> >> >
>> >> >> 
>> >> >> >> I'm afraid "driver_name" is too confusing, because we already use
>> >> >> >> "driver" and "name" for the name of the device model: DeviceInfo member
>> >> >> >> name, and qemu_device_opts option name "driver".
>> >> >> > I use "driver_name" here since I am coding to Open Firmware spec now
>> >> >> > and this element in device path is called driver_name by the spec.
>> >> >> 
>> >> >> Why is it different from our DeviceInfo member name?
>> >> >> 
>> >> >> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
>> >> >> need a third?
>> >> > I haven't noticed we have alias! What is it used for? I think I can use
>> >> > it instead.
>> >> >
>> >> >> 
>> >> >> Do you envisage different device models sharing the same driver_name?
>> >> >> 
>> >> > Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.
>> >> 
>> >> But they're different devices!  Isn't Open Firmware's "driver name"
>> >> meant to identify a device type unambigously?
>> >> 
>> > Not necessary as far as I see from examples. Full FDT contains more
>> > info. In this case all of those different devices present exactly same
>> > HW interface, so from FW point of view they are the same. To make FW
>> > life more easy it is better to have one name for all of them.
>> 
>> Okay.  It's a name for a sufficiently compatible set of devices, where
>> "sufficient compatibility" is defined from the consumer's point of view.
>> 
>> The consumer here is SeaBios, right?  To be precise: the specific
>> version of SeaBios we ship together with QEMU, right?  Then why are our
>> existing driver names (DevinceInfo member name) not good enough?
>> 
> Why should Seabios match against three (or even more) different type of
> devices to detect ata interface? Why require Seabios changes when this
> can be avoided (if new device that provide ata is added)? OpenBIOS also
> supports qemu BTW (this is Open Firmware implementation for pc, you can
> run and see what kind of device paths it generates). 

I think we've finally cut through the confusion caused by the
unfortunate choice of driver_name for this new device attribute.

The fact that you choose values of your driver_name in a way that is
inspired by the syntactic conventions of IEEE 1275 is not its
distinguishing characteristic.  The values of existing member name are
inspired by that as well.  driver_name's distinguishing characteristic
is its purpose: communication with SeaBIOS.

I'm fine with you choosing its values however it's convenient for that
purpose, as long as you give it a name reflecting that purpose.  What
about fw_name and qdev_fw_name()?


Next, I'm worried about overloading of method get_dev_path().  It's
being used for a very specific purpose: savevm/loadvm.  

* It's currently defined only for PCI devices.  Your PATCH 7/8 changes
  its value there, from DOMAIN:BUS:SLOT.FUNCTION to FW_NAME@SLOT.

  - The old value identifies the qdev.  The new value does not
    (remember, we have a separate qdev per PCI function).  Why is this
    okay?

  - Is the value saved with the VM?  If yes, this is an incompatible
    change.

* You extend it for ISA and System bus (PATCH 5,6/8).  How does this
  affect savevm?

[...]

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Gleb Natapov]

On Sat, Nov 06, 2010 at 10:01:25AM +0100, Markus Armbruster wrote:
[skip]
> > Why should Seabios match against three (or even more) different type of
> > devices to detect ata interface? Why require Seabios changes when this
> > can be avoided (if new device that provide ata is added)? OpenBIOS also
> > supports qemu BTW (this is Open Firmware implementation for pc, you can
> > run and see what kind of device paths it generates). 
> 
> I think we've finally cut through the confusion caused by the
> unfortunate choice of driver_name for this new device attribute.
> 
> The fact that you choose values of your driver_name in a way that is
> inspired by the syntactic conventions of IEEE 1275 is not its
> distinguishing characteristic.  The values of existing member name are
> inspired by that as well.  driver_name's distinguishing characteristic
> is its purpose: communication with SeaBIOS.
> 
My understanding of this name in IEEE 1275 is that it specifies what
driver in FW handles a device.

> I'm fine with you choosing its values however it's convenient for that
> purpose, as long as you give it a name reflecting that purpose.  What
> about fw_name and qdev_fw_name()?
> 
I am not attached to the name. Can "alias" be used for that purpose?

> 
> Next, I'm worried about overloading of method get_dev_path().  It's
> being used for a very specific purpose: savevm/loadvm.  
> 
This part of the patch is not completed yet. I intend to change the code
in savevm/loadvm to call qdev_get_dev_path() to get full device path
there.

> * It's currently defined only for PCI devices.  Your PATCH 7/8 changes
>   its value there, from DOMAIN:BUS:SLOT.FUNCTION to FW_NAME@SLOT.
> 
Old definition is buggy BTW. BUS part is controlled by a guest and may
be different from default value at destination.

>   - The old value identifies the qdev.  The new value does not
>     (remember, we have a separate qdev per PCI function).  Why is this
>     okay?
> 
No no. New value is FW_NAME@SLOT,FUNC. Spec says that if FUNC is zero it
can be omitted.

>   - Is the value saved with the VM?  If yes, this is an incompatible
>     change.
Don't understand that remark.

> 
> * You extend it for ISA and System bus (PATCH 5,6/8).  How does this
>   affect savevm?
> 
We should ask savevm experts. As far as I can see it affects id
creation. As long as id is unique we should be OK. We may send more info
on migration after the patches.

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Sat, Nov 06, 2010 at 10:01:25AM +0100, Markus Armbruster wrote:
> [skip]
>> > Why should Seabios match against three (or even more) different type of
>> > devices to detect ata interface? Why require Seabios changes when this
>> > can be avoided (if new device that provide ata is added)? OpenBIOS also
>> > supports qemu BTW (this is Open Firmware implementation for pc, you can
>> > run and see what kind of device paths it generates). 
>> 
>> I think we've finally cut through the confusion caused by the
>> unfortunate choice of driver_name for this new device attribute.
>> 
>> The fact that you choose values of your driver_name in a way that is
>> inspired by the syntactic conventions of IEEE 1275 is not its
>> distinguishing characteristic.  The values of existing member name are
>> inspired by that as well.  driver_name's distinguishing characteristic
>> is its purpose: communication with SeaBIOS.
>> 
> My understanding of this name in IEEE 1275 is that it specifies what
> driver in FW handles a device.
>
>> I'm fine with you choosing its values however it's convenient for that
>> purpose, as long as you give it a name reflecting that purpose.  What
>> about fw_name and qdev_fw_name()?
>> 
> I am not attached to the name. Can "alias" be used for that purpose?

alias needs to be an unambigous name of the device, just like name.  If
I understand you correctly, you want to use the same string for
different, yet sufficiently compatible devices, so alias won't do.

>> Next, I'm worried about overloading of method get_dev_path().  It's
>> being used for a very specific purpose: savevm/loadvm.  
>> 
> This part of the patch is not completed yet. I intend to change the code
> in savevm/loadvm to call qdev_get_dev_path() to get full device path
> there.
>
>> * It's currently defined only for PCI devices.  Your PATCH 7/8 changes
>>   its value there, from DOMAIN:BUS:SLOT.FUNCTION to FW_NAME@SLOT.
>> 
> Old definition is buggy BTW. BUS part is controlled by a guest and may
> be different from default value at destination.

Yes, it's problematic for anything domain:bus 0:0.  Which happens to be
the only one that can occur here currently, as far as I know.

>>   - The old value identifies the qdev.  The new value does not
>>     (remember, we have a separate qdev per PCI function).  Why is this
>>     okay?
>> 
> No no. New value is FW_NAME@SLOT,FUNC. Spec says that if FUNC is zero it
> can be omitted.

Okay.

>>   - Is the value saved with the VM?  If yes, this is an incompatible
>>     change.
> Don't understand that remark.

If the value somehow makes it into the savevm data, then changing values
could render the data incompatible: old qemu can't load new data, and
vice versa.

>> * You extend it for ISA and System bus (PATCH 5,6/8).  How does this
>>   affect savevm?
>> 
> We should ask savevm experts. As far as I can see it affects id
> creation. As long as id is unique we should be OK. We may send more info
> on migration after the patches.

We definitely need review and testing there.

[PATCHv2 2/8] Keep track of ISA ports ISA device is using in qdev.

[Gleb Natapov]

Store all io ports used by device in ISADevice structure.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/cs4231a.c     |    1 +
 hw/fdc.c         |    3 +++
 hw/gus.c         |    4 ++++
 hw/ide/isa.c     |    2 ++
 hw/isa-bus.c     |   25 +++++++++++++++++++++++++
 hw/isa.h         |    4 ++++
 hw/m48t59.c      |    1 +
 hw/mc146818rtc.c |    1 +
 hw/ne2000-isa.c  |    3 +++
 hw/parallel.c    |    5 +++++
 hw/pckbd.c       |    3 +++
 hw/sb16.c        |    4 ++++
 hw/serial.c      |    1 +
 13 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/hw/cs4231a.c b/hw/cs4231a.c
index 4d5ce5c..598f032 100644
--- a/hw/cs4231a.c
+++ b/hw/cs4231a.c
@@ -645,6 +645,7 @@ static int cs4231a_initfn (ISADevice *dev)
     isa_init_irq (dev, &s->pic, s->irq);
 
     for (i = 0; i < 4; i++) {
+        isa_init_ioport(dev, i);
         register_ioport_write (s->port + i, 1, 1, cs_write, s);
         register_ioport_read (s->port + i, 1, 1, cs_read, s);
     }
diff --git a/hw/fdc.c b/hw/fdc.c
index b4217a3..51ca404 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -1983,6 +1983,9 @@ static int isabus_fdc_init1(ISADevice *dev)
                           &fdctrl_write_port, fdctrl);
     register_ioport_write(iobase + 0x07, 1, 1,
                           &fdctrl_write_port, fdctrl);
+    isa_init_ioport_range(dev, iobase + 1, 5);
+    isa_init_ioport(dev, iobase + 7);
+
     isa_init_irq(&isa->busdev, &fdctrl->irq, isairq);
     fdctrl->dma_chann = dma_chann;
 
diff --git a/hw/gus.c b/hw/gus.c
index e9016d8..ff9e7c7 100644
--- a/hw/gus.c
+++ b/hw/gus.c
@@ -264,20 +264,24 @@ static int gus_initfn (ISADevice *dev)
 
     register_ioport_write (s->port, 1, 1, gus_writeb, s);
     register_ioport_write (s->port, 1, 2, gus_writew, s);
+    isa_init_ioport_range(dev, s->port, 2);
 
     register_ioport_read ((s->port + 0x100) & 0xf00, 1, 1, gus_readb, s);
     register_ioport_read ((s->port + 0x100) & 0xf00, 1, 2, gus_readw, s);
+    isa_init_ioport_range(dev, (s->port + 0x100) & 0xf00, 2);
 
     register_ioport_write (s->port + 6, 10, 1, gus_writeb, s);
     register_ioport_write (s->port + 6, 10, 2, gus_writew, s);
     register_ioport_read (s->port + 6, 10, 1, gus_readb, s);
     register_ioport_read (s->port + 6, 10, 2, gus_readw, s);
+    isa_init_ioport_range(dev, s->port + 6, 10);
 
 
     register_ioport_write (s->port + 0x100, 8, 1, gus_writeb, s);
     register_ioport_write (s->port + 0x100, 8, 2, gus_writew, s);
     register_ioport_read (s->port + 0x100, 8, 1, gus_readb, s);
     register_ioport_read (s->port + 0x100, 8, 2, gus_readw, s);
+    isa_init_ioport_range(dev, s->port + 0x100, 8);
 
     DMA_register_channel (s->emu.gusdma, GUS_read_DMA, s);
     s->emu.himemaddr = s->himem;
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 489cc99..9b94495 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -70,6 +70,8 @@ static int isa_ide_initfn(ISADevice *dev)
     ide_bus_new(&s->bus, &s->dev.qdev);
     ide_init_ioport(&s->bus, s->iobase, s->iobase2);
     isa_init_irq(dev, &s->irq, s->isairq);
+    isa_init_ioport_range(dev, s->iobase, 8);
+    isa_init_ioport(dev, s->iobase2);
     ide_init2(&s->bus, s->irq);
     vmstate_register(&dev->qdev, 0, &vmstate_ide_isa, s);
     return 0;
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 2c42b80..c1275e8 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -92,6 +92,31 @@ void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
     dev->nirqs++;
 }
 
+static void isa_init_ioport_one(ISADevice *dev, uint16_t ioport)
+{
+    assert(dev->nioports < ARRAY_SIZE(dev->ioports));
+    dev->ioports[dev->nioports++] = ioport;
+}
+
+static int isa_cmp_ports(const void *p1, const void *p2)
+{
+    return *(uint16_t*)p1 - *(uint16_t*)p2;
+}
+
+void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length)
+{
+    int i;
+    for (i = start; i < start + length; i++) {
+        isa_init_ioport_one(dev, i);
+    }
+    qsort(dev->ioports, dev->nioports, sizeof(dev->ioports[0]), isa_cmp_ports);
+}
+
+void isa_init_ioport(ISADevice *dev, uint16_t ioport)
+{
+    isa_init_ioport_range(dev, ioport, 1);
+}
+
 static int isa_qdev_init(DeviceState *qdev, DeviceInfo *base)
 {
     ISADevice *dev = DO_UPCAST(ISADevice, qdev, qdev);
diff --git a/hw/isa.h b/hw/isa.h
index aaf0272..4794b76 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -14,6 +14,8 @@ struct ISADevice {
     DeviceState qdev;
     uint32_t isairq[2];
     int nirqs;
+    uint16_t ioports[32];
+    int nioports;
 };
 
 typedef int (*isa_qdev_initfn)(ISADevice *dev);
@@ -26,6 +28,8 @@ ISABus *isa_bus_new(DeviceState *dev);
 void isa_bus_irqs(qemu_irq *irqs);
 qemu_irq isa_reserve_irq(int isairq);
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
+void isa_init_ioport(ISADevice *dev, uint16_t ioport);
+void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length);
 void isa_qdev_register(ISADeviceInfo *info);
 ISADevice *isa_create(const char *name);
 ISADevice *isa_create_simple(const char *name);
diff --git a/hw/m48t59.c b/hw/m48t59.c
index c7492a6..75a94e1 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -680,6 +680,7 @@ M48t59State *m48t59_init_isa(uint32_t io_base, uint16_t size, int type)
     if (io_base != 0) {
         register_ioport_read(io_base, 0x04, 1, NVRAM_readb, s);
         register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, s);
+        isa_init_ioport_range(dev, io_base, 4);
     }
 
     return s;
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 2b91fa8..6466aff 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -605,6 +605,7 @@ static int rtc_initfn(ISADevice *dev)
 
     register_ioport_write(base, 2, 1, cmos_ioport_write, s);
     register_ioport_read(base, 2, 1, cmos_ioport_read, s);
+    isa_init_ioport_range(dev, base, 2);
 
     qdev_set_legacy_instance_id(&dev->qdev, base, 2);
     qemu_register_reset(rtc_reset, s);
diff --git a/hw/ne2000-isa.c b/hw/ne2000-isa.c
index 03a5a1f..3ff0d89 100644
--- a/hw/ne2000-isa.c
+++ b/hw/ne2000-isa.c
@@ -68,14 +68,17 @@ static int isa_ne2000_initfn(ISADevice *dev)
 
     register_ioport_write(isa->iobase, 16, 1, ne2000_ioport_write, s);
     register_ioport_read(isa->iobase, 16, 1, ne2000_ioport_read, s);
+    isa_init_ioport_range(dev, isa->iobase, 16);
 
     register_ioport_write(isa->iobase + 0x10, 1, 1, ne2000_asic_ioport_write, s);
     register_ioport_read(isa->iobase + 0x10, 1, 1, ne2000_asic_ioport_read, s);
     register_ioport_write(isa->iobase + 0x10, 2, 2, ne2000_asic_ioport_write, s);
     register_ioport_read(isa->iobase + 0x10, 2, 2, ne2000_asic_ioport_read, s);
+    isa_init_ioport_range(dev, isa->iobase + 0x10, 2);
 
     register_ioport_write(isa->iobase + 0x1f, 1, 1, ne2000_reset_ioport_write, s);
     register_ioport_read(isa->iobase + 0x1f, 1, 1, ne2000_reset_ioport_read, s);
+    isa_init_ioport(dev, isa->iobase + 0x1f);
 
     isa_init_irq(dev, &s->irq, isa->isairq);
 
diff --git a/hw/parallel.c b/hw/parallel.c
index 6b11672..6270b53 100644
--- a/hw/parallel.c
+++ b/hw/parallel.c
@@ -481,16 +481,21 @@ static int parallel_isa_initfn(ISADevice *dev)
     if (s->hw_driver) {
         register_ioport_write(base, 8, 1, parallel_ioport_write_hw, s);
         register_ioport_read(base, 8, 1, parallel_ioport_read_hw, s);
+        isa_init_ioport_range(dev, base, 8);
+
         register_ioport_write(base+4, 1, 2, parallel_ioport_eppdata_write_hw2, s);
         register_ioport_read(base+4, 1, 2, parallel_ioport_eppdata_read_hw2, s);
         register_ioport_write(base+4, 1, 4, parallel_ioport_eppdata_write_hw4, s);
         register_ioport_read(base+4, 1, 4, parallel_ioport_eppdata_read_hw4, s);
+        isa_init_ioport(dev, base+4);
         register_ioport_write(base+0x400, 8, 1, parallel_ioport_ecp_write, s);
         register_ioport_read(base+0x400, 8, 1, parallel_ioport_ecp_read, s);
+        isa_init_ioport_range(dev, base+0x400, 8);
     }
     else {
         register_ioport_write(base, 8, 1, parallel_ioport_write_sw, s);
         register_ioport_read(base, 8, 1, parallel_ioport_read_sw, s);
+        isa_init_ioport_range(dev, base, 8);
     }
     return 0;
 }
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 6e4e406..e736505 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -484,10 +484,13 @@ static int i8042_initfn(ISADevice *dev)
 
     register_ioport_read(0x60, 1, 1, kbd_read_data, s);
     register_ioport_write(0x60, 1, 1, kbd_write_data, s);
+    isa_init_ioport(dev, 0x60);
     register_ioport_read(0x64, 1, 1, kbd_read_status, s);
     register_ioport_write(0x64, 1, 1, kbd_write_command, s);
+    isa_init_ioport(dev, 0x64);
     register_ioport_read(0x92, 1, 1, ioport92_read, s);
     register_ioport_write(0x92, 1, 1, ioport92_write, s);
+    isa_init_ioport(dev, 0x92);
 
     s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
     s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
diff --git a/hw/sb16.c b/hw/sb16.c
index 78590a7..c9d37ad 100644
--- a/hw/sb16.c
+++ b/hw/sb16.c
@@ -1368,16 +1368,20 @@ static int sb16_initfn (ISADevice *dev)
 
     for (i = 0; i < ARRAY_SIZE (dsp_write_ports); i++) {
         register_ioport_write (s->port + dsp_write_ports[i], 1, 1, dsp_write, s);
+        isa_init_ioport(dev, s->port + dsp_write_ports[i]);
     }
 
     for (i = 0; i < ARRAY_SIZE (dsp_read_ports); i++) {
         register_ioport_read (s->port + dsp_read_ports[i], 1, 1, dsp_read, s);
+        isa_init_ioport(dev, s->port + dsp_read_ports[i]);
     }
 
     register_ioport_write (s->port + 0x4, 1, 1, mixer_write_indexb, s);
     register_ioport_write (s->port + 0x4, 1, 2, mixer_write_indexw, s);
+    isa_init_ioport(dev, s->port + 0x4);
     register_ioport_read (s->port + 0x5, 1, 1, mixer_read, s);
     register_ioport_write (s->port + 0x5, 1, 1, mixer_write_datab, s);
+    isa_init_ioport(dev, s->port + 0x5);
 
     DMA_register_channel (s->hdma, SB_read_DMA, s);
     DMA_register_channel (s->dma, SB_read_DMA, s);
diff --git a/hw/serial.c b/hw/serial.c
index 9ebc452..20902ae 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -778,6 +778,7 @@ static int serial_isa_initfn(ISADevice *dev)
 
     register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
     register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
+    isa_init_ioport_range(dev, isa->iobase, 8);
     return 0;
 }
 
-- 
1.7.1

[Qemu-devel] [PATCHv2 2/8] Keep track of ISA ports ISA device is using in qdev.

[Gleb Natapov]

Store all io ports used by device in ISADevice structure.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/cs4231a.c     |    1 +
 hw/fdc.c         |    3 +++
 hw/gus.c         |    4 ++++
 hw/ide/isa.c     |    2 ++
 hw/isa-bus.c     |   25 +++++++++++++++++++++++++
 hw/isa.h         |    4 ++++
 hw/m48t59.c      |    1 +
 hw/mc146818rtc.c |    1 +
 hw/ne2000-isa.c  |    3 +++
 hw/parallel.c    |    5 +++++
 hw/pckbd.c       |    3 +++
 hw/sb16.c        |    4 ++++
 hw/serial.c      |    1 +
 13 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/hw/cs4231a.c b/hw/cs4231a.c
index 4d5ce5c..598f032 100644
--- a/hw/cs4231a.c
+++ b/hw/cs4231a.c
@@ -645,6 +645,7 @@ static int cs4231a_initfn (ISADevice *dev)
     isa_init_irq (dev, &s->pic, s->irq);
 
     for (i = 0; i < 4; i++) {
+        isa_init_ioport(dev, i);
         register_ioport_write (s->port + i, 1, 1, cs_write, s);
         register_ioport_read (s->port + i, 1, 1, cs_read, s);
     }
diff --git a/hw/fdc.c b/hw/fdc.c
index b4217a3..51ca404 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -1983,6 +1983,9 @@ static int isabus_fdc_init1(ISADevice *dev)
                           &fdctrl_write_port, fdctrl);
     register_ioport_write(iobase + 0x07, 1, 1,
                           &fdctrl_write_port, fdctrl);
+    isa_init_ioport_range(dev, iobase + 1, 5);
+    isa_init_ioport(dev, iobase + 7);
+
     isa_init_irq(&isa->busdev, &fdctrl->irq, isairq);
     fdctrl->dma_chann = dma_chann;
 
diff --git a/hw/gus.c b/hw/gus.c
index e9016d8..ff9e7c7 100644
--- a/hw/gus.c
+++ b/hw/gus.c
@@ -264,20 +264,24 @@ static int gus_initfn (ISADevice *dev)
 
     register_ioport_write (s->port, 1, 1, gus_writeb, s);
     register_ioport_write (s->port, 1, 2, gus_writew, s);
+    isa_init_ioport_range(dev, s->port, 2);
 
     register_ioport_read ((s->port + 0x100) & 0xf00, 1, 1, gus_readb, s);
     register_ioport_read ((s->port + 0x100) & 0xf00, 1, 2, gus_readw, s);
+    isa_init_ioport_range(dev, (s->port + 0x100) & 0xf00, 2);
 
     register_ioport_write (s->port + 6, 10, 1, gus_writeb, s);
     register_ioport_write (s->port + 6, 10, 2, gus_writew, s);
     register_ioport_read (s->port + 6, 10, 1, gus_readb, s);
     register_ioport_read (s->port + 6, 10, 2, gus_readw, s);
+    isa_init_ioport_range(dev, s->port + 6, 10);
 
 
     register_ioport_write (s->port + 0x100, 8, 1, gus_writeb, s);
     register_ioport_write (s->port + 0x100, 8, 2, gus_writew, s);
     register_ioport_read (s->port + 0x100, 8, 1, gus_readb, s);
     register_ioport_read (s->port + 0x100, 8, 2, gus_readw, s);
+    isa_init_ioport_range(dev, s->port + 0x100, 8);
 
     DMA_register_channel (s->emu.gusdma, GUS_read_DMA, s);
     s->emu.himemaddr = s->himem;
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 489cc99..9b94495 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -70,6 +70,8 @@ static int isa_ide_initfn(ISADevice *dev)
     ide_bus_new(&s->bus, &s->dev.qdev);
     ide_init_ioport(&s->bus, s->iobase, s->iobase2);
     isa_init_irq(dev, &s->irq, s->isairq);
+    isa_init_ioport_range(dev, s->iobase, 8);
+    isa_init_ioport(dev, s->iobase2);
     ide_init2(&s->bus, s->irq);
     vmstate_register(&dev->qdev, 0, &vmstate_ide_isa, s);
     return 0;
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 2c42b80..c1275e8 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -92,6 +92,31 @@ void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
     dev->nirqs++;
 }
 
+static void isa_init_ioport_one(ISADevice *dev, uint16_t ioport)
+{
+    assert(dev->nioports < ARRAY_SIZE(dev->ioports));
+    dev->ioports[dev->nioports++] = ioport;
+}
+
+static int isa_cmp_ports(const void *p1, const void *p2)
+{
+    return *(uint16_t*)p1 - *(uint16_t*)p2;
+}
+
+void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length)
+{
+    int i;
+    for (i = start; i < start + length; i++) {
+        isa_init_ioport_one(dev, i);
+    }
+    qsort(dev->ioports, dev->nioports, sizeof(dev->ioports[0]), isa_cmp_ports);
+}
+
+void isa_init_ioport(ISADevice *dev, uint16_t ioport)
+{
+    isa_init_ioport_range(dev, ioport, 1);
+}
+
 static int isa_qdev_init(DeviceState *qdev, DeviceInfo *base)
 {
     ISADevice *dev = DO_UPCAST(ISADevice, qdev, qdev);
diff --git a/hw/isa.h b/hw/isa.h
index aaf0272..4794b76 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -14,6 +14,8 @@ struct ISADevice {
     DeviceState qdev;
     uint32_t isairq[2];
     int nirqs;
+    uint16_t ioports[32];
+    int nioports;
 };
 
 typedef int (*isa_qdev_initfn)(ISADevice *dev);
@@ -26,6 +28,8 @@ ISABus *isa_bus_new(DeviceState *dev);
 void isa_bus_irqs(qemu_irq *irqs);
 qemu_irq isa_reserve_irq(int isairq);
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
+void isa_init_ioport(ISADevice *dev, uint16_t ioport);
+void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length);
 void isa_qdev_register(ISADeviceInfo *info);
 ISADevice *isa_create(const char *name);
 ISADevice *isa_create_simple(const char *name);
diff --git a/hw/m48t59.c b/hw/m48t59.c
index c7492a6..75a94e1 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -680,6 +680,7 @@ M48t59State *m48t59_init_isa(uint32_t io_base, uint16_t size, int type)
     if (io_base != 0) {
         register_ioport_read(io_base, 0x04, 1, NVRAM_readb, s);
         register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, s);
+        isa_init_ioport_range(dev, io_base, 4);
     }
 
     return s;
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 2b91fa8..6466aff 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -605,6 +605,7 @@ static int rtc_initfn(ISADevice *dev)
 
     register_ioport_write(base, 2, 1, cmos_ioport_write, s);
     register_ioport_read(base, 2, 1, cmos_ioport_read, s);
+    isa_init_ioport_range(dev, base, 2);
 
     qdev_set_legacy_instance_id(&dev->qdev, base, 2);
     qemu_register_reset(rtc_reset, s);
diff --git a/hw/ne2000-isa.c b/hw/ne2000-isa.c
index 03a5a1f..3ff0d89 100644
--- a/hw/ne2000-isa.c
+++ b/hw/ne2000-isa.c
@@ -68,14 +68,17 @@ static int isa_ne2000_initfn(ISADevice *dev)
 
     register_ioport_write(isa->iobase, 16, 1, ne2000_ioport_write, s);
     register_ioport_read(isa->iobase, 16, 1, ne2000_ioport_read, s);
+    isa_init_ioport_range(dev, isa->iobase, 16);
 
     register_ioport_write(isa->iobase + 0x10, 1, 1, ne2000_asic_ioport_write, s);
     register_ioport_read(isa->iobase + 0x10, 1, 1, ne2000_asic_ioport_read, s);
     register_ioport_write(isa->iobase + 0x10, 2, 2, ne2000_asic_ioport_write, s);
     register_ioport_read(isa->iobase + 0x10, 2, 2, ne2000_asic_ioport_read, s);
+    isa_init_ioport_range(dev, isa->iobase + 0x10, 2);
 
     register_ioport_write(isa->iobase + 0x1f, 1, 1, ne2000_reset_ioport_write, s);
     register_ioport_read(isa->iobase + 0x1f, 1, 1, ne2000_reset_ioport_read, s);
+    isa_init_ioport(dev, isa->iobase + 0x1f);
 
     isa_init_irq(dev, &s->irq, isa->isairq);
 
diff --git a/hw/parallel.c b/hw/parallel.c
index 6b11672..6270b53 100644
--- a/hw/parallel.c
+++ b/hw/parallel.c
@@ -481,16 +481,21 @@ static int parallel_isa_initfn(ISADevice *dev)
     if (s->hw_driver) {
         register_ioport_write(base, 8, 1, parallel_ioport_write_hw, s);
         register_ioport_read(base, 8, 1, parallel_ioport_read_hw, s);
+        isa_init_ioport_range(dev, base, 8);
+
         register_ioport_write(base+4, 1, 2, parallel_ioport_eppdata_write_hw2, s);
         register_ioport_read(base+4, 1, 2, parallel_ioport_eppdata_read_hw2, s);
         register_ioport_write(base+4, 1, 4, parallel_ioport_eppdata_write_hw4, s);
         register_ioport_read(base+4, 1, 4, parallel_ioport_eppdata_read_hw4, s);
+        isa_init_ioport(dev, base+4);
         register_ioport_write(base+0x400, 8, 1, parallel_ioport_ecp_write, s);
         register_ioport_read(base+0x400, 8, 1, parallel_ioport_ecp_read, s);
+        isa_init_ioport_range(dev, base+0x400, 8);
     }
     else {
         register_ioport_write(base, 8, 1, parallel_ioport_write_sw, s);
         register_ioport_read(base, 8, 1, parallel_ioport_read_sw, s);
+        isa_init_ioport_range(dev, base, 8);
     }
     return 0;
 }
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 6e4e406..e736505 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -484,10 +484,13 @@ static int i8042_initfn(ISADevice *dev)
 
     register_ioport_read(0x60, 1, 1, kbd_read_data, s);
     register_ioport_write(0x60, 1, 1, kbd_write_data, s);
+    isa_init_ioport(dev, 0x60);
     register_ioport_read(0x64, 1, 1, kbd_read_status, s);
     register_ioport_write(0x64, 1, 1, kbd_write_command, s);
+    isa_init_ioport(dev, 0x64);
     register_ioport_read(0x92, 1, 1, ioport92_read, s);
     register_ioport_write(0x92, 1, 1, ioport92_write, s);
+    isa_init_ioport(dev, 0x92);
 
     s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
     s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
diff --git a/hw/sb16.c b/hw/sb16.c
index 78590a7..c9d37ad 100644
--- a/hw/sb16.c
+++ b/hw/sb16.c
@@ -1368,16 +1368,20 @@ static int sb16_initfn (ISADevice *dev)
 
     for (i = 0; i < ARRAY_SIZE (dsp_write_ports); i++) {
         register_ioport_write (s->port + dsp_write_ports[i], 1, 1, dsp_write, s);
+        isa_init_ioport(dev, s->port + dsp_write_ports[i]);
     }
 
     for (i = 0; i < ARRAY_SIZE (dsp_read_ports); i++) {
         register_ioport_read (s->port + dsp_read_ports[i], 1, 1, dsp_read, s);
+        isa_init_ioport(dev, s->port + dsp_read_ports[i]);
     }
 
     register_ioport_write (s->port + 0x4, 1, 1, mixer_write_indexb, s);
     register_ioport_write (s->port + 0x4, 1, 2, mixer_write_indexw, s);
+    isa_init_ioport(dev, s->port + 0x4);
     register_ioport_read (s->port + 0x5, 1, 1, mixer_read, s);
     register_ioport_write (s->port + 0x5, 1, 1, mixer_write_datab, s);
+    isa_init_ioport(dev, s->port + 0x5);
 
     DMA_register_channel (s->hdma, SB_read_DMA, s);
     DMA_register_channel (s->dma, SB_read_DMA, s);
diff --git a/hw/serial.c b/hw/serial.c
index 9ebc452..20902ae 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -778,6 +778,7 @@ static int serial_isa_initfn(ISADevice *dev)
 
     register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
     register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
+    isa_init_ioport_range(dev, isa->iobase, 8);
     return 0;
 }
 
-- 
1.7.1

[PATCHv2 3/8] Add get_dev_path callback to ISA bus in qdev.

[Gleb Natapov]

Use device ioports to create unique device path.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/isa-bus.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index c1275e8..c523302 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -31,11 +31,13 @@ static ISABus *isabus;
 target_phys_addr_t isa_mem_base = 0;
 
 static void isabus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static char *isabus_get_dev_path(DeviceState *dev);
 
 static struct BusInfo isa_bus_info = {
     .name      = "ISA",
     .size      = sizeof(ISABus),
     .print_dev = isabus_dev_print,
+    .get_dev_path = isabus_get_dev_path,
 };
 
 ISABus *isa_bus_new(DeviceState *dev)
@@ -188,4 +190,17 @@ static void isabus_register_devices(void)
     sysbus_register_withprop(&isabus_bridge_info);
 }
 
+static char *isabus_get_dev_path(DeviceState *dev)
+{
+    ISADevice *d = (ISADevice*)dev;
+    char path[40];
+    int off;
+
+    off = snprintf(path, sizeof(path), "%s", qdev_driver_name(dev));
+    if (d->nioports)
+        snprintf(path + off, sizeof(path) - off, "@%04x", d->ioports[0]);
+
+    return strdup(path);
+}
+
 device_init(isabus_register_devices)
-- 
1.7.1

[Qemu-devel] [PATCHv2 3/8] Add get_dev_path callback to ISA bus in qdev.

[Gleb Natapov]

Use device ioports to create unique device path.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/isa-bus.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index c1275e8..c523302 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -31,11 +31,13 @@ static ISABus *isabus;
 target_phys_addr_t isa_mem_base = 0;
 
 static void isabus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static char *isabus_get_dev_path(DeviceState *dev);
 
 static struct BusInfo isa_bus_info = {
     .name      = "ISA",
     .size      = sizeof(ISABus),
     .print_dev = isabus_dev_print,
+    .get_dev_path = isabus_get_dev_path,
 };
 
 ISABus *isa_bus_new(DeviceState *dev)
@@ -188,4 +190,17 @@ static void isabus_register_devices(void)
     sysbus_register_withprop(&isabus_bridge_info);
 }
 
+static char *isabus_get_dev_path(DeviceState *dev)
+{
+    ISADevice *d = (ISADevice*)dev;
+    char path[40];
+    int off;
+
+    off = snprintf(path, sizeof(path), "%s", qdev_driver_name(dev));
+    if (d->nioports)
+        snprintf(path + off, sizeof(path) - off, "@%04x", d->ioports[0]);
+
+    return strdup(path);
+}
+
 device_init(isabus_register_devices)
-- 
1.7.1

[PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/ide/cmd646.c   |    4 ++--
 hw/ide/internal.h |    3 ++-
 hw/ide/isa.c      |    2 +-
 hw/ide/piix.c     |    4 ++--
 hw/ide/qdev.c     |    3 ++-
 hw/ide/via.c      |    4 ++--
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index ff80dd5..b2cbdbc 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
     pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
 
     irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
-    ide_bus_new(&d->bus[0], &d->dev.qdev);
-    ide_bus_new(&d->bus[1], &d->dev.qdev);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init2(&d->bus[0], irq[0]);
     ide_init2(&d->bus[1], irq[1]);
 
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index 4165543..bde2664 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -448,6 +448,7 @@ struct IDEBus {
     IDEDevice *slave;
     BMDMAState *bmdma;
     IDEState ifs[2];
+    uint8_t bus_id;
     uint8_t unit;
     uint8_t cmd;
     qemu_irq irq;
@@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
 void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
 
 /* hw/ide/qdev.c */
-void ide_bus_new(IDEBus *idebus, DeviceState *dev);
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
 IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
 
 #endif /* HW_IDE_INTERNAL_H */
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 9b94495..0f54c3d 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -67,7 +67,7 @@ static int isa_ide_initfn(ISADevice *dev)
 {
     ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
 
-    ide_bus_new(&s->bus, &s->dev.qdev);
+    ide_bus_new(&s->bus, &s->dev.qdev, 0);
     ide_init_ioport(&s->bus, s->iobase, s->iobase2);
     isa_init_irq(dev, &s->irq, s->isairq);
     isa_init_ioport_range(dev, s->iobase, 8);
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 6206201..e56777f 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
     ide_init_ioport(&d->bus[1], 0x170, 0x376);
 
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 341548e..3ad2138 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -29,9 +29,10 @@ static struct BusInfo ide_bus_info = {
     .size  = sizeof(IDEBus),
 };
 
-void ide_bus_new(IDEBus *idebus, DeviceState *dev)
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
 {
     qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
+    idebus->bus_id = bus_id;
 }
 
 static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
diff --git a/hw/ide/via.c b/hw/ide/via.c
index b2c7cad..cc48b2b 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
 
     vmstate_register(&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);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init2(&d->bus[0], isa_reserve_irq(14));
     ide_init2(&d->bus[1], isa_reserve_irq(15));
     ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
-- 
1.7.1

[Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/ide/cmd646.c   |    4 ++--
 hw/ide/internal.h |    3 ++-
 hw/ide/isa.c      |    2 +-
 hw/ide/piix.c     |    4 ++--
 hw/ide/qdev.c     |    3 ++-
 hw/ide/via.c      |    4 ++--
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index ff80dd5..b2cbdbc 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
     pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
 
     irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
-    ide_bus_new(&d->bus[0], &d->dev.qdev);
-    ide_bus_new(&d->bus[1], &d->dev.qdev);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init2(&d->bus[0], irq[0]);
     ide_init2(&d->bus[1], irq[1]);
 
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index 4165543..bde2664 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -448,6 +448,7 @@ struct IDEBus {
     IDEDevice *slave;
     BMDMAState *bmdma;
     IDEState ifs[2];
+    uint8_t bus_id;
     uint8_t unit;
     uint8_t cmd;
     qemu_irq irq;
@@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
 void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
 
 /* hw/ide/qdev.c */
-void ide_bus_new(IDEBus *idebus, DeviceState *dev);
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
 IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
 
 #endif /* HW_IDE_INTERNAL_H */
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 9b94495..0f54c3d 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -67,7 +67,7 @@ static int isa_ide_initfn(ISADevice *dev)
 {
     ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
 
-    ide_bus_new(&s->bus, &s->dev.qdev);
+    ide_bus_new(&s->bus, &s->dev.qdev, 0);
     ide_init_ioport(&s->bus, s->iobase, s->iobase2);
     isa_init_irq(dev, &s->irq, s->isairq);
     isa_init_ioport_range(dev, s->iobase, 8);
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 6206201..e56777f 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
     ide_init_ioport(&d->bus[1], 0x170, 0x376);
 
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 341548e..3ad2138 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -29,9 +29,10 @@ static struct BusInfo ide_bus_info = {
     .size  = sizeof(IDEBus),
 };
 
-void ide_bus_new(IDEBus *idebus, DeviceState *dev)
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
 {
     qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
+    idebus->bus_id = bus_id;
 }
 
 static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
diff --git a/hw/ide/via.c b/hw/ide/via.c
index b2c7cad..cc48b2b 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
 
     vmstate_register(&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);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init2(&d->bus[0], isa_reserve_irq(14));
     ide_init2(&d->bus[1], isa_reserve_irq(15));
     ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
-- 
1.7.1

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Here's a generic answer to the question "which of the device's buses is
this?"

int qbus_index(BusState *bus)
{
    BusState *b;
    int i, index;

    index = -1;
    i = 0;
    QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
        if (b == bus) {
            index = i;
        }
        i++;
    }
    assert(0 <= index && index < i);
    return i - 1 - index;
}

The bus created first has index 0.

Note that the child_bus holds the children in reverse creation order,
and we can't traverse it backwards.  Same problem also visible with
makes info qtree:

      dev: piix3-ide, id ""
[...]
        bus: ide.1
          type IDE
        bus: ide.0
          type IDE

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Here's a generic answer to the question "which of the device's buses is
this?"

int qbus_index(BusState *bus)
{
    BusState *b;
    int i, index;

    index = -1;
    i = 0;
    QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
        if (b == bus) {
            index = i;
        }
        i++;
    }
    assert(0 <= index && index < i);
    return i - 1 - index;
}

The bus created first has index 0.

Note that the child_bus holds the children in reverse creation order,
and we can't traverse it backwards.  Same problem also visible with
makes info qtree:

      dev: piix3-ide, id ""
[...]
        bus: ide.1
          type IDE
        bus: ide.0
          type IDE

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
> Here's a generic answer to the question "which of the device's buses is
> this?"
> 
> int qbus_index(BusState *bus)
> {
>     BusState *b;
>     int i, index;
> 
>     index = -1;
>     i = 0;
>     QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
>         if (b == bus) {
>             index = i;
>         }
>         i++;
>     }
>     assert(0 <= index && index < i);
>     return i - 1 - index;
> }
> 
> The bus created first has index 0.
> 
> Note that the child_bus holds the children in reverse creation order,
> and we can't traverse it backwards.  Same problem also visible with
> makes info qtree:
> 
>       dev: piix3-ide, id ""
> [...]
>         bus: ide.1
>           type IDE
>         bus: ide.0
>           type IDE
Isn't this too implementation dependant? Are you against adding bus_id
to IDEBus? And will it work with ISA? I do not think IDEBus is
added to bus->parent->child_bus in case of ISA otherwise why both
IDEBuses have same name in isapc. Currently I have following patch
queued. It should fix isapc case too.

    Fix isapc IDE bus creation
    
    Currently we create two ide buses with the same name, so it is impossible
    to use -device ide-drive,bus= to address all possible disks in the isapc
    machine. Fix that by giving different names to different ide buses. Also
    store IDE bus id in IDEBus structure for easy access.

diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index ff80dd5..b2cbdbc 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
     pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
 
     irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
-    ide_bus_new(&d->bus[0], &d->dev.qdev);
-    ide_bus_new(&d->bus[1], &d->dev.qdev);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init2(&d->bus[0], irq[0]);
     ide_init2(&d->bus[1], irq[1]);
 
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index 4165543..bde2664 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -448,6 +448,7 @@ struct IDEBus {
     IDEDevice *slave;
     BMDMAState *bmdma;
     IDEState ifs[2];
+    uint8_t bus_id;
     uint8_t unit;
     uint8_t cmd;
     qemu_irq irq;
@@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
 void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
 
 /* hw/ide/qdev.c */
-void ide_bus_new(IDEBus *idebus, DeviceState *dev);
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
 IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
 
 #endif /* HW_IDE_INTERNAL_H */
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 9b94495..b000ab8 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -66,8 +66,9 @@ static const VMStateDescription vmstate_ide_isa = {
 static int isa_ide_initfn(ISADevice *dev)
 {
     ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
+    static uint8_t bus_id = 0;
 
-    ide_bus_new(&s->bus, &s->dev.qdev);
+    ide_bus_new(&s->bus, &s->dev.qdev, bus_id++);
     ide_init_ioport(&s->bus, s->iobase, s->iobase2);
     isa_init_irq(dev, &s->irq, s->isairq);
     isa_init_ioport_range(dev, s->iobase, 8);
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 6206201..e56777f 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
     ide_init_ioport(&d->bus[1], 0x170, 0x376);
 
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 336ffe1..220729e 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -29,9 +29,13 @@ static struct BusInfo ide_bus_info = {
     .size  = sizeof(IDEBus),
 };
 
-void ide_bus_new(IDEBus *idebus, DeviceState *dev)
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
 {
-    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
+    char name[10];
+
+    snprintf(name, sizeof(name), "ide.%d", bus_id); 
+    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, name);
+    idebus->bus_id = bus_id;
 }
 
 static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
diff --git a/hw/ide/via.c b/hw/ide/via.c
index b2c7cad..cc48b2b 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
 
     vmstate_register(&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);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init2(&d->bus[0], isa_reserve_irq(14));
     ide_init2(&d->bus[1], isa_reserve_irq(15));
     ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 3d07ce5..cec6c9b 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -163,7 +163,7 @@ static void pc_init1(ram_addr_t ram_size,
             ISADevice *dev;
             dev = isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
                                hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
-            idebus[i] = qdev_get_child_bus(&dev->qdev, "ide.0");
+            idebus[i] = qdev_get_child_bus(&dev->qdev, i ? "ide.1" : "ide.0");
         }
     }
 
--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
> Here's a generic answer to the question "which of the device's buses is
> this?"
> 
> int qbus_index(BusState *bus)
> {
>     BusState *b;
>     int i, index;
> 
>     index = -1;
>     i = 0;
>     QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
>         if (b == bus) {
>             index = i;
>         }
>         i++;
>     }
>     assert(0 <= index && index < i);
>     return i - 1 - index;
> }
> 
> The bus created first has index 0.
> 
> Note that the child_bus holds the children in reverse creation order,
> and we can't traverse it backwards.  Same problem also visible with
> makes info qtree:
> 
>       dev: piix3-ide, id ""
> [...]
>         bus: ide.1
>           type IDE
>         bus: ide.0
>           type IDE
Isn't this too implementation dependant? Are you against adding bus_id
to IDEBus? And will it work with ISA? I do not think IDEBus is
added to bus->parent->child_bus in case of ISA otherwise why both
IDEBuses have same name in isapc. Currently I have following patch
queued. It should fix isapc case too.

    Fix isapc IDE bus creation
    
    Currently we create two ide buses with the same name, so it is impossible
    to use -device ide-drive,bus= to address all possible disks in the isapc
    machine. Fix that by giving different names to different ide buses. Also
    store IDE bus id in IDEBus structure for easy access.

diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index ff80dd5..b2cbdbc 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
     pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
 
     irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
-    ide_bus_new(&d->bus[0], &d->dev.qdev);
-    ide_bus_new(&d->bus[1], &d->dev.qdev);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init2(&d->bus[0], irq[0]);
     ide_init2(&d->bus[1], irq[1]);
 
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index 4165543..bde2664 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -448,6 +448,7 @@ struct IDEBus {
     IDEDevice *slave;
     BMDMAState *bmdma;
     IDEState ifs[2];
+    uint8_t bus_id;
     uint8_t unit;
     uint8_t cmd;
     qemu_irq irq;
@@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
 void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
 
 /* hw/ide/qdev.c */
-void ide_bus_new(IDEBus *idebus, DeviceState *dev);
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
 IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
 
 #endif /* HW_IDE_INTERNAL_H */
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 9b94495..b000ab8 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -66,8 +66,9 @@ static const VMStateDescription vmstate_ide_isa = {
 static int isa_ide_initfn(ISADevice *dev)
 {
     ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
+    static uint8_t bus_id = 0;
 
-    ide_bus_new(&s->bus, &s->dev.qdev);
+    ide_bus_new(&s->bus, &s->dev.qdev, bus_id++);
     ide_init_ioport(&s->bus, s->iobase, s->iobase2);
     isa_init_irq(dev, &s->irq, s->isairq);
     isa_init_ioport_range(dev, s->iobase, 8);
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 6206201..e56777f 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
     ide_init_ioport(&d->bus[1], 0x170, 0x376);
 
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 336ffe1..220729e 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -29,9 +29,13 @@ static struct BusInfo ide_bus_info = {
     .size  = sizeof(IDEBus),
 };
 
-void ide_bus_new(IDEBus *idebus, DeviceState *dev)
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
 {
-    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
+    char name[10];
+
+    snprintf(name, sizeof(name), "ide.%d", bus_id); 
+    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, name);
+    idebus->bus_id = bus_id;
 }
 
 static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
diff --git a/hw/ide/via.c b/hw/ide/via.c
index b2c7cad..cc48b2b 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
 
     vmstate_register(&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);
+    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
     ide_init2(&d->bus[0], isa_reserve_irq(14));
     ide_init2(&d->bus[1], isa_reserve_irq(15));
     ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 3d07ce5..cec6c9b 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -163,7 +163,7 @@ static void pc_init1(ram_addr_t ram_size,
             ISADevice *dev;
             dev = isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
                                hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
-            idebus[i] = qdev_get_child_bus(&dev->qdev, "ide.0");
+            idebus[i] = qdev_get_child_bus(&dev->qdev, i ? "ide.1" : "ide.0");
         }
     }
 
--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
>> Here's a generic answer to the question "which of the device's buses is
>> this?"
>> 
>> int qbus_index(BusState *bus)
>> {
>>     BusState *b;
>>     int i, index;
>> 
>>     index = -1;
>>     i = 0;
>>     QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
>>         if (b == bus) {
>>             index = i;
>>         }
>>         i++;
>>     }
>>     assert(0 <= index && index < i);
>>     return i - 1 - index;
>> }
>> 
>> The bus created first has index 0.
>> 
>> Note that the child_bus holds the children in reverse creation order,
>> and we can't traverse it backwards.  Same problem also visible with
>> makes info qtree:
>> 
>>       dev: piix3-ide, id ""
>> [...]
>>         bus: ide.1
>>           type IDE
>>         bus: ide.0
>>           type IDE
> Isn't this too implementation dependant?

Well, it's the implementation depending on itself.

>                                          Are you against adding bus_id
> to IDEBus?

"Against" is too hard a word.  If it's a general question, I'd prefer a
general answer.

>            And will it work with ISA? I do not think IDEBus is
> added to bus->parent->child_bus in case of ISA otherwise why both
> IDEBuses have same name in isapc. Currently I have following patch
> queued. It should fix isapc case too.

You're right, it's not helpful there: two separate devices, both
providing just one bus.

>     Fix isapc IDE bus creation
>     
>     Currently we create two ide buses with the same name, so it is impossible
>     to use -device ide-drive,bus= to address all possible disks in the isapc
>     machine. Fix that by giving different names to different ide buses. Also
>     store IDE bus id in IDEBus structure for easy access.

Changing the name of the second default isa-ide device's bus to "ide.1"
is fine with me.

But with that change in place, why do we need to store the bus number?
Why can't we just use the name?

Moreover, I think the meaning of "bus number" is unclear.  See comments
inline.

> diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
> index ff80dd5..b2cbdbc 100644
> --- a/hw/ide/cmd646.c
> +++ b/hw/ide/cmd646.c
> @@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
>      pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
>  
>      irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
> -    ide_bus_new(&d->bus[0], &d->dev.qdev);
> -    ide_bus_new(&d->bus[1], &d->dev.qdev);
> +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>      ide_init2(&d->bus[0], irq[0]);
>      ide_init2(&d->bus[1], irq[1]);
>  
> diff --git a/hw/ide/internal.h b/hw/ide/internal.h
> index 4165543..bde2664 100644
> --- a/hw/ide/internal.h
> +++ b/hw/ide/internal.h
> @@ -448,6 +448,7 @@ struct IDEBus {
>      IDEDevice *slave;
>      BMDMAState *bmdma;
>      IDEState ifs[2];
> +    uint8_t bus_id;

Why is this uint8_t?

>      uint8_t unit;
>      uint8_t cmd;
>      qemu_irq irq;
> @@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
>  void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
>  
>  /* hw/ide/qdev.c */
> -void ide_bus_new(IDEBus *idebus, DeviceState *dev);
> +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
>  IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
>  
>  #endif /* HW_IDE_INTERNAL_H */
> diff --git a/hw/ide/isa.c b/hw/ide/isa.c
> index 9b94495..b000ab8 100644
> --- a/hw/ide/isa.c
> +++ b/hw/ide/isa.c
> @@ -66,8 +66,9 @@ static const VMStateDescription vmstate_ide_isa = {
>  static int isa_ide_initfn(ISADevice *dev)
>  {
>      ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
> +    static uint8_t bus_id = 0;
>  
> -    ide_bus_new(&s->bus, &s->dev.qdev);
> +    ide_bus_new(&s->bus, &s->dev.qdev, bus_id++);
>      ide_init_ioport(&s->bus, s->iobase, s->iobase2);
>      isa_init_irq(dev, &s->irq, s->isairq);
>      isa_init_ioport_range(dev, s->iobase, 8);

Works for any number of isa-ide devices.  Each one provides one IDE bus,
and the buses are numbered 0, ... in the order the isa-ide devices are
created.

> diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> index 6206201..e56777f 100644
> --- a/hw/ide/piix.c
> +++ b/hw/ide/piix.c
> @@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
> +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
>      ide_init_ioport(&d->bus[1], 0x170, 0x376);
>  

Each piix3-ide device provides two IDE buses numbered 0 and 1.

If you create multiple IDE controller devices, then the IDE bus numbers
and names clash, unless they're all isa-ide devices.

What is the IDE bus number supposed to mean?

Example: default piix3-ide plus a tertiary IDE channel
-M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11

> diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> index 336ffe1..220729e 100644
> --- a/hw/ide/qdev.c
> +++ b/hw/ide/qdev.c
> @@ -29,9 +29,13 @@ static struct BusInfo ide_bus_info = {
>      .size  = sizeof(IDEBus),
>  };
>  
> -void ide_bus_new(IDEBus *idebus, DeviceState *dev)
> +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
>  {
> -    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
> +    char name[10];
> +
> +    snprintf(name, sizeof(name), "ide.%d", bus_id); 
> +    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, name);
> +    idebus->bus_id = bus_id;
>  }

Incompatible change.

Before: -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11,id=foo
provides an IDE bus called "foo.0":

          dev: isa-ide, id "foo"
            dev-prop: iobase = 0x1e8
            dev-prop: iobase2 = 0x3ee
            dev-prop: irq = 11
            isa irq 11
            bus: foo.0
              type IDE

After: it's called "ide.0", I think.

Likely to break non-default IDE controller use.  Could be rare enough
for us not to care, I don't know.

If we need to avoid this change, then ide_bus_new() must not pass a bus
name to qbus_create_inplace() for devices added with -device/device_add.

>  
>  static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
> diff --git a/hw/ide/via.c b/hw/ide/via.c
> index b2c7cad..cc48b2b 100644
> --- a/hw/ide/via.c
> +++ b/hw/ide/via.c
> @@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
>  
>      vmstate_register(&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);
> +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>      ide_init2(&d->bus[0], isa_reserve_irq(14));
>      ide_init2(&d->bus[1], isa_reserve_irq(15));
>      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 3d07ce5..cec6c9b 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -163,7 +163,7 @@ static void pc_init1(ram_addr_t ram_size,
>              ISADevice *dev;
>              dev = isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
>                                 hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
> -            idebus[i] = qdev_get_child_bus(&dev->qdev, "ide.0");
> +            idebus[i] = qdev_get_child_bus(&dev->qdev, i ? "ide.1" : "ide.0");
>          }
>      }

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Wed, Nov 03, 2010 at 04:18:18PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
> >> Here's a generic answer to the question "which of the device's buses is
> >> this?"
> >> 
> >> int qbus_index(BusState *bus)
> >> {
> >>     BusState *b;
> >>     int i, index;
> >> 
> >>     index = -1;
> >>     i = 0;
> >>     QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
> >>         if (b == bus) {
> >>             index = i;
> >>         }
> >>         i++;
> >>     }
> >>     assert(0 <= index && index < i);
> >>     return i - 1 - index;
> >> }
> >> 
> >> The bus created first has index 0.
> >> 
> >> Note that the child_bus holds the children in reverse creation order,
> >> and we can't traverse it backwards.  Same problem also visible with
> >> makes info qtree:
> >> 
> >>       dev: piix3-ide, id ""
> >> [...]
> >>         bus: ide.1
> >>           type IDE
> >>         bus: ide.0
> >>           type IDE
> > Isn't this too implementation dependant?
> 
> Well, it's the implementation depending on itself.
> 
In a sense yes, but we expose internal qdev state in upper layer of the
stack. Look like leaking abstraction problem to me. What if we will
change qdev to store child buses in hash instead of list?

> >                                          Are you against adding bus_id
> > to IDEBus?
> 
> "Against" is too hard a word.  If it's a general question, I'd prefer a
> general answer.
It is as general as "what pci slot/func of a pci device". We store those
in PCIDevice.

> 
> >            And will it work with ISA? I do not think IDEBus is
> > added to bus->parent->child_bus in case of ISA otherwise why both
> > IDEBuses have same name in isapc. Currently I have following patch
> > queued. It should fix isapc case too.
> 
> You're right, it's not helpful there: two separate devices, both
> providing just one bus.
> 
> >     Fix isapc IDE bus creation
> >     
> >     Currently we create two ide buses with the same name, so it is impossible
> >     to use -device ide-drive,bus= to address all possible disks in the isapc
> >     machine. Fix that by giving different names to different ide buses. Also
> >     store IDE bus id in IDEBus structure for easy access.
> 
> Changing the name of the second default isa-ide device's bus to "ide.1"
> is fine with me.
> 
> But with that change in place, why do we need to store the bus number?
> Why can't we just use the name?
This name has no meaning outside of qemu internals. I can derive bus
number from bus name by parsing the string, but I don't see why is it
better than storing bus_id (that was used to create this bus name in the
first place) for easy access.

> 
> Moreover, I think the meaning of "bus number" is unclear.  See comments
> inline.
> 
> > diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
> > index ff80dd5..b2cbdbc 100644
> > --- a/hw/ide/cmd646.c
> > +++ b/hw/ide/cmd646.c
> > @@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
> >      pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
> >  
> >      irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
> > -    ide_bus_new(&d->bus[0], &d->dev.qdev);
> > -    ide_bus_new(&d->bus[1], &d->dev.qdev);
> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
> >      ide_init2(&d->bus[0], irq[0]);
> >      ide_init2(&d->bus[1], irq[1]);
> >  
> > diff --git a/hw/ide/internal.h b/hw/ide/internal.h
> > index 4165543..bde2664 100644
> > --- a/hw/ide/internal.h
> > +++ b/hw/ide/internal.h
> > @@ -448,6 +448,7 @@ struct IDEBus {
> >      IDEDevice *slave;
> >      BMDMAState *bmdma;
> >      IDEState ifs[2];
> > +    uint8_t bus_id;
> 
> Why is this uint8_t?
> 
I do not expect to have more then 255 ide buses provided by one device :)

> >      uint8_t unit;
> >      uint8_t cmd;
> >      qemu_irq irq;
> > @@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
> >  void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
> >  
> >  /* hw/ide/qdev.c */
> > -void ide_bus_new(IDEBus *idebus, DeviceState *dev);
> > +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
> >  IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
> >  
> >  #endif /* HW_IDE_INTERNAL_H */
> > diff --git a/hw/ide/isa.c b/hw/ide/isa.c
> > index 9b94495..b000ab8 100644
> > --- a/hw/ide/isa.c
> > +++ b/hw/ide/isa.c
> > @@ -66,8 +66,9 @@ static const VMStateDescription vmstate_ide_isa = {
> >  static int isa_ide_initfn(ISADevice *dev)
> >  {
> >      ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
> > +    static uint8_t bus_id = 0;
> >  
> > -    ide_bus_new(&s->bus, &s->dev.qdev);
> > +    ide_bus_new(&s->bus, &s->dev.qdev, bus_id++);
> >      ide_init_ioport(&s->bus, s->iobase, s->iobase2);
> >      isa_init_irq(dev, &s->irq, s->isairq);
> >      isa_init_ioport_range(dev, s->iobase, 8);
> 
> Works for any number of isa-ide devices.  Each one provides one IDE bus,
> and the buses are numbered 0, ... in the order the isa-ide devices are
> created.
> 
Except that we use those names to address device on command line. And 
this is very unfortunate since now we can't address all ide devices in
isapc case and in the future we can have same problem with other kind of
devices. Actually adding such way may be better solution then what I did
in this patch.

> > diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> > index 6206201..e56777f 100644
> > --- a/hw/ide/piix.c
> > +++ b/hw/ide/piix.c
> > @@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
> >      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
> >      ide_init_ioport(&d->bus[1], 0x170, 0x376);
> >  
> 
> Each piix3-ide device provides two IDE buses numbered 0 and 1.
> 
> If you create multiple IDE controller devices, then the IDE bus numbers
> and names clash, unless they're all isa-ide devices.
> 
> What is the IDE bus number supposed to mean?
Bus number on parent bus. I don't care if name clashes since device
that provide those IDE buses will have different names.

> 
> Example: default piix3-ide plus a tertiary IDE channel
> -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11
Here are the device names my patch produces (for pci ide disks one
virtio and one isa-ide:

/pci@i0cf8/ata@1,1/ide@0/disk@0
/pci@i0cf8/ata@1,1/ide@0/disk@1
/pci@i0cf8/ata@1,1/ide@1/disk@0
/pci@i0cf8/ata@1,1/ide@1/disk@1
/pci@i0cf8/virtio-blk@3/disk@0
/pci@i0cf8/pci-isa-bridge@1/ata@01e8/ide@0/disk@0

As you can see there is no name clashes at all. Each device has device
name that can be used to identify it in firmware.

> 
> > diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> > index 336ffe1..220729e 100644
> > --- a/hw/ide/qdev.c
> > +++ b/hw/ide/qdev.c
> > @@ -29,9 +29,13 @@ static struct BusInfo ide_bus_info = {
> >      .size  = sizeof(IDEBus),
> >  };
> >  
> > -void ide_bus_new(IDEBus *idebus, DeviceState *dev)
> > +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
> >  {
> > -    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
> > +    char name[10];
> > +
> > +    snprintf(name, sizeof(name), "ide.%d", bus_id); 
> > +    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, name);
> > +    idebus->bus_id = bus_id;
> >  }
> 
> Incompatible change.
> 
> Before: -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11,id=foo
> provides an IDE bus called "foo.0":
> 
>           dev: isa-ide, id "foo"
>             dev-prop: iobase = 0x1e8
>             dev-prop: iobase2 = 0x3ee
>             dev-prop: irq = 11
>             isa irq 11
>             bus: foo.0
>               type IDE
> 
> After: it's called "ide.0", I think.
> 
snprintf(name, sizeof(name), "%s.%d", dev->id ? : "ide", bus_id);
will take care of it. But I am starting to think that this is indeed not
needed. Without the change my patch produce name like that in isapc case:
/isa/ata@01f0/ide@0/disk@0
/isa/ata@01f0/ide@0/disk@1
/isa/ata@0170/ide@0/disk@0
/isa/ata@0170/ide@0/disk@1

so the paths are unique and usable by firmware. The only problem is that
not all disks are addressable from -device option, so I can't set
bootindex on some of them.


> Likely to break non-default IDE controller use.  Could be rare enough
> for us not to care, I don't know.
> 
> If we need to avoid this change, then ide_bus_new() must not pass a bus
> name to qbus_create_inplace() for devices added with -device/device_add.
> 
> >  
> >  static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
> > diff --git a/hw/ide/via.c b/hw/ide/via.c
> > index b2c7cad..cc48b2b 100644
> > --- a/hw/ide/via.c
> > +++ b/hw/ide/via.c
> > @@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
> >  
> >      vmstate_register(&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);
> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
> >      ide_init2(&d->bus[0], isa_reserve_irq(14));
> >      ide_init2(&d->bus[1], isa_reserve_irq(15));
> >      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > index 3d07ce5..cec6c9b 100644
> > --- a/hw/pc_piix.c
> > +++ b/hw/pc_piix.c
> > @@ -163,7 +163,7 @@ static void pc_init1(ram_addr_t ram_size,
> >              ISADevice *dev;
> >              dev = isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
> >                                 hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
> > -            idebus[i] = qdev_get_child_bus(&dev->qdev, "ide.0");
> > +            idebus[i] = qdev_get_child_bus(&dev->qdev, i ? "ide.1" : "ide.0");
> >          }
> >      }

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Wed, Nov 03, 2010 at 04:18:18PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
>> >> Here's a generic answer to the question "which of the device's buses is
>> >> this?"
>> >> 
>> >> int qbus_index(BusState *bus)
>> >> {
>> >>     BusState *b;
>> >>     int i, index;
>> >> 
>> >>     index = -1;
>> >>     i = 0;
>> >>     QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
>> >>         if (b == bus) {
>> >>             index = i;
>> >>         }
>> >>         i++;
>> >>     }
>> >>     assert(0 <= index && index < i);
>> >>     return i - 1 - index;
>> >> }
>> >> 
>> >> The bus created first has index 0.
>> >> 
>> >> Note that the child_bus holds the children in reverse creation order,
>> >> and we can't traverse it backwards.  Same problem also visible with
>> >> makes info qtree:
>> >> 
>> >>       dev: piix3-ide, id ""
>> >> [...]
>> >>         bus: ide.1
>> >>           type IDE
>> >>         bus: ide.0
>> >>           type IDE
>> > Isn't this too implementation dependant?
>> 
>> Well, it's the implementation depending on itself.
>> 
> In a sense yes, but we expose internal qdev state in upper layer of the
> stack. Look like leaking abstraction problem to me. What if we will
> change qdev to store child buses in hash instead of list?

The function is defined in terms of the qdev interface: it depends only
on the order in which the parent device's buses are created.  The fact
that my implementation happens to depend on how we store child buses
doesn't change that.

>> >                                          Are you against adding bus_id
>> > to IDEBus?
>> 
>> "Against" is too hard a word.  If it's a general question, I'd prefer a
>> general answer.
> It is as general as "what pci slot/func of a pci device". We store those
> in PCIDevice.

It's actually more general than that :)

PCI slot.function is the address of a PCI device on its parent bus.
It's specific to PCI buses.

The bus number is the "address" of a bus on its parent device.  It's the
same regardless of the device.

>> >            And will it work with ISA? I do not think IDEBus is
>> > added to bus->parent->child_bus in case of ISA otherwise why both
>> > IDEBuses have same name in isapc. Currently I have following patch
>> > queued. It should fix isapc case too.
>> 
>> You're right, it's not helpful there: two separate devices, both
>> providing just one bus.
>> 
>> >     Fix isapc IDE bus creation
>> >     
>> >     Currently we create two ide buses with the same name, so it is impossible
>> >     to use -device ide-drive,bus= to address all possible disks in the isapc
>> >     machine. Fix that by giving different names to different ide buses. Also
>> >     store IDE bus id in IDEBus structure for easy access.
>> 
>> Changing the name of the second default isa-ide device's bus to "ide.1"
>> is fine with me.
>> 
>> But with that change in place, why do we need to store the bus number?
>> Why can't we just use the name?
> This name has no meaning outside of qemu internals. I can derive bus
> number from bus name by parsing the string, but I don't see why is it
> better than storing bus_id (that was used to create this bus name in the
> first place) for easy access.
>
>> 
>> Moreover, I think the meaning of "bus number" is unclear.  See comments
>> inline.
>> 
>> > diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
>> > index ff80dd5..b2cbdbc 100644
>> > --- a/hw/ide/cmd646.c
>> > +++ b/hw/ide/cmd646.c
>> > @@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
>> >      pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
>> >  
>> >      irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
>> > -    ide_bus_new(&d->bus[0], &d->dev.qdev);
>> > -    ide_bus_new(&d->bus[1], &d->dev.qdev);
>> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
>> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>> >      ide_init2(&d->bus[0], irq[0]);
>> >      ide_init2(&d->bus[1], irq[1]);
>> >  
>> > diff --git a/hw/ide/internal.h b/hw/ide/internal.h
>> > index 4165543..bde2664 100644
>> > --- a/hw/ide/internal.h
>> > +++ b/hw/ide/internal.h
>> > @@ -448,6 +448,7 @@ struct IDEBus {
>> >      IDEDevice *slave;
>> >      BMDMAState *bmdma;
>> >      IDEState ifs[2];
>> > +    uint8_t bus_id;
>> 
>> Why is this uint8_t?
>> 
> I do not expect to have more then 255 ide buses provided by one device :)

Bah, let's make it an int.

>> >      uint8_t unit;
>> >      uint8_t cmd;
>> >      qemu_irq irq;
>> > @@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
>> >  void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
>> >  
>> >  /* hw/ide/qdev.c */
>> > -void ide_bus_new(IDEBus *idebus, DeviceState *dev);
>> > +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
>> >  IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
>> >  
>> >  #endif /* HW_IDE_INTERNAL_H */
>> > diff --git a/hw/ide/isa.c b/hw/ide/isa.c
>> > index 9b94495..b000ab8 100644
>> > --- a/hw/ide/isa.c
>> > +++ b/hw/ide/isa.c
>> > @@ -66,8 +66,9 @@ static const VMStateDescription vmstate_ide_isa = {
>> >  static int isa_ide_initfn(ISADevice *dev)
>> >  {
>> >      ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
>> > +    static uint8_t bus_id = 0;
>> >  
>> > -    ide_bus_new(&s->bus, &s->dev.qdev);
>> > +    ide_bus_new(&s->bus, &s->dev.qdev, bus_id++);
>> >      ide_init_ioport(&s->bus, s->iobase, s->iobase2);
>> >      isa_init_irq(dev, &s->irq, s->isairq);
>> >      isa_init_ioport_range(dev, s->iobase, 8);
>> 
>> Works for any number of isa-ide devices.  Each one provides one IDE bus,
>> and the buses are numbered 0, ... in the order the isa-ide devices are
>> created.
>> 
> Except that we use those names to address device on command line. And 
> this is very unfortunate since now we can't address all ide devices in
> isapc case and in the future we can have same problem with other kind of
> devices. Actually adding such way may be better solution then what I did
> in this patch.
>
>> > diff --git a/hw/ide/piix.c b/hw/ide/piix.c
>> > index 6206201..e56777f 100644
>> > --- a/hw/ide/piix.c
>> > +++ b/hw/ide/piix.c
>> > @@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
>> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
>> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>> >      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
>> >      ide_init_ioport(&d->bus[1], 0x170, 0x376);
>> >  
>> 
>> Each piix3-ide device provides two IDE buses numbered 0 and 1.
>> 
>> If you create multiple IDE controller devices, then the IDE bus numbers
>> and names clash, unless they're all isa-ide devices.
>> 
>> What is the IDE bus number supposed to mean?
> Bus number on parent bus. I don't care if name clashes since device
> that provide those IDE buses will have different names.

Bus number on parent *bus*?  Not parent *device*?

If you mean bus number on parent device, then your code for isa-ide is
wrong.  Each isa-ide device provides one bus.  By your definition, its
bus number must be 0.

If you mean bus number on parent bus, and by parent bus you mean the
parent device's parent bus, then your code for PCI IDE controllers such
as piix3-ide is wrong.

Please define bus number clearly.  Be verbose if you have to.  We've
been running in circles all this time in part because we miscommunicate/
misunderstand basic definitions such as bus number.

>> Example: default piix3-ide plus a tertiary IDE channel
>> -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11
> Here are the device names my patch produces (for pci ide disks one
> virtio and one isa-ide:
>
> /pci@i0cf8/ata@1,1/ide@0/disk@0
> /pci@i0cf8/ata@1,1/ide@0/disk@1
> /pci@i0cf8/ata@1,1/ide@1/disk@0
> /pci@i0cf8/ata@1,1/ide@1/disk@1
> /pci@i0cf8/virtio-blk@3/disk@0
> /pci@i0cf8/pci-isa-bridge@1/ata@01e8/ide@0/disk@0
>
> As you can see there is no name clashes at all. Each device has device
> name that can be used to identify it in firmware.
>
>> 
>> > diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
>> > index 336ffe1..220729e 100644
>> > --- a/hw/ide/qdev.c
>> > +++ b/hw/ide/qdev.c
>> > @@ -29,9 +29,13 @@ static struct BusInfo ide_bus_info = {
>> >      .size  = sizeof(IDEBus),
>> >  };
>> >  
>> > -void ide_bus_new(IDEBus *idebus, DeviceState *dev)
>> > +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
>> >  {
>> > -    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
>> > +    char name[10];
>> > +
>> > +    snprintf(name, sizeof(name), "ide.%d", bus_id); 
>> > +    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, name);
>> > +    idebus->bus_id = bus_id;
>> >  }
>> 
>> Incompatible change.
>> 
>> Before: -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11,id=foo
>> provides an IDE bus called "foo.0":
>> 
>>           dev: isa-ide, id "foo"
>>             dev-prop: iobase = 0x1e8
>>             dev-prop: iobase2 = 0x3ee
>>             dev-prop: irq = 11
>>             isa irq 11
>>             bus: foo.0
>>               type IDE
>> 
>> After: it's called "ide.0", I think.
>> 
> snprintf(name, sizeof(name), "%s.%d", dev->id ? : "ide", bus_id);
> will take care of it.

Not fully.

-M pc
-device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11,id=foo
-device isa-ide,iobase=0x168,iobase2=0x36e,irq=10,id=bar

Before: foo.0 and bar.0
After: foo.0 and bar.1

>                       But I am starting to think that this is indeed not
> needed. Without the change my patch produce name like that in isapc case:
> /isa/ata@01f0/ide@0/disk@0
> /isa/ata@01f0/ide@0/disk@1
> /isa/ata@0170/ide@0/disk@0
> /isa/ata@0170/ide@0/disk@1
>
> so the paths are unique and usable by firmware. The only problem is that
> not all disks are addressable from -device option, so I can't set
> bootindex on some of them.

Perhaps we can treat the non-addressability of -M isapc's second IDE bus
as a separate problem.

>> Likely to break non-default IDE controller use.  Could be rare enough
>> for us not to care, I don't know.
>> 
>> If we need to avoid this change, then ide_bus_new() must not pass a bus
>> name to qbus_create_inplace() for devices added with -device/device_add.
>> 
>> >  
>> >  static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
>> > diff --git a/hw/ide/via.c b/hw/ide/via.c
>> > index b2c7cad..cc48b2b 100644
>> > --- a/hw/ide/via.c
>> > +++ b/hw/ide/via.c
>> > @@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
>> >  
>> >      vmstate_register(&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);
>> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
>> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>> >      ide_init2(&d->bus[0], isa_reserve_irq(14));
>> >      ide_init2(&d->bus[1], isa_reserve_irq(15));
>> >      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
>> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
>> > index 3d07ce5..cec6c9b 100644
>> > --- a/hw/pc_piix.c
>> > +++ b/hw/pc_piix.c
>> > @@ -163,7 +163,7 @@ static void pc_init1(ram_addr_t ram_size,
>> >              ISADevice *dev;
>> >              dev = isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
>> >                                 hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
>> > -            idebus[i] = qdev_get_child_bus(&dev->qdev, "ide.0");
>> > +            idebus[i] = qdev_get_child_bus(&dev->qdev, i ? "ide.1" : "ide.0");
>> >          }
>> >      }

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Wed, Nov 03, 2010 at 06:22:11PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Wed, Nov 03, 2010 at 04:18:18PM +0100, Markus Armbruster wrote:
> >> Gleb Natapov <gleb@redhat.com> writes:
> >> 
> >> > On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
> >> >> Here's a generic answer to the question "which of the device's buses is
> >> >> this?"
> >> >> 
> >> >> int qbus_index(BusState *bus)
> >> >> {
> >> >>     BusState *b;
> >> >>     int i, index;
> >> >> 
> >> >>     index = -1;
> >> >>     i = 0;
> >> >>     QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
> >> >>         if (b == bus) {
> >> >>             index = i;
> >> >>         }
> >> >>         i++;
> >> >>     }
> >> >>     assert(0 <= index && index < i);
> >> >>     return i - 1 - index;
> >> >> }
> >> >> 
> >> >> The bus created first has index 0.
> >> >> 
> >> >> Note that the child_bus holds the children in reverse creation order,
> >> >> and we can't traverse it backwards.  Same problem also visible with
> >> >> makes info qtree:
> >> >> 
> >> >>       dev: piix3-ide, id ""
> >> >> [...]
> >> >>         bus: ide.1
> >> >>           type IDE
> >> >>         bus: ide.0
> >> >>           type IDE
> >> > Isn't this too implementation dependant?
> >> 
> >> Well, it's the implementation depending on itself.
> >> 
> > In a sense yes, but we expose internal qdev state in upper layer of the
> > stack. Look like leaking abstraction problem to me. What if we will
> > change qdev to store child buses in hash instead of list?
> 
> The function is defined in terms of the qdev interface: it depends only
> on the order in which the parent device's buses are created.  The fact
> that my implementation happens to depend on how we store child buses
> doesn't change that.
> 
But why order of device creation is important? It shouldn't be if we
want to move HW description into config file. We even may allow creating
piix3-ide with only second IDE bus, but not first.


> >> >                                          Are you against adding bus_id
> >> > to IDEBus?
> >> 
> >> "Against" is too hard a word.  If it's a general question, I'd prefer a
> >> general answer.
> > It is as general as "what pci slot/func of a pci device". We store those
> > in PCIDevice.
> 
> It's actually more general than that :)
> 
> PCI slot.function is the address of a PCI device on its parent bus.
> It's specific to PCI buses.
> 
> The bus number is the "address" of a bus on its parent device.  It's the
> same regardless of the device.
> 
In case of IDE bus siting on piix3-ide it is not just arbitrary number
like you suggest here. It actually tells how to talk to a device. IDE
bus 0 is reachable through BAR0,1 of piix3-ide and IDE bus 1 is reachable
through BAR2,3. So this number is part of the device address as much as
pci slot/func is.


> >> >            And will it work with ISA? I do not think IDEBus is
> >> > added to bus->parent->child_bus in case of ISA otherwise why both
> >> > IDEBuses have same name in isapc. Currently I have following patch
> >> > queued. It should fix isapc case too.
> >> 
> >> You're right, it's not helpful there: two separate devices, both
> >> providing just one bus.
> >> 
> >> >     Fix isapc IDE bus creation
> >> >     
> >> >     Currently we create two ide buses with the same name, so it is impossible
> >> >     to use -device ide-drive,bus= to address all possible disks in the isapc
> >> >     machine. Fix that by giving different names to different ide buses. Also
> >> >     store IDE bus id in IDEBus structure for easy access.
> >> 
> >> Changing the name of the second default isa-ide device's bus to "ide.1"
> >> is fine with me.
> >> 
> >> But with that change in place, why do we need to store the bus number?
> >> Why can't we just use the name?
> > This name has no meaning outside of qemu internals. I can derive bus
> > number from bus name by parsing the string, but I don't see why is it
> > better than storing bus_id (that was used to create this bus name in the
> > first place) for easy access.
> >
> >> 
> >> Moreover, I think the meaning of "bus number" is unclear.  See comments
> >> inline.
> >> 
> >> > diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
> >> > index ff80dd5..b2cbdbc 100644
> >> > --- a/hw/ide/cmd646.c
> >> > +++ b/hw/ide/cmd646.c
> >> > @@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
> >> >      pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
> >> >  
> >> >      irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
> >> > -    ide_bus_new(&d->bus[0], &d->dev.qdev);
> >> > -    ide_bus_new(&d->bus[1], &d->dev.qdev);
> >> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> >> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
> >> >      ide_init2(&d->bus[0], irq[0]);
> >> >      ide_init2(&d->bus[1], irq[1]);
> >> >  
> >> > diff --git a/hw/ide/internal.h b/hw/ide/internal.h
> >> > index 4165543..bde2664 100644
> >> > --- a/hw/ide/internal.h
> >> > +++ b/hw/ide/internal.h
> >> > @@ -448,6 +448,7 @@ struct IDEBus {
> >> >      IDEDevice *slave;
> >> >      BMDMAState *bmdma;
> >> >      IDEState ifs[2];
> >> > +    uint8_t bus_id;
> >> 
> >> Why is this uint8_t?
> >> 
> > I do not expect to have more then 255 ide buses provided by one device :)
> 
> Bah, let's make it an int.
OK.

> 
> >> >      uint8_t unit;
> >> >      uint8_t cmd;
> >> >      qemu_irq irq;
> >> > @@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
> >> >  void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
> >> >  
> >> >  /* hw/ide/qdev.c */
> >> > -void ide_bus_new(IDEBus *idebus, DeviceState *dev);
> >> > +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
> >> >  IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
> >> >  
> >> >  #endif /* HW_IDE_INTERNAL_H */
> >> > diff --git a/hw/ide/isa.c b/hw/ide/isa.c
> >> > index 9b94495..b000ab8 100644
> >> > --- a/hw/ide/isa.c
> >> > +++ b/hw/ide/isa.c
> >> > @@ -66,8 +66,9 @@ static const VMStateDescription vmstate_ide_isa = {
> >> >  static int isa_ide_initfn(ISADevice *dev)
> >> >  {
> >> >      ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
> >> > +    static uint8_t bus_id = 0;
> >> >  
> >> > -    ide_bus_new(&s->bus, &s->dev.qdev);
> >> > +    ide_bus_new(&s->bus, &s->dev.qdev, bus_id++);
> >> >      ide_init_ioport(&s->bus, s->iobase, s->iobase2);
> >> >      isa_init_irq(dev, &s->irq, s->isairq);
> >> >      isa_init_ioport_range(dev, s->iobase, 8);
> >> 
> >> Works for any number of isa-ide devices.  Each one provides one IDE bus,
> >> and the buses are numbered 0, ... in the order the isa-ide devices are
> >> created.
> >> 
> > Except that we use those names to address device on command line. And 
> > this is very unfortunate since now we can't address all ide devices in
> > isapc case and in the future we can have same problem with other kind of
> > devices. Actually adding such way may be better solution then what I did
> > in this patch.
> >
> >> > diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> >> > index 6206201..e56777f 100644
> >> > --- a/hw/ide/piix.c
> >> > +++ b/hw/ide/piix.c
> >> > @@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
> >> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> >> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
> >> >      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
> >> >      ide_init_ioport(&d->bus[1], 0x170, 0x376);
> >> >  
> >> 
> >> Each piix3-ide device provides two IDE buses numbered 0 and 1.
> >> 
> >> If you create multiple IDE controller devices, then the IDE bus numbers
> >> and names clash, unless they're all isa-ide devices.
> >> 
> >> What is the IDE bus number supposed to mean?
> > Bus number on parent bus. I don't care if name clashes since device
> > that provide those IDE buses will have different names.
> 
> Bus number on parent *bus*?  Not parent *device*?
> 
On parent device.

> If you mean bus number on parent device, then your code for isa-ide is
> wrong.  Each isa-ide device provides one bus.  By your definition, its
> bus number must be 0.
> 
> If you mean bus number on parent bus, and by parent bus you mean the
> parent device's parent bus, then your code for PCI IDE controllers such
> as piix3-ide is wrong.
> 
> Please define bus number clearly.  Be verbose if you have to.  We've
> been running in circles all this time in part because we miscommunicate/
> misunderstand basic definitions such as bus number.
> 
I agree it is conceptually wrong. It is not even needed for unique device
path generation. It is only needed to make both IDE buses configurable
from command line in ISA machine. I'll drop it in favor of other solution,
but qdev has to rethink how devices should it addressable from command
line. Current way is broken.

> >> Example: default piix3-ide plus a tertiary IDE channel
> >> -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11
> > Here are the device names my patch produces (for pci ide disks one
> > virtio and one isa-ide:
> >
> > /pci@i0cf8/ata@1,1/ide@0/disk@0
> > /pci@i0cf8/ata@1,1/ide@0/disk@1
> > /pci@i0cf8/ata@1,1/ide@1/disk@0
> > /pci@i0cf8/ata@1,1/ide@1/disk@1
> > /pci@i0cf8/virtio-blk@3/disk@0
> > /pci@i0cf8/pci-isa-bridge@1/ata@01e8/ide@0/disk@0
> >
> > As you can see there is no name clashes at all. Each device has device
> > name that can be used to identify it in firmware.
> >
> >> 
> >> > diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> >> > index 336ffe1..220729e 100644
> >> > --- a/hw/ide/qdev.c
> >> > +++ b/hw/ide/qdev.c
> >> > @@ -29,9 +29,13 @@ static struct BusInfo ide_bus_info = {
> >> >      .size  = sizeof(IDEBus),
> >> >  };
> >> >  
> >> > -void ide_bus_new(IDEBus *idebus, DeviceState *dev)
> >> > +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
> >> >  {
> >> > -    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
> >> > +    char name[10];
> >> > +
> >> > +    snprintf(name, sizeof(name), "ide.%d", bus_id); 
> >> > +    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, name);
> >> > +    idebus->bus_id = bus_id;
> >> >  }
> >> 
> >> Incompatible change.
> >> 
> >> Before: -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11,id=foo
> >> provides an IDE bus called "foo.0":
> >> 
> >>           dev: isa-ide, id "foo"
> >>             dev-prop: iobase = 0x1e8
> >>             dev-prop: iobase2 = 0x3ee
> >>             dev-prop: irq = 11
> >>             isa irq 11
> >>             bus: foo.0
> >>               type IDE
> >> 
> >> After: it's called "ide.0", I think.
> >> 
> > snprintf(name, sizeof(name), "%s.%d", dev->id ? : "ide", bus_id);
> > will take care of it.
> 
> Not fully.
> 
> -M pc
> -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11,id=foo
> -device isa-ide,iobase=0x168,iobase2=0x36e,irq=10,id=bar
> 
> Before: foo.0 and bar.0
> After: foo.0 and bar.1
> 
> >                       But I am starting to think that this is indeed not
> > needed. Without the change my patch produce name like that in isapc case:
> > /isa/ata@01f0/ide@0/disk@0
> > /isa/ata@01f0/ide@0/disk@1
> > /isa/ata@0170/ide@0/disk@0
> > /isa/ata@0170/ide@0/disk@1
> >
> > so the paths are unique and usable by firmware. The only problem is that
> > not all disks are addressable from -device option, so I can't set
> > bootindex on some of them.
> 
> Perhaps we can treat the non-addressability of -M isapc's second IDE bus
> as a separate problem.
> 
Agree, hence I will not use this patch and will get back to just
recording bus_id. But -M isapc is just a symptom of much more serious
problem in qdev. The way devices addressable there is not well defined.
Two devices may have the same device path. Ultimately I think qdev
should use device addresses similar to what I am trying to achieve here.
For ISA machine it should automatically generate ids like isa-ide@0x170
for first isa IDE controller and isa-ide@0x1f0 for second one. And get
rid of user assigned ids. They are good for nothing and exist only
because qdev developer didn't agree on how to name devices.

> >> Likely to break non-default IDE controller use.  Could be rare enough
> >> for us not to care, I don't know.
> >> 
> >> If we need to avoid this change, then ide_bus_new() must not pass a bus
> >> name to qbus_create_inplace() for devices added with -device/device_add.
> >> 
> >> >  
> >> >  static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
> >> > diff --git a/hw/ide/via.c b/hw/ide/via.c
> >> > index b2c7cad..cc48b2b 100644
> >> > --- a/hw/ide/via.c
> >> > +++ b/hw/ide/via.c
> >> > @@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
> >> >  
> >> >      vmstate_register(&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);
> >> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
> >> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
> >> >      ide_init2(&d->bus[0], isa_reserve_irq(14));
> >> >      ide_init2(&d->bus[1], isa_reserve_irq(15));
> >> >      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
> >> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> >> > index 3d07ce5..cec6c9b 100644
> >> > --- a/hw/pc_piix.c
> >> > +++ b/hw/pc_piix.c
> >> > @@ -163,7 +163,7 @@ static void pc_init1(ram_addr_t ram_size,
> >> >              ISADevice *dev;
> >> >              dev = isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
> >> >                                 hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
> >> > -            idebus[i] = qdev_get_child_bus(&dev->qdev, "ide.0");
> >> > +            idebus[i] = qdev_get_child_bus(&dev->qdev, i ? "ide.1" : "ide.0");
> >> >          }
> >> >      }

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Wed, Nov 03, 2010 at 06:22:11PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > On Wed, Nov 03, 2010 at 04:18:18PM +0100, Markus Armbruster wrote:
>> >> Gleb Natapov <gleb@redhat.com> writes:
>> >> 
>> >> > On Wed, Nov 03, 2010 at 02:39:52PM +0100, Markus Armbruster wrote:
>> >> >> Here's a generic answer to the question "which of the device's buses is
>> >> >> this?"
>> >> >> 
>> >> >> int qbus_index(BusState *bus)
>> >> >> {
>> >> >>     BusState *b;
>> >> >>     int i, index;
>> >> >> 
>> >> >>     index = -1;
>> >> >>     i = 0;
>> >> >>     QLIST_FOREACH(b, &bus->parent->child_bus, sibling) {
>> >> >>         if (b == bus) {
>> >> >>             index = i;
>> >> >>         }
>> >> >>         i++;
>> >> >>     }
>> >> >>     assert(0 <= index && index < i);
>> >> >>     return i - 1 - index;
>> >> >> }
>> >> >> 
>> >> >> The bus created first has index 0.
>> >> >> 
>> >> >> Note that the child_bus holds the children in reverse creation order,
>> >> >> and we can't traverse it backwards.  Same problem also visible with
>> >> >> makes info qtree:
>> >> >> 
>> >> >>       dev: piix3-ide, id ""
>> >> >> [...]
>> >> >>         bus: ide.1
>> >> >>           type IDE
>> >> >>         bus: ide.0
>> >> >>           type IDE
>> >> > Isn't this too implementation dependant?
>> >> 
>> >> Well, it's the implementation depending on itself.
>> >> 
>> > In a sense yes, but we expose internal qdev state in upper layer of the
>> > stack. Look like leaking abstraction problem to me. What if we will
>> > change qdev to store child buses in hash instead of list?
>> 
>> The function is defined in terms of the qdev interface: it depends only
>> on the order in which the parent device's buses are created.  The fact
>> that my implementation happens to depend on how we store child buses
>> doesn't change that.
>> 
> But why order of device creation is important? It shouldn't be if we
> want to move HW description into config file. We even may allow creating
> piix3-ide with only second IDE bus, but not first.

That's not how buses work in qdev.

Configuration file, command line and monitor configure *devices*.
Devices need to be created after the device providing their parent bus,
obviously.  Other than that, order should not matter.

Buses are always created by device model code.  Thus, creation order is
fixed in code.  Thus defining bus number in terms of creation order is
fine.

If we create piix3-ide with only the second bus (for the sake of
argument), then its bus number is zero by definition, as clarified by
you below.  Unless you want to amend your definition :)

>> >> >                                          Are you against adding bus_id
>> >> > to IDEBus?
>> >> 
>> >> "Against" is too hard a word.  If it's a general question, I'd prefer a
>> >> general answer.
>> > It is as general as "what pci slot/func of a pci device". We store those
>> > in PCIDevice.
>> 
>> It's actually more general than that :)
>> 
>> PCI slot.function is the address of a PCI device on its parent bus.
>> It's specific to PCI buses.
>> 
>> The bus number is the "address" of a bus on its parent device.  It's the
>> same regardless of the device.
>> 
> In case of IDE bus siting on piix3-ide it is not just arbitrary number
> like you suggest here. It actually tells how to talk to a device. IDE
> bus 0 is reachable through BAR0,1 of piix3-ide and IDE bus 1 is reachable
> through BAR2,3. So this number is part of the device address as much as
> pci slot/func is.

What I mean to say: regardless of what the device is, or what kind of
buses it provides, the buses can *always* be identified the same way:
define an order, identify bus by ordinal number.

Because of that, I believe the concept "bus number" should be a generic
qdev concept, not special to IDE buses.

>> >> >            And will it work with ISA? I do not think IDEBus is
>> >> > added to bus->parent->child_bus in case of ISA otherwise why both
>> >> > IDEBuses have same name in isapc. Currently I have following patch
>> >> > queued. It should fix isapc case too.
>> >> 
>> >> You're right, it's not helpful there: two separate devices, both
>> >> providing just one bus.
>> >> 
>> >> >     Fix isapc IDE bus creation
>> >> >     
>> >> >     Currently we create two ide buses with the same name, so it is impossible
>> >> >     to use -device ide-drive,bus= to address all possible disks in the isapc
>> >> >     machine. Fix that by giving different names to different ide buses. Also
>> >> >     store IDE bus id in IDEBus structure for easy access.
>> >> 
>> >> Changing the name of the second default isa-ide device's bus to "ide.1"
>> >> is fine with me.
>> >> 
>> >> But with that change in place, why do we need to store the bus number?
>> >> Why can't we just use the name?
>> > This name has no meaning outside of qemu internals. I can derive bus
>> > number from bus name by parsing the string, but I don't see why is it
>> > better than storing bus_id (that was used to create this bus name in the
>> > first place) for easy access.
>> >
>> >> 
>> >> Moreover, I think the meaning of "bus number" is unclear.  See comments
>> >> inline.
>> >> 
>> >> > diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
>> >> > index ff80dd5..b2cbdbc 100644
>> >> > --- a/hw/ide/cmd646.c
>> >> > +++ b/hw/ide/cmd646.c
>> >> > @@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
>> >> >      pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
>> >> >  
>> >> >      irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
>> >> > -    ide_bus_new(&d->bus[0], &d->dev.qdev);
>> >> > -    ide_bus_new(&d->bus[1], &d->dev.qdev);
>> >> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
>> >> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>> >> >      ide_init2(&d->bus[0], irq[0]);
>> >> >      ide_init2(&d->bus[1], irq[1]);
>> >> >  
>> >> > diff --git a/hw/ide/internal.h b/hw/ide/internal.h
>> >> > index 4165543..bde2664 100644
>> >> > --- a/hw/ide/internal.h
>> >> > +++ b/hw/ide/internal.h
>> >> > @@ -448,6 +448,7 @@ struct IDEBus {
>> >> >      IDEDevice *slave;
>> >> >      BMDMAState *bmdma;
>> >> >      IDEState ifs[2];
>> >> > +    uint8_t bus_id;
>> >> 
>> >> Why is this uint8_t?
>> >> 
>> > I do not expect to have more then 255 ide buses provided by one device :)
>> 
>> Bah, let's make it an int.
> OK.
>
>> 
>> >> >      uint8_t unit;
>> >> >      uint8_t cmd;
>> >> >      qemu_irq irq;
>> >> > @@ -564,7 +565,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
>> >> >  void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
>> >> >  
>> >> >  /* hw/ide/qdev.c */
>> >> > -void ide_bus_new(IDEBus *idebus, DeviceState *dev);
>> >> > +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id);
>> >> >  IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
>> >> >  
>> >> >  #endif /* HW_IDE_INTERNAL_H */
>> >> > diff --git a/hw/ide/isa.c b/hw/ide/isa.c
>> >> > index 9b94495..b000ab8 100644
>> >> > --- a/hw/ide/isa.c
>> >> > +++ b/hw/ide/isa.c
>> >> > @@ -66,8 +66,9 @@ static const VMStateDescription vmstate_ide_isa = {
>> >> >  static int isa_ide_initfn(ISADevice *dev)
>> >> >  {
>> >> >      ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
>> >> > +    static uint8_t bus_id = 0;
>> >> >  
>> >> > -    ide_bus_new(&s->bus, &s->dev.qdev);
>> >> > +    ide_bus_new(&s->bus, &s->dev.qdev, bus_id++);
>> >> >      ide_init_ioport(&s->bus, s->iobase, s->iobase2);
>> >> >      isa_init_irq(dev, &s->irq, s->isairq);
>> >> >      isa_init_ioport_range(dev, s->iobase, 8);
>> >> 
>> >> Works for any number of isa-ide devices.  Each one provides one IDE bus,
>> >> and the buses are numbered 0, ... in the order the isa-ide devices are
>> >> created.
>> >> 
>> > Except that we use those names to address device on command line. And 
>> > this is very unfortunate since now we can't address all ide devices in
>> > isapc case and in the future we can have same problem with other kind of
>> > devices. Actually adding such way may be better solution then what I did
>> > in this patch.
>> >
>> >> > diff --git a/hw/ide/piix.c b/hw/ide/piix.c
>> >> > index 6206201..e56777f 100644
>> >> > --- a/hw/ide/piix.c
>> >> > +++ b/hw/ide/piix.c
>> >> > @@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *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);
>> >> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
>> >> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>> >> >      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
>> >> >      ide_init_ioport(&d->bus[1], 0x170, 0x376);
>> >> >  
>> >> 
>> >> Each piix3-ide device provides two IDE buses numbered 0 and 1.
>> >> 
>> >> If you create multiple IDE controller devices, then the IDE bus numbers
>> >> and names clash, unless they're all isa-ide devices.
>> >> 
>> >> What is the IDE bus number supposed to mean?
>> > Bus number on parent bus. I don't care if name clashes since device
>> > that provide those IDE buses will have different names.
>> 
>> Bus number on parent *bus*?  Not parent *device*?
>> 
> On parent device.

Makes sense to me.

>> If you mean bus number on parent device, then your code for isa-ide is
>> wrong.  Each isa-ide device provides one bus.  By your definition, its
>> bus number must be 0.
>> 
>> If you mean bus number on parent bus, and by parent bus you mean the
>> parent device's parent bus, then your code for PCI IDE controllers such
>> as piix3-ide is wrong.
>> 
>> Please define bus number clearly.  Be verbose if you have to.  We've
>> been running in circles all this time in part because we miscommunicate/
>> misunderstand basic definitions such as bus number.
>> 
> I agree it is conceptually wrong. It is not even needed for unique device
> path generation. It is only needed to make both IDE buses configurable
> from command line in ISA machine. I'll drop it in favor of other solution,
> but qdev has to rethink how devices should it addressable from command
> line. Current way is broken.

I agree it's broken and needs fixing.  I appreciate you trying to fix
it, but it indeed looks like it's better to fix it separately.

>> >> Example: default piix3-ide plus a tertiary IDE channel
>> >> -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11
>> > Here are the device names my patch produces (for pci ide disks one
>> > virtio and one isa-ide:
>> >
>> > /pci@i0cf8/ata@1,1/ide@0/disk@0
>> > /pci@i0cf8/ata@1,1/ide@0/disk@1
>> > /pci@i0cf8/ata@1,1/ide@1/disk@0
>> > /pci@i0cf8/ata@1,1/ide@1/disk@1
>> > /pci@i0cf8/virtio-blk@3/disk@0
>> > /pci@i0cf8/pci-isa-bridge@1/ata@01e8/ide@0/disk@0
>> >
>> > As you can see there is no name clashes at all. Each device has device
>> > name that can be used to identify it in firmware.
>> >
>> >> 
>> >> > diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
>> >> > index 336ffe1..220729e 100644
>> >> > --- a/hw/ide/qdev.c
>> >> > +++ b/hw/ide/qdev.c
>> >> > @@ -29,9 +29,13 @@ static struct BusInfo ide_bus_info = {
>> >> >      .size  = sizeof(IDEBus),
>> >> >  };
>> >> >  
>> >> > -void ide_bus_new(IDEBus *idebus, DeviceState *dev)
>> >> > +void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
>> >> >  {
>> >> > -    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
>> >> > +    char name[10];
>> >> > +
>> >> > +    snprintf(name, sizeof(name), "ide.%d", bus_id); 
>> >> > +    qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, name);
>> >> > +    idebus->bus_id = bus_id;
>> >> >  }
>> >> 
>> >> Incompatible change.
>> >> 
>> >> Before: -M pc -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11,id=foo
>> >> provides an IDE bus called "foo.0":
>> >> 
>> >>           dev: isa-ide, id "foo"
>> >>             dev-prop: iobase = 0x1e8
>> >>             dev-prop: iobase2 = 0x3ee
>> >>             dev-prop: irq = 11
>> >>             isa irq 11
>> >>             bus: foo.0
>> >>               type IDE
>> >> 
>> >> After: it's called "ide.0", I think.
>> >> 
>> > snprintf(name, sizeof(name), "%s.%d", dev->id ? : "ide", bus_id);
>> > will take care of it.
>> 
>> Not fully.
>> 
>> -M pc
>> -device isa-ide,iobase=0x1e8,iobase2=0x3ee,irq=11,id=foo
>> -device isa-ide,iobase=0x168,iobase2=0x36e,irq=10,id=bar
>> 
>> Before: foo.0 and bar.0
>> After: foo.0 and bar.1
>> 
>> >                       But I am starting to think that this is indeed not
>> > needed. Without the change my patch produce name like that in isapc case:
>> > /isa/ata@01f0/ide@0/disk@0
>> > /isa/ata@01f0/ide@0/disk@1
>> > /isa/ata@0170/ide@0/disk@0
>> > /isa/ata@0170/ide@0/disk@1
>> >
>> > so the paths are unique and usable by firmware. The only problem is that
>> > not all disks are addressable from -device option, so I can't set
>> > bootindex on some of them.
>> 
>> Perhaps we can treat the non-addressability of -M isapc's second IDE bus
>> as a separate problem.
>> 
> Agree, hence I will not use this patch and will get back to just
> recording bus_id. But -M isapc is just a symptom of much more serious
> problem in qdev. The way devices addressable there is not well defined.
> Two devices may have the same device path. Ultimately I think qdev
> should use device addresses similar to what I am trying to achieve here.
> For ISA machine it should automatically generate ids like isa-ide@0x170
> for first isa IDE controller and isa-ide@0x1f0 for second one. And get
> rid of user assigned ids. They are good for nothing and exist only
> because qdev developer didn't agree on how to name devices.

Yes, ambigous paths are a well-known problem.  For user-defined devices,
users can define the (unique) ID, which provides an unambigous path.
But default devices don't have one.  When we have two of identical
devices without ID on the same bus, their paths become ambigous.

There has been quite some discussion on "canonical path" on the list,
but no consensus.  Ironically, one of the places where we got stuck was
ISA.  You cut right through that, so that's progress.  Maybe people
aren't looking ;)

>> >> Likely to break non-default IDE controller use.  Could be rare enough
>> >> for us not to care, I don't know.
>> >> 
>> >> If we need to avoid this change, then ide_bus_new() must not pass a bus
>> >> name to qbus_create_inplace() for devices added with -device/device_add.
>> >> 
>> >> >  
>> >> >  static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
>> >> > diff --git a/hw/ide/via.c b/hw/ide/via.c
>> >> > index b2c7cad..cc48b2b 100644
>> >> > --- a/hw/ide/via.c
>> >> > +++ b/hw/ide/via.c
>> >> > @@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
>> >> >  
>> >> >      vmstate_register(&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);
>> >> > +    ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
>> >> > +    ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
>> >> >      ide_init2(&d->bus[0], isa_reserve_irq(14));
>> >> >      ide_init2(&d->bus[1], isa_reserve_irq(15));
>> >> >      ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
>> >> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
>> >> > index 3d07ce5..cec6c9b 100644
>> >> > --- a/hw/pc_piix.c
>> >> > +++ b/hw/pc_piix.c
>> >> > @@ -163,7 +163,7 @@ static void pc_init1(ram_addr_t ram_size,
>> >> >              ISADevice *dev;
>> >> >              dev = isa_ide_init(ide_iobase[i], ide_iobase2[i], ide_irq[i],
>> >> >                                 hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
>> >> > -            idebus[i] = qdev_get_child_bus(&dev->qdev, "ide.0");
>> >> > +            idebus[i] = qdev_get_child_bus(&dev->qdev, i ? "ide.1" : "ide.0");
>> >> >          }
>> >> >      }

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Thu, Nov 04, 2010 at 09:46:57AM +0100, Markus Armbruster wrote:
> > But why order of device creation is important? It shouldn't be if we
> > want to move HW description into config file. We even may allow creating
> > piix3-ide with only second IDE bus, but not first.
> 
> That's not how buses work in qdev.
> 
> Configuration file, command line and monitor configure *devices*.
> Devices need to be created after the device providing their parent bus,
> obviously.  Other than that, order should not matter.
> 
Correct, but it will if we use your function for looking for IDEBus id.
See below.

> Buses are always created by device model code.  Thus, creation order is
> fixed in code.  Thus defining bus number in terms of creation order is
> fine.
So I can't create piix3-ide with only one bus. Looks like arbitrary
limitation for me.

> 
> If we create piix3-ide with only the second bus (for the sake of
> argument), then its bus number is zero by definition, as clarified by
> you below.  Unless you want to amend your definition :)
> 
As clarified by me below in case of piix3-ide bus number is actually
used to figure out how to talk to device on that bus. So if (for
the sake of argument of course) we will create piix3-ide device with
only secondary bus (the one accessible through BAR2,3 of piix3-ide),
device sitting on it will be named ide@0 since there will be only one
bus on piix3-ide. Given name ide@0 guest will try to use BAR0,1 and
fail. I understand that such config is not possible today (at least
with piix3-ide) but it is important to understand that this is not
"just a number showing in which order bus was created"


> >> >> >                                          Are you against adding bus_id
> >> >> > to IDEBus?
> >> >> 
> >> >> "Against" is too hard a word.  If it's a general question, I'd prefer a
> >> >> general answer.
> >> > It is as general as "what pci slot/func of a pci device". We store those
> >> > in PCIDevice.
> >> 
> >> It's actually more general than that :)
> >> 
> >> PCI slot.function is the address of a PCI device on its parent bus.
> >> It's specific to PCI buses.
> >> 
> >> The bus number is the "address" of a bus on its parent device.  It's the
> >> same regardless of the device.
> >> 
> > In case of IDE bus siting on piix3-ide it is not just arbitrary number
> > like you suggest here. It actually tells how to talk to a device. IDE
> > bus 0 is reachable through BAR0,1 of piix3-ide and IDE bus 1 is reachable
> > through BAR2,3. So this number is part of the device address as much as
> > pci slot/func is.
> 
> What I mean to say: regardless of what the device is, or what kind of
> buses it provides, the buses can *always* be identified the same way:
> define an order, identify bus by ordinal number.
Only if you always create them all and in the correct order. Then, just by
coincidence (not by design), your assertion above will be true.

> 
> Because of that, I believe the concept "bus number" should be a generic
> qdev concept, not special to IDE buses.
If you think that other devices may benefit from "bus number" I can
move it into BusState. Important thing is that "bus number" should
be determined by bus creator and should be independent from order of
creation. The thing is other devices may use other means to address
different buses. For instance system bus may have two PCI domains
one is addressable via 0x0cf8 IO port another is addressable through
MMIO address 0xf8000000. "bus number" is meaningless for those two
buses. Instead one of them will be named pci@i0cf8 and another one is
pci@f8000000.


> > I agree it is conceptually wrong. It is not even needed for unique device
> > path generation. It is only needed to make both IDE buses configurable
> > from command line in ISA machine. I'll drop it in favor of other solution,
> > but qdev has to rethink how devices should it addressable from command
> > line. Current way is broken.
> 
> I agree it's broken and needs fixing.  I appreciate you trying to fix
> it, but it indeed looks like it's better to fix it separately.
> 
OK.

> >> 
> >> Perhaps we can treat the non-addressability of -M isapc's second IDE bus
> >> as a separate problem.
> >> 
> > Agree, hence I will not use this patch and will get back to just
> > recording bus_id. But -M isapc is just a symptom of much more serious
> > problem in qdev. The way devices addressable there is not well defined.
> > Two devices may have the same device path. Ultimately I think qdev
> > should use device addresses similar to what I am trying to achieve here.
> > For ISA machine it should automatically generate ids like isa-ide@0x170
> > for first isa IDE controller and isa-ide@0x1f0 for second one. And get
> > rid of user assigned ids. They are good for nothing and exist only
> > because qdev developer didn't agree on how to name devices.
> 
> Yes, ambigous paths are a well-known problem.  For user-defined devices,
> users can define the (unique) ID, which provides an unambigous path.
This is just dropping problem onto a user. Qemu is capable to
create unique ids by itself. Advantage is that it will work for
internally create devices and user-defined devices.

> But default devices don't have one.  When we have two of identical
> devices without ID on the same bus, their paths become ambigous.
> 
> There has been quite some discussion on "canonical path" on the list,
> but no consensus.  Ironically, one of the places where we got stuck was
> ISA.  You cut right through that, so that's progress.  Maybe people
> aren't looking ;)
That is funny since the problem was already solved looong time ago. Just
look at Open Firmware device path. They are capable of addressing all
devices just fine, ISA devices included. What specific problem you had
with ISA bus? 

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Thu, Nov 04, 2010 at 09:46:57AM +0100, Markus Armbruster wrote:
>> > But why order of device creation is important? It shouldn't be if we
>> > want to move HW description into config file. We even may allow creating
>> > piix3-ide with only second IDE bus, but not first.
>> 
>> That's not how buses work in qdev.
>> 
>> Configuration file, command line and monitor configure *devices*.
>> Devices need to be created after the device providing their parent bus,
>> obviously.  Other than that, order should not matter.
>> 
> Correct, but it will if we use your function for looking for IDEBus id.
> See below.

Where I'll explain why device order creation can't affect bus numbers.

>> Buses are always created by device model code.  Thus, creation order is
>> fixed in code.  Thus defining bus number in terms of creation order is
>> fine.
> So I can't create piix3-ide with only one bus. Looks like arbitrary
> limitation for me.

If it has just one bus, it's simply not piix3-ide anymore.  The real
PIIX3 PCI device has an IDE function that provides two channels, no
more, no less.

>> If we create piix3-ide with only the second bus (for the sake of
>> argument), then its bus number is zero by definition, as clarified by
>> you below.  Unless you want to amend your definition :)
>> 
> As clarified by me below in case of piix3-ide bus number is actually
> used to figure out how to talk to device on that bus. So if (for
> the sake of argument of course) we will create piix3-ide device with
> only secondary bus (the one accessible through BAR2,3 of piix3-ide),
> device sitting on it will be named ide@0 since there will be only one
> bus on piix3-ide. Given name ide@0 guest will try to use BAR0,1 and
> fail. I understand that such config is not possible today (at least
> with piix3-ide) but it is important to understand that this is not
> "just a number showing in which order bus was created"

Why would a hypothetical piix3-ide with just one IDE channel
nevertheless expose BARs for *two* IDE channels?

To me it looks like the need for "holes" in the bus number sequence is
purely theoretical.

>> >> >> >                                          Are you against adding bus_id
>> >> >> > to IDEBus?
>> >> >> 
>> >> >> "Against" is too hard a word.  If it's a general question, I'd prefer a
>> >> >> general answer.
>> >> > It is as general as "what pci slot/func of a pci device". We store those
>> >> > in PCIDevice.
>> >> 
>> >> It's actually more general than that :)
>> >> 
>> >> PCI slot.function is the address of a PCI device on its parent bus.
>> >> It's specific to PCI buses.
>> >> 
>> >> The bus number is the "address" of a bus on its parent device.  It's the
>> >> same regardless of the device.
>> >> 
>> > In case of IDE bus siting on piix3-ide it is not just arbitrary number
>> > like you suggest here. It actually tells how to talk to a device. IDE
>> > bus 0 is reachable through BAR0,1 of piix3-ide and IDE bus 1 is reachable
>> > through BAR2,3. So this number is part of the device address as much as
>> > pci slot/func is.
>> 
>> What I mean to say: regardless of what the device is, or what kind of
>> buses it provides, the buses can *always* be identified the same way:
>> define an order, identify bus by ordinal number.
> Only if you always create them all and in the correct order. Then, just by
> coincidence (not by design), your assertion above will be true.

By definition of bus number, not by coincidence.

It's trivial to create buses in order.  It also ensures the numbers are
sane: start with 0, no holes.

Passing bus numbers explicitly isn't hard either.  Programmer is free to
pass nonsensical numbers.  For the most common case of one bus, the bus
number parameter is just noise.

There are two disputed issues here:

1. Whether to pass bus numbers explicitly or not.  I'd prefer not.  But
   I won't insist on it.

2. Whether bus numbers are IDE specific or general.  In my opinion, they
   are general.

>> Because of that, I believe the concept "bus number" should be a generic
>> qdev concept, not special to IDE buses.
> If you think that other devices may benefit from "bus number" I can
> move it into BusState. Important thing is that "bus number" should
> be determined by bus creator and should be independent from order of
> creation. The thing is other devices may use other means to address
> different buses. For instance system bus may have two PCI domains
> one is addressable via 0x0cf8 IO port another is addressable through
> MMIO address 0xf8000000. "bus number" is meaningless for those two
> buses. Instead one of them will be named pci@i0cf8 and another one is
> pci@f8000000.

The system bus doesn't "have two PCI domains".  There are *devices*
providing PCI buses on the system bus.

In your example, there are two such devices on the system bus.  One with
configuration I/O port 0x0cf8, and one with memory-mapped configuration
at 0xf8000000.  Bus number is indeed meaningless, because a bus number
numbers a device's buses, not the system bus's devices!

Devices are identified by their address on the parent bus.  The
addressing scheme is specific to the parent bus type.

Buses are identified by their bus number within their parent device.
The addressing scheme is always the same: ordinal number.

>> > I agree it is conceptually wrong. It is not even needed for unique device
>> > path generation. It is only needed to make both IDE buses configurable
>> > from command line in ISA machine. I'll drop it in favor of other solution,
>> > but qdev has to rethink how devices should it addressable from command
>> > line. Current way is broken.
>> 
>> I agree it's broken and needs fixing.  I appreciate you trying to fix
>> it, but it indeed looks like it's better to fix it separately.
>> 
> OK.
>
>> >> 
>> >> Perhaps we can treat the non-addressability of -M isapc's second IDE bus
>> >> as a separate problem.
>> >> 
>> > Agree, hence I will not use this patch and will get back to just
>> > recording bus_id. But -M isapc is just a symptom of much more serious
>> > problem in qdev. The way devices addressable there is not well defined.
>> > Two devices may have the same device path. Ultimately I think qdev
>> > should use device addresses similar to what I am trying to achieve here.
>> > For ISA machine it should automatically generate ids like isa-ide@0x170
>> > for first isa IDE controller and isa-ide@0x1f0 for second one. And get
>> > rid of user assigned ids. They are good for nothing and exist only
>> > because qdev developer didn't agree on how to name devices.
>> 
>> Yes, ambigous paths are a well-known problem.  For user-defined devices,
>> users can define the (unique) ID, which provides an unambigous path.
> This is just dropping problem onto a user. Qemu is capable to
> create unique ids by itself. Advantage is that it will work for
> internally create devices and user-defined devices.

IDs are a user feature.  The user has full control over them.  If we
created IDs automatically, they could clash with the user's.

The problem is that our rules what to do when the user didn't assign ID
are broken.  Yes, we should make sure every device has an unambigous
name even then.  More so for devices created automatically.

>> But default devices don't have one.  When we have two of identical
>> devices without ID on the same bus, their paths become ambigous.
>> 
>> There has been quite some discussion on "canonical path" on the list,
>> but no consensus.  Ironically, one of the places where we got stuck was
>> ISA.  You cut right through that, so that's progress.  Maybe people
>> aren't looking ;)
> That is funny since the problem was already solved looong time ago. Just
> look at Open Firmware device path. They are capable of addressing all
> devices just fine, ISA devices included. What specific problem you had
> with ISA bus? 

Lack of consensus.  I was in favour of using I/O base, just like you do.
There were worries about ISA devices not using any I/O ports.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Thu, Nov 04, 2010 at 03:22:50PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Thu, Nov 04, 2010 at 09:46:57AM +0100, Markus Armbruster wrote:
> >> > But why order of device creation is important? It shouldn't be if we
> >> > want to move HW description into config file. We even may allow creating
> >> > piix3-ide with only second IDE bus, but not first.
> >> 
> >> That's not how buses work in qdev.
> >> 
> >> Configuration file, command line and monitor configure *devices*.
> >> Devices need to be created after the device providing their parent bus,
> >> obviously.  Other than that, order should not matter.
> >> 
> > Correct, but it will if we use your function for looking for IDEBus id.
> > See below.
> 
> Where I'll explain why device order creation can't affect bus numbers.
> 
Bus order creation will affect bus number thought.

> >> Buses are always created by device model code.  Thus, creation order is
> >> fixed in code.  Thus defining bus number in terms of creation order is
> >> fine.
> > So I can't create piix3-ide with only one bus. Looks like arbitrary
> > limitation for me.
> 
> If it has just one bus, it's simply not piix3-ide anymore.  The real
> PIIX3 PCI device has an IDE function that provides two channels, no
> more, no less.
> 
We are doing mental exercise to see if our design is flexible enough

> >> If we create piix3-ide with only the second bus (for the sake of
> >> argument), then its bus number is zero by definition, as clarified by
> >> you below.  Unless you want to amend your definition :)
> >> 
> > As clarified by me below in case of piix3-ide bus number is actually
> > used to figure out how to talk to device on that bus. So if (for
> > the sake of argument of course) we will create piix3-ide device with
> > only secondary bus (the one accessible through BAR2,3 of piix3-ide),
> > device sitting on it will be named ide@0 since there will be only one
> > bus on piix3-ide. Given name ide@0 guest will try to use BAR0,1 and
> > fail. I understand that such config is not possible today (at least
> > with piix3-ide) but it is important to understand that this is not
> > "just a number showing in which order bus was created"
> 
> Why would a hypothetical piix3-ide with just one IDE channel
> nevertheless expose BARs for *two* IDE channels?
> 
> To me it looks like the need for "holes" in the bus number sequence is
> purely theoretical.
> 
And to me it looks like relying on implicit bus ordering may limit us in
the situation too.

> >> >> >> >                                          Are you against adding bus_id
> >> >> >> > to IDEBus?
> >> >> >> 
> >> >> >> "Against" is too hard a word.  If it's a general question, I'd prefer a
> >> >> >> general answer.
> >> >> > It is as general as "what pci slot/func of a pci device". We store those
> >> >> > in PCIDevice.
> >> >> 
> >> >> It's actually more general than that :)
> >> >> 
> >> >> PCI slot.function is the address of a PCI device on its parent bus.
> >> >> It's specific to PCI buses.
> >> >> 
> >> >> The bus number is the "address" of a bus on its parent device.  It's the
> >> >> same regardless of the device.
> >> >> 
> >> > In case of IDE bus siting on piix3-ide it is not just arbitrary number
> >> > like you suggest here. It actually tells how to talk to a device. IDE
> >> > bus 0 is reachable through BAR0,1 of piix3-ide and IDE bus 1 is reachable
> >> > through BAR2,3. So this number is part of the device address as much as
> >> > pci slot/func is.
> >> 
> >> What I mean to say: regardless of what the device is, or what kind of
> >> buses it provides, the buses can *always* be identified the same way:
> >> define an order, identify bus by ordinal number.
> > Only if you always create them all and in the correct order. Then, just by
> > coincidence (not by design), your assertion above will be true.
> 
> By definition of bus number, not by coincidence.
> 
> It's trivial to create buses in order.  It also ensures the numbers are
> sane: start with 0, no holes.
In case of piix3-ide I agree it is indeed trivial to create them in
order, but are you sure about all other, not yet implemented, cases?
> 
> Passing bus numbers explicitly isn't hard either.  Programmer is free to
> pass nonsensical numbers.  For the most common case of one bus, the bus
> number parameter is just noise.
If programmer makes an error this is a bug that should be fixed.

> 
> There are two disputed issues here:
> 
> 1. Whether to pass bus numbers explicitly or not.  I'd prefer not.  But
>    I won't insist on it.
> 
> 2. Whether bus numbers are IDE specific or general.  In my opinion, they
>    are general.
> 
Do we have other cases of device providing two buses in qemu tree now?
I prefer to do it only for piix3-ide for now and change it later if
this is a common pattern.

> >> Because of that, I believe the concept "bus number" should be a generic
> >> qdev concept, not special to IDE buses.
> > If you think that other devices may benefit from "bus number" I can
> > move it into BusState. Important thing is that "bus number" should
> > be determined by bus creator and should be independent from order of
> > creation. The thing is other devices may use other means to address
> > different buses. For instance system bus may have two PCI domains
> > one is addressable via 0x0cf8 IO port another is addressable through
> > MMIO address 0xf8000000. "bus number" is meaningless for those two
> > buses. Instead one of them will be named pci@i0cf8 and another one is
> > pci@f8000000.
> 
> The system bus doesn't "have two PCI domains".  There are *devices*
> providing PCI buses on the system bus.
> 
Correct. Not a good example indeed. I can't think of other device with
two buses except piix3_ide.

> In your example, there are two such devices on the system bus.  One with
> configuration I/O port 0x0cf8, and one with memory-mapped configuration
> at 0xf8000000.  Bus number is indeed meaningless, because a bus number
> numbers a device's buses, not the system bus's devices!
> 
> Devices are identified by their address on the parent bus.  The
> addressing scheme is specific to the parent bus type.
> 
> Buses are identified by their bus number within their parent device.
> The addressing scheme is always the same: ordinal number.
> 
> >> > I agree it is conceptually wrong. It is not even needed for unique device
> >> > path generation. It is only needed to make both IDE buses configurable
> >> > from command line in ISA machine. I'll drop it in favor of other solution,
> >> > but qdev has to rethink how devices should it addressable from command
> >> > line. Current way is broken.
> >> 
> >> I agree it's broken and needs fixing.  I appreciate you trying to fix
> >> it, but it indeed looks like it's better to fix it separately.
> >> 
> > OK.
> >
> >> >> 
> >> >> Perhaps we can treat the non-addressability of -M isapc's second IDE bus
> >> >> as a separate problem.
> >> >> 
> >> > Agree, hence I will not use this patch and will get back to just
> >> > recording bus_id. But -M isapc is just a symptom of much more serious
> >> > problem in qdev. The way devices addressable there is not well defined.
> >> > Two devices may have the same device path. Ultimately I think qdev
> >> > should use device addresses similar to what I am trying to achieve here.
> >> > For ISA machine it should automatically generate ids like isa-ide@0x170
> >> > for first isa IDE controller and isa-ide@0x1f0 for second one. And get
> >> > rid of user assigned ids. They are good for nothing and exist only
> >> > because qdev developer didn't agree on how to name devices.
> >> 
> >> Yes, ambigous paths are a well-known problem.  For user-defined devices,
> >> users can define the (unique) ID, which provides an unambigous path.
> > This is just dropping problem onto a user. Qemu is capable to
> > create unique ids by itself. Advantage is that it will work for
> > internally create devices and user-defined devices.
> 
> IDs are a user feature.  The user has full control over them.  If we
> created IDs automatically, they could clash with the user's.
> 
That is why I am saying that it is misfeature. It should have been
automatically created for all devices.

> The problem is that our rules what to do when the user didn't assign ID
> are broken.  Yes, we should make sure every device has an unambigous
> name even then.  More so for devices created automatically.
> 
> >> But default devices don't have one.  When we have two of identical
> >> devices without ID on the same bus, their paths become ambigous.
> >> 
> >> There has been quite some discussion on "canonical path" on the list,
> >> but no consensus.  Ironically, one of the places where we got stuck was
> >> ISA.  You cut right through that, so that's progress.  Maybe people
> >> aren't looking ;)
> > That is funny since the problem was already solved looong time ago. Just
> > look at Open Firmware device path. They are capable of addressing all
> > devices just fine, ISA devices included. What specific problem you had
> > with ISA bus? 
> 
> Lack of consensus.  I was in favour of using I/O base, just like you do.
> There were worries about ISA devices not using any I/O ports.
There is a solution for that problem for almost 15 years and we are
still looking for consensus on qemu list?! Here is ISA device binding
spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
If ISA device have no IO ports MMIO is used.

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Thu, Nov 04, 2010 at 03:22:50PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > On Thu, Nov 04, 2010 at 09:46:57AM +0100, Markus Armbruster wrote:
>> >> > But why order of device creation is important? It shouldn't be if we
>> >> > want to move HW description into config file. We even may allow creating
>> >> > piix3-ide with only second IDE bus, but not first.
>> >> 
>> >> That's not how buses work in qdev.
>> >> 
>> >> Configuration file, command line and monitor configure *devices*.
>> >> Devices need to be created after the device providing their parent bus,
>> >> obviously.  Other than that, order should not matter.
>> >> 
>> > Correct, but it will if we use your function for looking for IDEBus id.
>> > See below.
>> 
>> Where I'll explain why device order creation can't affect bus numbers.
>> 
> Bus order creation will affect bus number thought.

Yes, but that order is completely arbitrary in the code, so you can just
as well create the buses in the natural order.

>> >> Buses are always created by device model code.  Thus, creation order is
>> >> fixed in code.  Thus defining bus number in terms of creation order is
>> >> fine.
>> > So I can't create piix3-ide with only one bus. Looks like arbitrary
>> > limitation for me.
>> 
>> If it has just one bus, it's simply not piix3-ide anymore.  The real
>> PIIX3 PCI device has an IDE function that provides two channels, no
>> more, no less.
>> 
> We are doing mental exercise to see if our design is flexible enough

Fair enough.  What I mean to say is that a device's buses are an
integral part of it, not something that's pluggable.

>> >> If we create piix3-ide with only the second bus (for the sake of
>> >> argument), then its bus number is zero by definition, as clarified by
>> >> you below.  Unless you want to amend your definition :)
>> >> 
>> > As clarified by me below in case of piix3-ide bus number is actually
>> > used to figure out how to talk to device on that bus. So if (for
>> > the sake of argument of course) we will create piix3-ide device with
>> > only secondary bus (the one accessible through BAR2,3 of piix3-ide),
>> > device sitting on it will be named ide@0 since there will be only one
>> > bus on piix3-ide. Given name ide@0 guest will try to use BAR0,1 and
>> > fail. I understand that such config is not possible today (at least
>> > with piix3-ide) but it is important to understand that this is not
>> > "just a number showing in which order bus was created"
>> 
>> Why would a hypothetical piix3-ide with just one IDE channel
>> nevertheless expose BARs for *two* IDE channels?
>> 
>> To me it looks like the need for "holes" in the bus number sequence is
>> purely theoretical.
>> 
> And to me it looks like relying on implicit bus ordering may limit us in
> the situation too.
>
>> >> >> >> >                                          Are you against adding bus_id
>> >> >> >> > to IDEBus?
>> >> >> >> 
>> >> >> >> "Against" is too hard a word.  If it's a general question, I'd prefer a
>> >> >> >> general answer.
>> >> >> > It is as general as "what pci slot/func of a pci device". We store those
>> >> >> > in PCIDevice.
>> >> >> 
>> >> >> It's actually more general than that :)
>> >> >> 
>> >> >> PCI slot.function is the address of a PCI device on its parent bus.
>> >> >> It's specific to PCI buses.
>> >> >> 
>> >> >> The bus number is the "address" of a bus on its parent device.  It's the
>> >> >> same regardless of the device.
>> >> >> 
>> >> > In case of IDE bus siting on piix3-ide it is not just arbitrary number
>> >> > like you suggest here. It actually tells how to talk to a device. IDE
>> >> > bus 0 is reachable through BAR0,1 of piix3-ide and IDE bus 1 is reachable
>> >> > through BAR2,3. So this number is part of the device address as much as
>> >> > pci slot/func is.
>> >> 
>> >> What I mean to say: regardless of what the device is, or what kind of
>> >> buses it provides, the buses can *always* be identified the same way:
>> >> define an order, identify bus by ordinal number.
>> > Only if you always create them all and in the correct order. Then, just by
>> > coincidence (not by design), your assertion above will be true.
>> 
>> By definition of bus number, not by coincidence.
>> 
>> It's trivial to create buses in order.  It also ensures the numbers are
>> sane: start with 0, no holes.
> In case of piix3-ide I agree it is indeed trivial to create them in
> order, but are you sure about all other, not yet implemented, cases?

Bus creation is basically "malloc the bus state, initialize it, add to
the parent's list of children".  Can't see how we could get dependencies
in there.

>> Passing bus numbers explicitly isn't hard either.  Programmer is free to
>> pass nonsensical numbers.  For the most common case of one bus, the bus
>> number parameter is just noise.
> If programmer makes an error this is a bug that should be fixed.
>
>> 
>> There are two disputed issues here:
>> 
>> 1. Whether to pass bus numbers explicitly or not.  I'd prefer not.  But
>>    I won't insist on it.
>> 
>> 2. Whether bus numbers are IDE specific or general.  In my opinion, they
>>    are general.
>> 
> Do we have other cases of device providing two buses in qemu tree now?
> I prefer to do it only for piix3-ide for now and change it later if
> this is a common pattern.

A quick, superficial search finds

device          buses           function creating them
corgi-ssp       3 x SSI         corgi_ssp_init()
evb6965-ssi     2 x SSI         stellaris_ssi_bus_init()
cmd646-ide      2 x IDE         pci_cmd646_ide_initfn()
piix[34]-ide    2 x IDE         pci_piix_ide_initfn()
via-ide         2 x IDE         vt82c686b_ide_initfn()

It's even conceivable that one device provides two different kinds of
buses.  I'd expect sane PCI devices to use separate functions for that,
but not everything's PCI, and not everything's sane.

>> >> Because of that, I believe the concept "bus number" should be a generic
>> >> qdev concept, not special to IDE buses.
>> > If you think that other devices may benefit from "bus number" I can
>> > move it into BusState. Important thing is that "bus number" should
>> > be determined by bus creator and should be independent from order of
>> > creation. The thing is other devices may use other means to address
>> > different buses. For instance system bus may have two PCI domains
>> > one is addressable via 0x0cf8 IO port another is addressable through
>> > MMIO address 0xf8000000. "bus number" is meaningless for those two
>> > buses. Instead one of them will be named pci@i0cf8 and another one is
>> > pci@f8000000.
>> 
>> The system bus doesn't "have two PCI domains".  There are *devices*
>> providing PCI buses on the system bus.
>> 
> Correct. Not a good example indeed. I can't think of other device with
> two buses except piix3_ide.
>
>> In your example, there are two such devices on the system bus.  One with
>> configuration I/O port 0x0cf8, and one with memory-mapped configuration
>> at 0xf8000000.  Bus number is indeed meaningless, because a bus number
>> numbers a device's buses, not the system bus's devices!
>> 
>> Devices are identified by their address on the parent bus.  The
>> addressing scheme is specific to the parent bus type.
>> 
>> Buses are identified by their bus number within their parent device.
>> The addressing scheme is always the same: ordinal number.
>> 
>> >> > I agree it is conceptually wrong. It is not even needed for unique device
>> >> > path generation. It is only needed to make both IDE buses configurable
>> >> > from command line in ISA machine. I'll drop it in favor of other solution,
>> >> > but qdev has to rethink how devices should it addressable from command
>> >> > line. Current way is broken.
>> >> 
>> >> I agree it's broken and needs fixing.  I appreciate you trying to fix
>> >> it, but it indeed looks like it's better to fix it separately.
>> >> 
>> > OK.
>> >
>> >> >> 
>> >> >> Perhaps we can treat the non-addressability of -M isapc's second IDE bus
>> >> >> as a separate problem.
>> >> >> 
>> >> > Agree, hence I will not use this patch and will get back to just
>> >> > recording bus_id. But -M isapc is just a symptom of much more serious
>> >> > problem in qdev. The way devices addressable there is not well defined.
>> >> > Two devices may have the same device path. Ultimately I think qdev
>> >> > should use device addresses similar to what I am trying to achieve here.
>> >> > For ISA machine it should automatically generate ids like isa-ide@0x170
>> >> > for first isa IDE controller and isa-ide@0x1f0 for second one. And get
>> >> > rid of user assigned ids. They are good for nothing and exist only
>> >> > because qdev developer didn't agree on how to name devices.
>> >> 
>> >> Yes, ambigous paths are a well-known problem.  For user-defined devices,
>> >> users can define the (unique) ID, which provides an unambigous path.
>> > This is just dropping problem onto a user. Qemu is capable to
>> > create unique ids by itself. Advantage is that it will work for
>> > internally create devices and user-defined devices.
>> 
>> IDs are a user feature.  The user has full control over them.  If we
>> created IDs automatically, they could clash with the user's.
>> 
> That is why I am saying that it is misfeature. It should have been
> automatically created for all devices.

Automatically created IDs tend to suck for human users.

Yes, the problem could have been avoided with a bit more thought.  Too
bad.  We'll fix it.

>> The problem is that our rules what to do when the user didn't assign ID
>> are broken.  Yes, we should make sure every device has an unambigous
>> name even then.  More so for devices created automatically.
>> 
>> >> But default devices don't have one.  When we have two of identical
>> >> devices without ID on the same bus, their paths become ambigous.
>> >> 
>> >> There has been quite some discussion on "canonical path" on the list,
>> >> but no consensus.  Ironically, one of the places where we got stuck was
>> >> ISA.  You cut right through that, so that's progress.  Maybe people
>> >> aren't looking ;)
>> > That is funny since the problem was already solved looong time ago. Just
>> > look at Open Firmware device path. They are capable of addressing all
>> > devices just fine, ISA devices included. What specific problem you had
>> > with ISA bus? 
>> 
>> Lack of consensus.  I was in favour of using I/O base, just like you do.
>> There were worries about ISA devices not using any I/O ports.
> There is a solution for that problem for almost 15 years and we are
> still looking for consensus on qemu list?! Here is ISA device binding
> spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
> If ISA device have no IO ports MMIO is used.

Precedence should promote consensus, but it can't replace it.  If you
can push the list to consensus, more power to you.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
[skip]
> >> Passing bus numbers explicitly isn't hard either.  Programmer is free to
> >> pass nonsensical numbers.  For the most common case of one bus, the bus
> >> number parameter is just noise.
> > If programmer makes an error this is a bug that should be fixed.
> >
> >> 
> >> There are two disputed issues here:
> >> 
> >> 1. Whether to pass bus numbers explicitly or not.  I'd prefer not.  But
> >>    I won't insist on it.
> >> 
> >> 2. Whether bus numbers are IDE specific or general.  In my opinion, they
> >>    are general.
> >> 
> > Do we have other cases of device providing two buses in qemu tree now?
> > I prefer to do it only for piix3-ide for now and change it later if
> > this is a common pattern.
> 
> A quick, superficial search finds
> 
> device          buses           function creating them
> corgi-ssp       3 x SSI         corgi_ssp_init()
> evb6965-ssi     2 x SSI         stellaris_ssi_bus_init()
I'll look at those.

> cmd646-ide      2 x IDE         pci_cmd646_ide_initfn()
> piix[34]-ide    2 x IDE         pci_piix_ide_initfn()
> via-ide         2 x IDE         vt82c686b_ide_initfn()
And those are the same IDEBus we already discussing.

> 
> It's even conceivable that one device provides two different kinds of
> buses.  I'd expect sane PCI devices to use separate functions for that,
> but not everything's PCI, and not everything's sane.
> 
Exactly, so we should be as flexible as possible to accommodate insane
HW.

> >> >> Because of that, I believe the concept "bus number" should be a generic
> >> >> qdev concept, not special to IDE buses.
> >> > If you think that other devices may benefit from "bus number" I can
> >> > move it into BusState. Important thing is that "bus number" should
> >> > be determined by bus creator and should be independent from order of
> >> > creation. The thing is other devices may use other means to address
> >> > different buses. For instance system bus may have two PCI domains
> >> > one is addressable via 0x0cf8 IO port another is addressable through
> >> > MMIO address 0xf8000000. "bus number" is meaningless for those two
> >> > buses. Instead one of them will be named pci@i0cf8 and another one is
> >> > pci@f8000000.
> >> 
> >> The system bus doesn't "have two PCI domains".  There are *devices*
> >> providing PCI buses on the system bus.
> >> 
> > Correct. Not a good example indeed. I can't think of other device with
> > two buses except piix3_ide.
> >
> >> In your example, there are two such devices on the system bus.  One with
> >> configuration I/O port 0x0cf8, and one with memory-mapped configuration
> >> at 0xf8000000.  Bus number is indeed meaningless, because a bus number
> >> numbers a device's buses, not the system bus's devices!
> >> 
> >> Devices are identified by their address on the parent bus.  The
> >> addressing scheme is specific to the parent bus type.
> >> 
> >> Buses are identified by their bus number within their parent device.
> >> The addressing scheme is always the same: ordinal number.
> >> 
> >> >> > I agree it is conceptually wrong. It is not even needed for unique device
> >> >> > path generation. It is only needed to make both IDE buses configurable
> >> >> > from command line in ISA machine. I'll drop it in favor of other solution,
> >> >> > but qdev has to rethink how devices should it addressable from command
> >> >> > line. Current way is broken.
> >> >> 
> >> >> I agree it's broken and needs fixing.  I appreciate you trying to fix
> >> >> it, but it indeed looks like it's better to fix it separately.
> >> >> 
> >> > OK.
> >> >
> >> >> >> 
> >> >> >> Perhaps we can treat the non-addressability of -M isapc's second IDE bus
> >> >> >> as a separate problem.
> >> >> >> 
> >> >> > Agree, hence I will not use this patch and will get back to just
> >> >> > recording bus_id. But -M isapc is just a symptom of much more serious
> >> >> > problem in qdev. The way devices addressable there is not well defined.
> >> >> > Two devices may have the same device path. Ultimately I think qdev
> >> >> > should use device addresses similar to what I am trying to achieve here.
> >> >> > For ISA machine it should automatically generate ids like isa-ide@0x170
> >> >> > for first isa IDE controller and isa-ide@0x1f0 for second one. And get
> >> >> > rid of user assigned ids. They are good for nothing and exist only
> >> >> > because qdev developer didn't agree on how to name devices.
> >> >> 
> >> >> Yes, ambigous paths are a well-known problem.  For user-defined devices,
> >> >> users can define the (unique) ID, which provides an unambigous path.
> >> > This is just dropping problem onto a user. Qemu is capable to
> >> > create unique ids by itself. Advantage is that it will work for
> >> > internally create devices and user-defined devices.
> >> 
> >> IDs are a user feature.  The user has full control over them.  If we
> >> created IDs automatically, they could clash with the user's.
> >> 
> > That is why I am saying that it is misfeature. It should have been
> > automatically created for all devices.
> 
> Automatically created IDs tend to suck for human users.
> 
You can mitigate it by allowing user to query existing device paths and
making matching more flexible. For instance if you have only one pci
domain with name ACME,pci it will be enough for user to specify only pci
as path element.

> Yes, the problem could have been avoided with a bit more thought.  Too
> bad.  We'll fix it.
> 
> >> The problem is that our rules what to do when the user didn't assign ID
> >> are broken.  Yes, we should make sure every device has an unambigous
> >> name even then.  More so for devices created automatically.
> >> 
> >> >> But default devices don't have one.  When we have two of identical
> >> >> devices without ID on the same bus, their paths become ambigous.
> >> >> 
> >> >> There has been quite some discussion on "canonical path" on the list,
> >> >> but no consensus.  Ironically, one of the places where we got stuck was
> >> >> ISA.  You cut right through that, so that's progress.  Maybe people
> >> >> aren't looking ;)
> >> > That is funny since the problem was already solved looong time ago. Just
> >> > look at Open Firmware device path. They are capable of addressing all
> >> > devices just fine, ISA devices included. What specific problem you had
> >> > with ISA bus? 
> >> 
> >> Lack of consensus.  I was in favour of using I/O base, just like you do.
> >> There were worries about ISA devices not using any I/O ports.
> > There is a solution for that problem for almost 15 years and we are
> > still looking for consensus on qemu list?! Here is ISA device binding
> > spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
> > If ISA device have no IO ports MMIO is used.
> 
> Precedence should promote consensus, but it can't replace it.  If you
> can push the list to consensus, more power to you.
I do not see disagreement right now :) You are saying you agree. Blue
Swirl asked me to use Open Firmware so I assume he agrees to. So who is
against and what are his arguments?

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
[...]
>> >> >> There has been quite some discussion on "canonical path" on the list,
>> >> >> but no consensus.  Ironically, one of the places where we got stuck was
>> >> >> ISA.  You cut right through that, so that's progress.  Maybe people
>> >> >> aren't looking ;)
>> >> > That is funny since the problem was already solved looong time ago. Just
>> >> > look at Open Firmware device path. They are capable of addressing all
>> >> > devices just fine, ISA devices included. What specific problem you had
>> >> > with ISA bus? 
>> >> 
>> >> Lack of consensus.  I was in favour of using I/O base, just like you do.
>> >> There were worries about ISA devices not using any I/O ports.
>> > There is a solution for that problem for almost 15 years and we are
>> > still looking for consensus on qemu list?! Here is ISA device binding
>> > spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
>> > If ISA device have no IO ports MMIO is used.
>> 
>> Precedence should promote consensus, but it can't replace it.  If you
>> can push the list to consensus, more power to you.
> I do not see disagreement right now :) You are saying you agree. Blue
> Swirl asked me to use Open Firmware so I assume he agrees to. So who is
> against and what are his arguments?

Start here:

http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
> [...]
> >> >> >> There has been quite some discussion on "canonical path" on the list,
> >> >> >> but no consensus.  Ironically, one of the places where we got stuck was
> >> >> >> ISA.  You cut right through that, so that's progress.  Maybe people
> >> >> >> aren't looking ;)
> >> >> > That is funny since the problem was already solved looong time ago. Just
> >> >> > look at Open Firmware device path. They are capable of addressing all
> >> >> > devices just fine, ISA devices included. What specific problem you had
> >> >> > with ISA bus? 
> >> >> 
> >> >> Lack of consensus.  I was in favour of using I/O base, just like you do.
> >> >> There were worries about ISA devices not using any I/O ports.
> >> > There is a solution for that problem for almost 15 years and we are
> >> > still looking for consensus on qemu list?! Here is ISA device binding
> >> > spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
> >> > If ISA device have no IO ports MMIO is used.
> >> 
> >> Precedence should promote consensus, but it can't replace it.  If you
> >> can push the list to consensus, more power to you.
> > I do not see disagreement right now :) You are saying you agree. Blue
> > Swirl asked me to use Open Firmware so I assume he agrees to. So who is
> > against and what are his arguments?
> 
> Start here:
> 
> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html

I saw this in fact. The wouldn't agree with this device path proposal
too. It mixes qemu internal names (which is a big no-no for my purpose)
and bus addresses. Paul made sensible points there and if you look
closely what he proposes is what I implemented here. Regarding ISA
("busses that don't have a consistent addressing scheme" he called it)
he himself proposed to use address of the first IO port/memory region
as an ID. This is what is already implemented by my patch.

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
>> [...]
>> >> >> >> There has been quite some discussion on "canonical path" on the list,
>> >> >> >> but no consensus.  Ironically, one of the places where we got stuck was
>> >> >> >> ISA.  You cut right through that, so that's progress.  Maybe people
>> >> >> >> aren't looking ;)
>> >> >> > That is funny since the problem was already solved looong time ago. Just
>> >> >> > look at Open Firmware device path. They are capable of addressing all
>> >> >> > devices just fine, ISA devices included. What specific problem you had
>> >> >> > with ISA bus? 
>> >> >> 
>> >> >> Lack of consensus.  I was in favour of using I/O base, just like you do.
>> >> >> There were worries about ISA devices not using any I/O ports.
>> >> > There is a solution for that problem for almost 15 years and we are
>> >> > still looking for consensus on qemu list?! Here is ISA device binding
>> >> > spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
>> >> > If ISA device have no IO ports MMIO is used.
>> >> 
>> >> Precedence should promote consensus, but it can't replace it.  If you
>> >> can push the list to consensus, more power to you.
>> > I do not see disagreement right now :) You are saying you agree. Blue
>> > Swirl asked me to use Open Firmware so I assume he agrees to. So who is
>> > against and what are his arguments?
>> 
>> Start here:
>> 
>> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html
>
> I saw this in fact. The wouldn't agree with this device path proposal
> too. It mixes qemu internal names (which is a big no-no for my purpose)
> and bus addresses. Paul made sensible points there and if you look
> closely what he proposes is what I implemented here. Regarding ISA
> ("busses that don't have a consistent addressing scheme" he called it)
> he himself proposed to use address of the first IO port/memory region
> as an ID. This is what is already implemented by my patch.

You don't have to convince me; I was with Paul in that thread.

Regarding DeviceInfo member name values being QEMU internal: hardly.
They're ABI.  They're what we use to identify device types on external
interfaces including command line, human monitor and QMP.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Sat, Nov 06, 2010 at 10:25:31AM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote:
> >> Gleb Natapov <gleb@redhat.com> writes:
> >> 
> >> > On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
> >> [...]
> >> >> >> >> There has been quite some discussion on "canonical path" on the list,
> >> >> >> >> but no consensus.  Ironically, one of the places where we got stuck was
> >> >> >> >> ISA.  You cut right through that, so that's progress.  Maybe people
> >> >> >> >> aren't looking ;)
> >> >> >> > That is funny since the problem was already solved looong time ago. Just
> >> >> >> > look at Open Firmware device path. They are capable of addressing all
> >> >> >> > devices just fine, ISA devices included. What specific problem you had
> >> >> >> > with ISA bus? 
> >> >> >> 
> >> >> >> Lack of consensus.  I was in favour of using I/O base, just like you do.
> >> >> >> There were worries about ISA devices not using any I/O ports.
> >> >> > There is a solution for that problem for almost 15 years and we are
> >> >> > still looking for consensus on qemu list?! Here is ISA device binding
> >> >> > spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
> >> >> > If ISA device have no IO ports MMIO is used.
> >> >> 
> >> >> Precedence should promote consensus, but it can't replace it.  If you
> >> >> can push the list to consensus, more power to you.
> >> > I do not see disagreement right now :) You are saying you agree. Blue
> >> > Swirl asked me to use Open Firmware so I assume he agrees to. So who is
> >> > against and what are his arguments?
> >> 
> >> Start here:
> >> 
> >> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html
> >
> > I saw this in fact. The wouldn't agree with this device path proposal
> > too. It mixes qemu internal names (which is a big no-no for my purpose)
> > and bus addresses. Paul made sensible points there and if you look
> > closely what he proposes is what I implemented here. Regarding ISA
> > ("busses that don't have a consistent addressing scheme" he called it)
> > he himself proposed to use address of the first IO port/memory region
> > as an ID. This is what is already implemented by my patch.
> 
> You don't have to convince me; I was with Paul in that thread.
> 
So who should I convince :)? Alex? He is CCed. Jan? I do not see him
complaining here.

> Regarding DeviceInfo member name values being QEMU internal: hardly.
> They're ABI.  They're what we use to identify device types on external
> interfaces including command line, human monitor and QMP.
Correct. They are ABI since they are user visible. But they describe
device type where I prefer to have a field that specifies device
functionality for cases when one driver handles multiple devices in a
guest. So to clarify: "name" will work (that is why I use it when
driver_name is not set), but I want something more optimal.

--
			Gleb.

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Sat, Nov 06, 2010 at 10:25:31AM +0100, Markus Armbruster wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> > On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote:
>> >> Gleb Natapov <gleb@redhat.com> writes:
>> >> 
>> >> > On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
>> >> [...]
>> >> >> >> >> There has been quite some discussion on "canonical path" on the list,
>> >> >> >> >> but no consensus.  Ironically, one of the places where we got stuck was
>> >> >> >> >> ISA.  You cut right through that, so that's progress.  Maybe people
>> >> >> >> >> aren't looking ;)
>> >> >> >> > That is funny since the problem was already solved looong time ago. Just
>> >> >> >> > look at Open Firmware device path. They are capable of addressing all
>> >> >> >> > devices just fine, ISA devices included. What specific problem you had
>> >> >> >> > with ISA bus? 
>> >> >> >> 
>> >> >> >> Lack of consensus.  I was in favour of using I/O base, just like you do.
>> >> >> >> There were worries about ISA devices not using any I/O ports.
>> >> >> > There is a solution for that problem for almost 15 years and we are
>> >> >> > still looking for consensus on qemu list?! Here is ISA device binding
>> >> >> > spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
>> >> >> > If ISA device have no IO ports MMIO is used.
>> >> >> 
>> >> >> Precedence should promote consensus, but it can't replace it.  If you
>> >> >> can push the list to consensus, more power to you.
>> >> > I do not see disagreement right now :) You are saying you agree. Blue
>> >> > Swirl asked me to use Open Firmware so I assume he agrees to. So who is
>> >> > against and what are his arguments?
>> >> 
>> >> Start here:
>> >> 
>> >> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html
>> >
>> > I saw this in fact. The wouldn't agree with this device path proposal
>> > too. It mixes qemu internal names (which is a big no-no for my purpose)
>> > and bus addresses. Paul made sensible points there and if you look
>> > closely what he proposes is what I implemented here. Regarding ISA
>> > ("busses that don't have a consistent addressing scheme" he called it)
>> > he himself proposed to use address of the first IO port/memory region
>> > as an ID. This is what is already implemented by my patch.
>> 
>> You don't have to convince me; I was with Paul in that thread.
>> 
> So who should I convince :)? Alex? He is CCed. Jan? I do not see him
> complaining here.

No more complaints, no more convincing.

[...]

[PATCHv2 5/8] Add get_dev_path callback to IDE bus.

[Gleb Natapov]

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/ide/qdev.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 3ad2138..7db2f19 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -24,9 +24,12 @@
 
 /* --------------------------------- */
 
+static char *idebus_get_dev_path(DeviceState *dev);
+
 static struct BusInfo ide_bus_info = {
     .name  = "IDE",
     .size  = sizeof(IDEBus),
+    .get_dev_path = idebus_get_dev_path,
 };
 
 void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
@@ -35,6 +38,17 @@ void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
     idebus->bus_id = bus_id;
 }
 
+static char *idebus_get_dev_path(DeviceState *dev)
+{
+    IDEDevice *d = (IDEDevice*)dev;
+    char path[30];
+
+    snprintf(path, sizeof(path), "%s@%d:%d", qdev_driver_name(dev),
+             ((IDEBus*)dev->parent_bus)->bus_id, d->unit);
+
+    return strdup(path);
+}
+
 static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
 {
     IDEDevice *dev = DO_UPCAST(IDEDevice, qdev, qdev);
-- 
1.7.1

[Qemu-devel] [PATCHv2 5/8] Add get_dev_path callback to IDE bus.

[Gleb Natapov]

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/ide/qdev.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 3ad2138..7db2f19 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -24,9 +24,12 @@
 
 /* --------------------------------- */
 
+static char *idebus_get_dev_path(DeviceState *dev);
+
 static struct BusInfo ide_bus_info = {
     .name  = "IDE",
     .size  = sizeof(IDEBus),
+    .get_dev_path = idebus_get_dev_path,
 };
 
 void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
@@ -35,6 +38,17 @@ void ide_bus_new(IDEBus *idebus, DeviceState *dev, uint8_t bus_id)
     idebus->bus_id = bus_id;
 }
 
+static char *idebus_get_dev_path(DeviceState *dev)
+{
+    IDEDevice *d = (IDEDevice*)dev;
+    char path[30];
+
+    snprintf(path, sizeof(path), "%s@%d:%d", qdev_driver_name(dev),
+             ((IDEBus*)dev->parent_bus)->bus_id, d->unit);
+
+    return strdup(path);
+}
+
 static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
 {
     IDEDevice *dev = DO_UPCAST(IDEDevice, qdev, qdev);
-- 
1.7.1

[PATCHv2 6/8] Add get_dev_path callback for system bus.

[Gleb Natapov]

Prints out mmio or pio used to access child device.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/pci_host.c |    2 ++
 hw/sysbus.c   |   30 ++++++++++++++++++++++++++++++
 hw/sysbus.h   |    4 ++++
 3 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/hw/pci_host.c b/hw/pci_host.c
index bc5b771..28d45bf 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -197,6 +197,7 @@ void pci_host_conf_register_ioport(pio_addr_t ioport, PCIHostState *s)
 {
     pci_host_init(s);
     register_ioport_simple(&s->conf_noswap_handler, ioport, 4, 4);
+    sysbus_init_ioports(&s->busdev, ioport, 4);
 }
 
 int pci_host_data_register_mmio(PCIHostState *s, int swap)
@@ -215,4 +216,5 @@ void pci_host_data_register_ioport(pio_addr_t ioport, PCIHostState *s)
     register_ioport_simple(&s->data_noswap_handler, ioport, 4, 1);
     register_ioport_simple(&s->data_noswap_handler, ioport, 4, 2);
     register_ioport_simple(&s->data_noswap_handler, ioport, 4, 4);
+    sysbus_init_ioports(&s->busdev, ioport, 4);
 }
diff --git a/hw/sysbus.c b/hw/sysbus.c
index d817721..7e307bb 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -22,11 +22,13 @@
 #include "monitor.h"
 
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static char *sysbus_get_dev_path(DeviceState *dev);
 
 struct BusInfo system_bus_info = {
     .name       = "System",
     .size       = sizeof(BusState),
     .print_dev  = sysbus_dev_print,
+    .get_dev_path = sysbus_get_dev_path,
 };
 
 void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq)
@@ -106,6 +108,16 @@ void sysbus_init_mmio_cb(SysBusDevice *dev, target_phys_addr_t size,
     dev->mmio[n].cb = cb;
 }
 
+void sysbus_init_ioports(SysBusDevice *dev, pio_addr_t ioport, pio_addr_t size)
+{
+    pio_addr_t i;
+
+    for (i = 0; i < size; i++) {
+        assert(dev->num_pio < QDEV_MAX_PIO);
+        dev->pio[dev->num_pio++] = ioport++;
+    }
+}
+
 static int sysbus_device_init(DeviceState *dev, DeviceInfo *base)
 {
     SysBusDeviceInfo *info = container_of(base, SysBusDeviceInfo, qdev);
@@ -171,3 +183,21 @@ static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
                        indent, "", s->mmio[i].addr, s->mmio[i].size);
     }
 }
+
+static char *sysbus_get_dev_path(DeviceState *dev)
+{
+    SysBusDevice *s = sysbus_from_qdev(dev);
+    char path[40];
+    int off;
+
+    off = snprintf(path, sizeof(path), "%s", qdev_driver_name(dev));
+
+    if (s->num_mmio) {
+        snprintf(path + off, sizeof(path) - off, "@"TARGET_FMT_plx,
+                 s->mmio[0].addr);
+    } else if (s->num_pio) {
+        snprintf(path + off, sizeof(path) - off, "@i%04x", s->pio[0]);
+    }
+
+    return strdup(path);
+}
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 5980901..e9eb618 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -6,6 +6,7 @@
 #include "qdev.h"
 
 #define QDEV_MAX_MMIO 32
+#define QDEV_MAX_PIO 32
 #define QDEV_MAX_IRQ 256
 
 typedef struct SysBusDevice SysBusDevice;
@@ -23,6 +24,8 @@ struct SysBusDevice {
         mmio_mapfunc cb;
         ram_addr_t iofunc;
     } mmio[QDEV_MAX_MMIO];
+    int num_pio;
+    pio_addr_t pio[QDEV_MAX_PIO];
 };
 
 typedef int (*sysbus_initfn)(SysBusDevice *dev);
@@ -45,6 +48,7 @@ void sysbus_init_mmio_cb(SysBusDevice *dev, target_phys_addr_t size,
                             mmio_mapfunc cb);
 void sysbus_init_irq(SysBusDevice *dev, qemu_irq *p);
 void sysbus_pass_irq(SysBusDevice *dev, SysBusDevice *target);
+void sysbus_init_ioports(SysBusDevice *dev, pio_addr_t ioport, pio_addr_t size);
 
 
 void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq);
-- 
1.7.1

[Qemu-devel] [PATCHv2 6/8] Add get_dev_path callback for system bus.

[Gleb Natapov]

Prints out mmio or pio used to access child device.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/pci_host.c |    2 ++
 hw/sysbus.c   |   30 ++++++++++++++++++++++++++++++
 hw/sysbus.h   |    4 ++++
 3 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/hw/pci_host.c b/hw/pci_host.c
index bc5b771..28d45bf 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -197,6 +197,7 @@ void pci_host_conf_register_ioport(pio_addr_t ioport, PCIHostState *s)
 {
     pci_host_init(s);
     register_ioport_simple(&s->conf_noswap_handler, ioport, 4, 4);
+    sysbus_init_ioports(&s->busdev, ioport, 4);
 }
 
 int pci_host_data_register_mmio(PCIHostState *s, int swap)
@@ -215,4 +216,5 @@ void pci_host_data_register_ioport(pio_addr_t ioport, PCIHostState *s)
     register_ioport_simple(&s->data_noswap_handler, ioport, 4, 1);
     register_ioport_simple(&s->data_noswap_handler, ioport, 4, 2);
     register_ioport_simple(&s->data_noswap_handler, ioport, 4, 4);
+    sysbus_init_ioports(&s->busdev, ioport, 4);
 }
diff --git a/hw/sysbus.c b/hw/sysbus.c
index d817721..7e307bb 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -22,11 +22,13 @@
 #include "monitor.h"
 
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static char *sysbus_get_dev_path(DeviceState *dev);
 
 struct BusInfo system_bus_info = {
     .name       = "System",
     .size       = sizeof(BusState),
     .print_dev  = sysbus_dev_print,
+    .get_dev_path = sysbus_get_dev_path,
 };
 
 void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq)
@@ -106,6 +108,16 @@ void sysbus_init_mmio_cb(SysBusDevice *dev, target_phys_addr_t size,
     dev->mmio[n].cb = cb;
 }
 
+void sysbus_init_ioports(SysBusDevice *dev, pio_addr_t ioport, pio_addr_t size)
+{
+    pio_addr_t i;
+
+    for (i = 0; i < size; i++) {
+        assert(dev->num_pio < QDEV_MAX_PIO);
+        dev->pio[dev->num_pio++] = ioport++;
+    }
+}
+
 static int sysbus_device_init(DeviceState *dev, DeviceInfo *base)
 {
     SysBusDeviceInfo *info = container_of(base, SysBusDeviceInfo, qdev);
@@ -171,3 +183,21 @@ static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
                        indent, "", s->mmio[i].addr, s->mmio[i].size);
     }
 }
+
+static char *sysbus_get_dev_path(DeviceState *dev)
+{
+    SysBusDevice *s = sysbus_from_qdev(dev);
+    char path[40];
+    int off;
+
+    off = snprintf(path, sizeof(path), "%s", qdev_driver_name(dev));
+
+    if (s->num_mmio) {
+        snprintf(path + off, sizeof(path) - off, "@"TARGET_FMT_plx,
+                 s->mmio[0].addr);
+    } else if (s->num_pio) {
+        snprintf(path + off, sizeof(path) - off, "@i%04x", s->pio[0]);
+    }
+
+    return strdup(path);
+}
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 5980901..e9eb618 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -6,6 +6,7 @@
 #include "qdev.h"
 
 #define QDEV_MAX_MMIO 32
+#define QDEV_MAX_PIO 32
 #define QDEV_MAX_IRQ 256
 
 typedef struct SysBusDevice SysBusDevice;
@@ -23,6 +24,8 @@ struct SysBusDevice {
         mmio_mapfunc cb;
         ram_addr_t iofunc;
     } mmio[QDEV_MAX_MMIO];
+    int num_pio;
+    pio_addr_t pio[QDEV_MAX_PIO];
 };
 
 typedef int (*sysbus_initfn)(SysBusDevice *dev);
@@ -45,6 +48,7 @@ void sysbus_init_mmio_cb(SysBusDevice *dev, target_phys_addr_t size,
                             mmio_mapfunc cb);
 void sysbus_init_irq(SysBusDevice *dev, qemu_irq *p);
 void sysbus_pass_irq(SysBusDevice *dev, SysBusDevice *target);
+void sysbus_init_ioports(SysBusDevice *dev, pio_addr_t ioport, pio_addr_t size);
 
 
 void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq);
-- 
1.7.1

[PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Gleb Natapov]

Domain should be determined form parent bus and bus number is configured
by guest and should not be used in qemu internally.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/pci.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 92aaa85..1c5706f 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 static char *pcibus_get_dev_path(DeviceState *dev)
 {
     PCIDevice *d = (PCIDevice *)dev;
-    char path[16];
-
-    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
-             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
-             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    char path[50];
+    int off;
 
+    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
+             PCI_SLOT(d->devfn));
+    if (PCI_FUNC(d->devfn))
+        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
     return strdup(path);
 }
 
-- 
1.7.1

[Qemu-devel] [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Gleb Natapov]

Domain should be determined form parent bus and bus number is configured
by guest and should not be used in qemu internally.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 hw/pci.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 92aaa85..1c5706f 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 static char *pcibus_get_dev_path(DeviceState *dev)
 {
     PCIDevice *d = (PCIDevice *)dev;
-    char path[16];
-
-    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
-             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
-             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    char path[50];
+    int off;
 
+    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
+             PCI_SLOT(d->devfn));
+    if (PCI_FUNC(d->devfn))
+        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
     return strdup(path);
 }
 
-- 
1.7.1

Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Michael S. Tsirkin]

On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> Domain should be determined form parent bus and bus number is configured
> by guest and should not be used in qemu internally.
> 
> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  hw/pci.c |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 92aaa85..1c5706f 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
>  static char *pcibus_get_dev_path(DeviceState *dev)
>  {
>      PCIDevice *d = (PCIDevice *)dev;
> -    char path[16];
> -
> -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> +    char path[50];
> +    int off;
>  
> +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> +             PCI_SLOT(d->devfn));
> +    if (PCI_FUNC(d->devfn))
> +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
>      return strdup(path);
>  }

Can we change separators to be : and . instead of @ and , please?
This will make it compatible with existing code and generally
what users expect.

-- 
MST

[Qemu-devel] Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Michael S. Tsirkin]

On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> Domain should be determined form parent bus and bus number is configured
> by guest and should not be used in qemu internally.
> 
> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  hw/pci.c |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 92aaa85..1c5706f 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
>  static char *pcibus_get_dev_path(DeviceState *dev)
>  {
>      PCIDevice *d = (PCIDevice *)dev;
> -    char path[16];
> -
> -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> +    char path[50];
> +    int off;
>  
> +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> +             PCI_SLOT(d->devfn));
> +    if (PCI_FUNC(d->devfn))
> +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
>      return strdup(path);
>  }

Can we change separators to be : and . instead of @ and , please?
This will make it compatible with existing code and generally
what users expect.

-- 
MST

Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Gleb Natapov]

On Mon, Nov 08, 2010 at 07:17:37PM +0200, Michael S. Tsirkin wrote:
> On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> > Domain should be determined form parent bus and bus number is configured
> > by guest and should not be used in qemu internally.
> > 
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > ---
> >  hw/pci.c |   11 ++++++-----
> >  1 files changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/hw/pci.c b/hw/pci.c
> > index 92aaa85..1c5706f 100644
> > --- a/hw/pci.c
> > +++ b/hw/pci.c
> > @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> >  static char *pcibus_get_dev_path(DeviceState *dev)
> >  {
> >      PCIDevice *d = (PCIDevice *)dev;
> > -    char path[16];
> > -
> > -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> > -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> > -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> > +    char path[50];
> > +    int off;
> >  
> > +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> > +             PCI_SLOT(d->devfn));
> > +    if (PCI_FUNC(d->devfn))
> > +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
> >      return strdup(path);
> >  }
> 
> Can we change separators to be : and . instead of @ and , please?
No. I am implementing well defined Open Firmware device path. Lets stop
reinventing things wrongly please?

> This will make it compatible with existing code and generally
> what users expect.
> 
It will drop domain and bus number part anyway.

--
			Gleb.

[Qemu-devel] Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Gleb Natapov]

On Mon, Nov 08, 2010 at 07:17:37PM +0200, Michael S. Tsirkin wrote:
> On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> > Domain should be determined form parent bus and bus number is configured
> > by guest and should not be used in qemu internally.
> > 
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > ---
> >  hw/pci.c |   11 ++++++-----
> >  1 files changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/hw/pci.c b/hw/pci.c
> > index 92aaa85..1c5706f 100644
> > --- a/hw/pci.c
> > +++ b/hw/pci.c
> > @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> >  static char *pcibus_get_dev_path(DeviceState *dev)
> >  {
> >      PCIDevice *d = (PCIDevice *)dev;
> > -    char path[16];
> > -
> > -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> > -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> > -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> > +    char path[50];
> > +    int off;
> >  
> > +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> > +             PCI_SLOT(d->devfn));
> > +    if (PCI_FUNC(d->devfn))
> > +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
> >      return strdup(path);
> >  }
> 
> Can we change separators to be : and . instead of @ and , please?
No. I am implementing well defined Open Firmware device path. Lets stop
reinventing things wrongly please?

> This will make it compatible with existing code and generally
> what users expect.
> 
It will drop domain and bus number part anyway.

--
			Gleb.

Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Michael S. Tsirkin]

On Mon, Nov 08, 2010 at 07:29:50PM +0200, Gleb Natapov wrote:
> On Mon, Nov 08, 2010 at 07:17:37PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> > > Domain should be determined form parent bus and bus number is configured
> > > by guest and should not be used in qemu internally.
> > > 
> > > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > > ---
> > >  hw/pci.c |   11 ++++++-----
> > >  1 files changed, 6 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/hw/pci.c b/hw/pci.c
> > > index 92aaa85..1c5706f 100644
> > > --- a/hw/pci.c
> > > +++ b/hw/pci.c
> > > @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > >  static char *pcibus_get_dev_path(DeviceState *dev)
> > >  {
> > >      PCIDevice *d = (PCIDevice *)dev;
> > > -    char path[16];
> > > -
> > > -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> > > -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> > > -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> > > +    char path[50];
> > > +    int off;
> > >  
> > > +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> > > +             PCI_SLOT(d->devfn));
> > > +    if (PCI_FUNC(d->devfn))
> > > +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
> > >      return strdup(path);
> > >  }
> > 
> > Can we change separators to be : and . instead of @ and , please?
> No. I am implementing well defined Open Firmware device path. Lets stop
> reinventing things wrongly please?
> 
> > This will make it compatible with existing code and generally
> > what users expect.
> > 
> It will drop domain and bus number part anyway.

Yes but most users at the moment have domain and bus 0 only.
So even simply adding 0000:00 prefix will work.

> --
> 			Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Qemu-devel] Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Michael S. Tsirkin]

On Mon, Nov 08, 2010 at 07:29:50PM +0200, Gleb Natapov wrote:
> On Mon, Nov 08, 2010 at 07:17:37PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> > > Domain should be determined form parent bus and bus number is configured
> > > by guest and should not be used in qemu internally.
> > > 
> > > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > > ---
> > >  hw/pci.c |   11 ++++++-----
> > >  1 files changed, 6 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/hw/pci.c b/hw/pci.c
> > > index 92aaa85..1c5706f 100644
> > > --- a/hw/pci.c
> > > +++ b/hw/pci.c
> > > @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > >  static char *pcibus_get_dev_path(DeviceState *dev)
> > >  {
> > >      PCIDevice *d = (PCIDevice *)dev;
> > > -    char path[16];
> > > -
> > > -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> > > -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> > > -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> > > +    char path[50];
> > > +    int off;
> > >  
> > > +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> > > +             PCI_SLOT(d->devfn));
> > > +    if (PCI_FUNC(d->devfn))
> > > +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
> > >      return strdup(path);
> > >  }
> > 
> > Can we change separators to be : and . instead of @ and , please?
> No. I am implementing well defined Open Firmware device path. Lets stop
> reinventing things wrongly please?
> 
> > This will make it compatible with existing code and generally
> > what users expect.
> > 
> It will drop domain and bus number part anyway.

Yes but most users at the moment have domain and bus 0 only.
So even simply adding 0000:00 prefix will work.

> --
> 			Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Gleb Natapov]

On Mon, Nov 08, 2010 at 08:12:55PM +0200, Michael S. Tsirkin wrote:
> On Mon, Nov 08, 2010 at 07:29:50PM +0200, Gleb Natapov wrote:
> > On Mon, Nov 08, 2010 at 07:17:37PM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> > > > Domain should be determined form parent bus and bus number is configured
> > > > by guest and should not be used in qemu internally.
> > > > 
> > > > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > > > ---
> > > >  hw/pci.c |   11 ++++++-----
> > > >  1 files changed, 6 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/hw/pci.c b/hw/pci.c
> > > > index 92aaa85..1c5706f 100644
> > > > --- a/hw/pci.c
> > > > +++ b/hw/pci.c
> > > > @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > > >  static char *pcibus_get_dev_path(DeviceState *dev)
> > > >  {
> > > >      PCIDevice *d = (PCIDevice *)dev;
> > > > -    char path[16];
> > > > -
> > > > -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> > > > -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> > > > -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> > > > +    char path[50];
> > > > +    int off;
> > > >  
> > > > +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> > > > +             PCI_SLOT(d->devfn));
> > > > +    if (PCI_FUNC(d->devfn))
> > > > +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
> > > >      return strdup(path);
> > > >  }
> > > 
> > > Can we change separators to be : and . instead of @ and , please?
> > No. I am implementing well defined Open Firmware device path. Lets stop
> > reinventing things wrongly please?
> > 
> > > This will make it compatible with existing code and generally
> > > what users expect.
> > > 
> > It will drop domain and bus number part anyway.
> 
> Yes but most users at the moment have domain and bus 0 only.
> So even simply adding 0000:00 prefix will work.
> 
Are we trying to build device path or do bunch of hacks? We already have
hack now. Why change anything at all? PPC Macs  (G500) had 3 pci buses.

--
			Gleb.

[Qemu-devel] Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Gleb Natapov]

On Mon, Nov 08, 2010 at 08:12:55PM +0200, Michael S. Tsirkin wrote:
> On Mon, Nov 08, 2010 at 07:29:50PM +0200, Gleb Natapov wrote:
> > On Mon, Nov 08, 2010 at 07:17:37PM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> > > > Domain should be determined form parent bus and bus number is configured
> > > > by guest and should not be used in qemu internally.
> > > > 
> > > > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > > > ---
> > > >  hw/pci.c |   11 ++++++-----
> > > >  1 files changed, 6 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/hw/pci.c b/hw/pci.c
> > > > index 92aaa85..1c5706f 100644
> > > > --- a/hw/pci.c
> > > > +++ b/hw/pci.c
> > > > @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > > >  static char *pcibus_get_dev_path(DeviceState *dev)
> > > >  {
> > > >      PCIDevice *d = (PCIDevice *)dev;
> > > > -    char path[16];
> > > > -
> > > > -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> > > > -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> > > > -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> > > > +    char path[50];
> > > > +    int off;
> > > >  
> > > > +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> > > > +             PCI_SLOT(d->devfn));
> > > > +    if (PCI_FUNC(d->devfn))
> > > > +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
> > > >      return strdup(path);
> > > >  }
> > > 
> > > Can we change separators to be : and . instead of @ and , please?
> > No. I am implementing well defined Open Firmware device path. Lets stop
> > reinventing things wrongly please?
> > 
> > > This will make it compatible with existing code and generally
> > > what users expect.
> > > 
> > It will drop domain and bus number part anyway.
> 
> Yes but most users at the moment have domain and bus 0 only.
> So even simply adding 0000:00 prefix will work.
> 
Are we trying to build device path or do bunch of hacks? We already have
hack now. Why change anything at all? PPC Macs  (G500) had 3 pci buses.

--
			Gleb.

Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Michael S. Tsirkin]

On Mon, Nov 08, 2010 at 07:29:50PM +0200, Gleb Natapov wrote:
> > This will make it compatible with existing code and generally
> > what users expect.
> > 
> It will drop domain and bus number part anyway.

Yes but the proposal was to add 0000:00: in front to
make it have the expected format for most users.

-- 
MST

[Qemu-devel] Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Michael S. Tsirkin]

On Mon, Nov 08, 2010 at 07:29:50PM +0200, Gleb Natapov wrote:
> > This will make it compatible with existing code and generally
> > what users expect.
> > 
> It will drop domain and bus number part anyway.

Yes but the proposal was to add 0000:00: in front to
make it have the expected format for most users.

-- 
MST

Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Gleb Natapov]

On Mon, Nov 08, 2010 at 11:00:17PM +0200, Michael S. Tsirkin wrote:
> On Mon, Nov 08, 2010 at 07:29:50PM +0200, Gleb Natapov wrote:
> > > This will make it compatible with existing code and generally
> > > what users expect.
> > > 
> > It will drop domain and bus number part anyway.
> 
> Yes but the proposal was to add 0000:00: in front to
> make it have the expected format for most users.
> 
I am not interesting in hacks. I do not know who are those most users 
you are talking about and why they expect 0000:00: in front of
something. Anyway, as I said, I moved to use another callback so you can
do whatever you want with get_dev_path.

--
			Gleb.

[Qemu-devel] Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Gleb Natapov]

On Mon, Nov 08, 2010 at 11:00:17PM +0200, Michael S. Tsirkin wrote:
> On Mon, Nov 08, 2010 at 07:29:50PM +0200, Gleb Natapov wrote:
> > > This will make it compatible with existing code and generally
> > > what users expect.
> > > 
> > It will drop domain and bus number part anyway.
> 
> Yes but the proposal was to add 0000:00: in front to
> make it have the expected format for most users.
> 
I am not interesting in hacks. I do not know who are those most users 
you are talking about and why they expect 0000:00: in front of
something. Anyway, as I said, I moved to use another callback so you can
do whatever you want with get_dev_path.

--
			Gleb.

Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Michael S. Tsirkin]

On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> Domain should be determined form parent bus and bus number is configured
> by guest and should not be used in qemu internally.
> 
> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  hw/pci.c |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 92aaa85..1c5706f 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
>  static char *pcibus_get_dev_path(DeviceState *dev)
>  {
>      PCIDevice *d = (PCIDevice *)dev;
> -    char path[16];
> -
> -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> +    char path[50];
> +    int off;
>  
> +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> +             PCI_SLOT(d->devfn));
> +    if (PCI_FUNC(d->devfn))
> +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
>      return strdup(path);
>  }

If we want to be backwards compatible at least for a single domain,
we need to call PCI root in that case "0000:00". Can this work?
I think that keeping a single way to address devices is good.


-- 
MST

[Qemu-devel] Re: [PATCHv2 7/8] Change pci bus get_dev_path callback to print only slot and func

[Michael S. Tsirkin]

On Sun, Oct 31, 2010 at 01:40:08PM +0200, Gleb Natapov wrote:
> Domain should be determined form parent bus and bus number is configured
> by guest and should not be used in qemu internally.
> 
> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  hw/pci.c |   11 ++++++-----
>  1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 92aaa85..1c5706f 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -2138,12 +2138,13 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
>  static char *pcibus_get_dev_path(DeviceState *dev)
>  {
>      PCIDevice *d = (PCIDevice *)dev;
> -    char path[16];
> -
> -    snprintf(path, sizeof(path), "%04x:%02x:%02x.%x",
> -             pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS],
> -             PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
> +    char path[50];
> +    int off;
>  
> +    off = snprintf(path, sizeof(path), "%s@%x", qdev_driver_name(dev),
> +             PCI_SLOT(d->devfn));
> +    if (PCI_FUNC(d->devfn))
> +        snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
>      return strdup(path);
>  }

If we want to be backwards compatible at least for a single domain,
we need to call PCI root in that case "0000:00". Can this work?
I think that keeping a single way to address devices is good.


-- 
MST

[PATCHv2 8/8] Add bootindex parameter to net/block/fd device

[Gleb Natapov]

If bootindex is specified on command line a string that describes device
in firmware readable way is added into sorted list. Later this list will
be passed into firmware to control boot order.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 block_int.h     |    4 +++-
 hw/e1000.c      |    7 +++++++
 hw/fdc.c        |   13 +++++++++++++
 hw/ide/qdev.c   |    6 ++++++
 hw/qdev.c       |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h       |    3 +++
 hw/virtio-blk.c |    4 ++++
 hw/virtio-net.c |    4 ++++
 net.h           |    4 +++-
 sysemu.h        |    9 +++++++++
 vl.c            |   24 ++++++++++++++++++++++++
 11 files changed, 128 insertions(+), 2 deletions(-)

diff --git a/block_int.h b/block_int.h
index e8e7156..60e7be2 100644
--- a/block_int.h
+++ b/block_int.h
@@ -225,6 +225,7 @@ typedef struct BlockConf {
     uint16_t logical_block_size;
     uint16_t min_io_size;
     uint32_t opt_io_size;
+    int32_t bootindex;
 } BlockConf;
 
 static inline unsigned int get_physical_block_exp(BlockConf *conf)
@@ -247,6 +248,7 @@ static inline unsigned int get_physical_block_exp(BlockConf *conf)
     DEFINE_PROP_UINT16("physical_block_size", _state,                   \
                        _conf.physical_block_size, 512),                 \
     DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0),  \
-    DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0)
+    DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0),    \
+    DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1)         \
 
 #endif /* BLOCK_INT_H */
diff --git a/hw/e1000.c b/hw/e1000.c
index 532efdc..55f6f15 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1148,6 +1148,12 @@ static int pci_e1000_init(PCIDevice *pci_dev)
                           d->dev.qdev.info->name, d->dev.qdev.id, d);
 
     qemu_format_nic_info_str(&d->nic->nc, macaddr);
+
+    if (d->conf.bootindex >= 0) {
+        qdev_add_boot_device_path(d->conf.bootindex, &pci_dev->qdev,
+                                  "ethernet-phy@0");
+    }
+
     return 0;
 }
 
@@ -1159,6 +1165,7 @@ static void qdev_e1000_reset(DeviceState *dev)
 
 static PCIDeviceInfo e1000_info = {
     .qdev.name  = "e1000",
+    .qdev.driver_name  = "ethernet",
     .qdev.desc  = "Intel Gigabit Ethernet",
     .qdev.size  = sizeof(E1000State),
     .qdev.reset = qdev_e1000_reset,
diff --git a/hw/fdc.c b/hw/fdc.c
index 51ca404..e7a1399 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -35,6 +35,7 @@
 #include "sysbus.h"
 #include "qdev-addr.h"
 #include "blockdev.h"
+#include "sysemu.h"
 
 /********************************************************/
 /* debug Floppy devices */
@@ -523,6 +524,8 @@ typedef struct FDCtrlSysBus {
 typedef struct FDCtrlISABus {
     ISADevice busdev;
     struct FDCtrl state;
+    int32_t bootindexA;
+    int32_t bootindexB;
 } FDCtrlISABus;
 
 static uint32_t fdctrl_read (void *opaque, uint32_t reg)
@@ -1992,6 +1995,14 @@ static int isabus_fdc_init1(ISADevice *dev)
     qdev_set_legacy_instance_id(&dev->qdev, iobase, 2);
     ret = fdctrl_init_common(fdctrl);
 
+    if (isa->bootindexA >= 0) {
+        qdev_add_boot_device_path(isa->bootindexA, &dev->qdev, "floppy@0");
+    }
+
+    if (isa->bootindexB >= 0) {
+        qdev_add_boot_device_path(isa->bootindexB, &dev->qdev, "floppy@1");
+    }
+
     return ret;
 }
 
@@ -2051,6 +2062,8 @@ static ISADeviceInfo isa_fdc_info = {
     .qdev.props = (Property[]) {
         DEFINE_PROP_DRIVE("driveA", FDCtrlISABus, state.drives[0].bs),
         DEFINE_PROP_DRIVE("driveB", FDCtrlISABus, state.drives[1].bs),
+        DEFINE_PROP_INT32("bootindexA", FDCtrlISABus, bootindexA, -1),
+        DEFINE_PROP_INT32("bootindexB", FDCtrlISABus, bootindexB, -1),
         DEFINE_PROP_END_OF_LIST(),
     },
 };
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 7db2f19..49d2ac1 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -21,6 +21,7 @@
 #include "qemu-error.h"
 #include <hw/ide/internal.h>
 #include "blockdev.h"
+#include "sysemu.h"
 
 /* --------------------------------- */
 
@@ -144,6 +145,11 @@ static int ide_drive_initfn(IDEDevice *dev)
     if (!dev->serial) {
         dev->serial = qemu_strdup(s->drive_serial_str);
     }
+
+    if (dev->conf.bootindex >= 0) {
+        qdev_add_boot_device_path(dev->conf.bootindex, &dev->qdev, NULL);
+    }
+
     return 0;
 }
 
diff --git a/hw/qdev.c b/hw/qdev.c
index 35858cb..2306b06 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -820,3 +820,55 @@ int do_device_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
     }
     return qdev_unplug(dev);
 }
+
+static int qdev_get_dev_path_helper(DeviceState *dev, char *p, int size)
+{
+    int l = 0;
+
+    if (dev && dev->parent_bus) {
+        char *d;
+        l = qdev_get_dev_path_helper(dev->parent_bus->parent, p, size);
+        if (dev->parent_bus->info->get_dev_path) {
+            d = dev->parent_bus->info->get_dev_path(dev);
+            l += snprintf(p + l, size - l, "%s", d);
+            qemu_free(d);
+        } else {
+            l += snprintf(p + l, size - l, "%s", dev->info->name);
+        }
+    }
+    l += snprintf(p + l , size - l, "/");
+
+    return l;
+}
+
+char* qdev_get_dev_path(DeviceState *dev)
+{
+    char path[128];
+    int l;
+
+    l = qdev_get_dev_path_helper(dev, path, 128);
+
+    path[l-1] = '\0';
+
+    return strdup(path);
+}
+
+void qdev_add_boot_device_path(int32_t bootindex, DeviceState *dev,
+                               const char *name)
+{
+    char *devpath, *bootpath;
+
+    devpath = qdev_get_dev_path(dev);
+
+    if (name) {
+        bootpath = qemu_malloc(strlen(devpath) + strlen(name) + 2);
+        sprintf(bootpath, "%s/%s", devpath, name);
+        qemu_free(devpath);
+    } else {
+        bootpath = devpath;
+    }
+
+    add_boot_device_path(bootindex, bootpath);
+
+    qemu_free(bootpath);
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index a9a98f8..6d8a543 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -294,6 +294,9 @@ static inline const char *qdev_driver_name(DeviceState *dev)
     return dev->info->driver_name ? : dev->info->name;
 }
 
+void qdev_add_boot_device_path(int32_t bootindex, DeviceState *dev,
+                               const char *name);
+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;
 
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index a1df26d..c3175fb 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -542,6 +542,10 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf)
     bdrv_set_removable(s->bs, 0);
     s->bs->buffer_alignment = conf->logical_block_size;
 
+    if (conf->bootindex >= 0) {
+        qdev_add_boot_device_path(conf->bootindex, dev, "virtio-disk@0");
+    }
+
     return &s->vdev;
 }
 
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 7e1688c..75a4407 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -1018,6 +1018,10 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf,
                     virtio_net_save, virtio_net_load, n);
     n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change, n);
 
+    if (conf->bootindex >= 0) {
+        qdev_add_boot_device_path(conf->bootindex, dev, "ethernet-phy@0");
+    }
+
     return &n->vdev;
 }
 
diff --git a/net.h b/net.h
index 44c31a9..6ceca50 100644
--- a/net.h
+++ b/net.h
@@ -17,12 +17,14 @@ typedef struct NICConf {
     MACAddr macaddr;
     VLANState *vlan;
     VLANClientState *peer;
+    int32_t bootindex;
 } NICConf;
 
 #define DEFINE_NIC_PROPERTIES(_state, _conf)                            \
     DEFINE_PROP_MACADDR("mac",   _state, _conf.macaddr),                \
     DEFINE_PROP_VLAN("vlan",     _state, _conf.vlan),                   \
-    DEFINE_PROP_NETDEV("netdev", _state, _conf.peer)
+    DEFINE_PROP_NETDEV("netdev", _state, _conf.peer),                   \
+    DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1)
 
 /* VLANs support */
 
diff --git a/sysemu.h b/sysemu.h
index 849dc8c..cc35731 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -193,4 +193,13 @@ void rtc_change_mon_event(struct tm *tm);
 
 void register_devices(void);
 
+typedef struct FWBootEntry FWBootEntry;
+
+struct FWBootEntry {
+    QTAILQ_ENTRY(FWBootEntry) link;
+    int32_t bootindex;
+    char *fw_device_path;
+};
+
+void add_boot_device_path(int32_t bootindex, char *fw_device_path);
 #endif
diff --git a/vl.c b/vl.c
index 42617c2..25d5767 100644
--- a/vl.c
+++ b/vl.c
@@ -234,6 +234,8 @@ const char *prom_envs[MAX_PROM_ENVS];
 const char *nvram = NULL;
 int boot_menu;
 
+QTAILQ_HEAD(, FWBootEntry) fw_boot_order = QTAILQ_HEAD_INITIALIZER(fw_boot_order);
+
 int nb_numa_nodes;
 uint64_t node_mem[MAX_NODES];
 uint64_t node_cpumask[MAX_NODES];
@@ -722,6 +724,28 @@ static void restore_boot_devices(void *opaque)
     qemu_free(standard_boot_devices);
 }
 
+void add_boot_device_path(int32_t bootindex, char *fw_device_path)
+{
+    FWBootEntry *node = qemu_mallocz(sizeof(FWBootEntry)), *i;
+
+    node->bootindex = bootindex;
+    node->fw_device_path = fw_device_path;
+
+    printf("adding '%s' at index %d\n", fw_device_path, bootindex);
+    QTAILQ_FOREACH(i, &fw_boot_order, link) {
+        if (i->bootindex == bootindex) {
+            fprintf(stderr, "Two devices with same boot index %d (%s %s)\n",
+                    bootindex, i->fw_device_path, fw_device_path);
+            exit(1);
+        } else if (i->bootindex < bootindex) {
+            continue;
+        }
+        QTAILQ_INSERT_BEFORE(i, node, link);
+        return;
+    }
+    QTAILQ_INSERT_TAIL(&fw_boot_order, node, link);
+}
+
 static void numa_add(const char *optarg)
 {
     char option[128];
-- 
1.7.1

[Qemu-devel] [PATCHv2 8/8] Add bootindex parameter to net/block/fd device

[Gleb Natapov]

If bootindex is specified on command line a string that describes device
in firmware readable way is added into sorted list. Later this list will
be passed into firmware to control boot order.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 block_int.h     |    4 +++-
 hw/e1000.c      |    7 +++++++
 hw/fdc.c        |   13 +++++++++++++
 hw/ide/qdev.c   |    6 ++++++
 hw/qdev.c       |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/qdev.h       |    3 +++
 hw/virtio-blk.c |    4 ++++
 hw/virtio-net.c |    4 ++++
 net.h           |    4 +++-
 sysemu.h        |    9 +++++++++
 vl.c            |   24 ++++++++++++++++++++++++
 11 files changed, 128 insertions(+), 2 deletions(-)

diff --git a/block_int.h b/block_int.h
index e8e7156..60e7be2 100644
--- a/block_int.h
+++ b/block_int.h
@@ -225,6 +225,7 @@ typedef struct BlockConf {
     uint16_t logical_block_size;
     uint16_t min_io_size;
     uint32_t opt_io_size;
+    int32_t bootindex;
 } BlockConf;
 
 static inline unsigned int get_physical_block_exp(BlockConf *conf)
@@ -247,6 +248,7 @@ static inline unsigned int get_physical_block_exp(BlockConf *conf)
     DEFINE_PROP_UINT16("physical_block_size", _state,                   \
                        _conf.physical_block_size, 512),                 \
     DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0),  \
-    DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0)
+    DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0),    \
+    DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1)         \
 
 #endif /* BLOCK_INT_H */
diff --git a/hw/e1000.c b/hw/e1000.c
index 532efdc..55f6f15 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1148,6 +1148,12 @@ static int pci_e1000_init(PCIDevice *pci_dev)
                           d->dev.qdev.info->name, d->dev.qdev.id, d);
 
     qemu_format_nic_info_str(&d->nic->nc, macaddr);
+
+    if (d->conf.bootindex >= 0) {
+        qdev_add_boot_device_path(d->conf.bootindex, &pci_dev->qdev,
+                                  "ethernet-phy@0");
+    }
+
     return 0;
 }
 
@@ -1159,6 +1165,7 @@ static void qdev_e1000_reset(DeviceState *dev)
 
 static PCIDeviceInfo e1000_info = {
     .qdev.name  = "e1000",
+    .qdev.driver_name  = "ethernet",
     .qdev.desc  = "Intel Gigabit Ethernet",
     .qdev.size  = sizeof(E1000State),
     .qdev.reset = qdev_e1000_reset,
diff --git a/hw/fdc.c b/hw/fdc.c
index 51ca404..e7a1399 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -35,6 +35,7 @@
 #include "sysbus.h"
 #include "qdev-addr.h"
 #include "blockdev.h"
+#include "sysemu.h"
 
 /********************************************************/
 /* debug Floppy devices */
@@ -523,6 +524,8 @@ typedef struct FDCtrlSysBus {
 typedef struct FDCtrlISABus {
     ISADevice busdev;
     struct FDCtrl state;
+    int32_t bootindexA;
+    int32_t bootindexB;
 } FDCtrlISABus;
 
 static uint32_t fdctrl_read (void *opaque, uint32_t reg)
@@ -1992,6 +1995,14 @@ static int isabus_fdc_init1(ISADevice *dev)
     qdev_set_legacy_instance_id(&dev->qdev, iobase, 2);
     ret = fdctrl_init_common(fdctrl);
 
+    if (isa->bootindexA >= 0) {
+        qdev_add_boot_device_path(isa->bootindexA, &dev->qdev, "floppy@0");
+    }
+
+    if (isa->bootindexB >= 0) {
+        qdev_add_boot_device_path(isa->bootindexB, &dev->qdev, "floppy@1");
+    }
+
     return ret;
 }
 
@@ -2051,6 +2062,8 @@ static ISADeviceInfo isa_fdc_info = {
     .qdev.props = (Property[]) {
         DEFINE_PROP_DRIVE("driveA", FDCtrlISABus, state.drives[0].bs),
         DEFINE_PROP_DRIVE("driveB", FDCtrlISABus, state.drives[1].bs),
+        DEFINE_PROP_INT32("bootindexA", FDCtrlISABus, bootindexA, -1),
+        DEFINE_PROP_INT32("bootindexB", FDCtrlISABus, bootindexB, -1),
         DEFINE_PROP_END_OF_LIST(),
     },
 };
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 7db2f19..49d2ac1 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -21,6 +21,7 @@
 #include "qemu-error.h"
 #include <hw/ide/internal.h>
 #include "blockdev.h"
+#include "sysemu.h"
 
 /* --------------------------------- */
 
@@ -144,6 +145,11 @@ static int ide_drive_initfn(IDEDevice *dev)
     if (!dev->serial) {
         dev->serial = qemu_strdup(s->drive_serial_str);
     }
+
+    if (dev->conf.bootindex >= 0) {
+        qdev_add_boot_device_path(dev->conf.bootindex, &dev->qdev, NULL);
+    }
+
     return 0;
 }
 
diff --git a/hw/qdev.c b/hw/qdev.c
index 35858cb..2306b06 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -820,3 +820,55 @@ int do_device_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
     }
     return qdev_unplug(dev);
 }
+
+static int qdev_get_dev_path_helper(DeviceState *dev, char *p, int size)
+{
+    int l = 0;
+
+    if (dev && dev->parent_bus) {
+        char *d;
+        l = qdev_get_dev_path_helper(dev->parent_bus->parent, p, size);
+        if (dev->parent_bus->info->get_dev_path) {
+            d = dev->parent_bus->info->get_dev_path(dev);
+            l += snprintf(p + l, size - l, "%s", d);
+            qemu_free(d);
+        } else {
+            l += snprintf(p + l, size - l, "%s", dev->info->name);
+        }
+    }
+    l += snprintf(p + l , size - l, "/");
+
+    return l;
+}
+
+char* qdev_get_dev_path(DeviceState *dev)
+{
+    char path[128];
+    int l;
+
+    l = qdev_get_dev_path_helper(dev, path, 128);
+
+    path[l-1] = '\0';
+
+    return strdup(path);
+}
+
+void qdev_add_boot_device_path(int32_t bootindex, DeviceState *dev,
+                               const char *name)
+{
+    char *devpath, *bootpath;
+
+    devpath = qdev_get_dev_path(dev);
+
+    if (name) {
+        bootpath = qemu_malloc(strlen(devpath) + strlen(name) + 2);
+        sprintf(bootpath, "%s/%s", devpath, name);
+        qemu_free(devpath);
+    } else {
+        bootpath = devpath;
+    }
+
+    add_boot_device_path(bootindex, bootpath);
+
+    qemu_free(bootpath);
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index a9a98f8..6d8a543 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -294,6 +294,9 @@ static inline const char *qdev_driver_name(DeviceState *dev)
     return dev->info->driver_name ? : dev->info->name;
 }
 
+void qdev_add_boot_device_path(int32_t bootindex, DeviceState *dev,
+                               const char *name);
+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;
 
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index a1df26d..c3175fb 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -542,6 +542,10 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf)
     bdrv_set_removable(s->bs, 0);
     s->bs->buffer_alignment = conf->logical_block_size;
 
+    if (conf->bootindex >= 0) {
+        qdev_add_boot_device_path(conf->bootindex, dev, "virtio-disk@0");
+    }
+
     return &s->vdev;
 }
 
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 7e1688c..75a4407 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -1018,6 +1018,10 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf,
                     virtio_net_save, virtio_net_load, n);
     n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change, n);
 
+    if (conf->bootindex >= 0) {
+        qdev_add_boot_device_path(conf->bootindex, dev, "ethernet-phy@0");
+    }
+
     return &n->vdev;
 }
 
diff --git a/net.h b/net.h
index 44c31a9..6ceca50 100644
--- a/net.h
+++ b/net.h
@@ -17,12 +17,14 @@ typedef struct NICConf {
     MACAddr macaddr;
     VLANState *vlan;
     VLANClientState *peer;
+    int32_t bootindex;
 } NICConf;
 
 #define DEFINE_NIC_PROPERTIES(_state, _conf)                            \
     DEFINE_PROP_MACADDR("mac",   _state, _conf.macaddr),                \
     DEFINE_PROP_VLAN("vlan",     _state, _conf.vlan),                   \
-    DEFINE_PROP_NETDEV("netdev", _state, _conf.peer)
+    DEFINE_PROP_NETDEV("netdev", _state, _conf.peer),                   \
+    DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1)
 
 /* VLANs support */
 
diff --git a/sysemu.h b/sysemu.h
index 849dc8c..cc35731 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -193,4 +193,13 @@ void rtc_change_mon_event(struct tm *tm);
 
 void register_devices(void);
 
+typedef struct FWBootEntry FWBootEntry;
+
+struct FWBootEntry {
+    QTAILQ_ENTRY(FWBootEntry) link;
+    int32_t bootindex;
+    char *fw_device_path;
+};
+
+void add_boot_device_path(int32_t bootindex, char *fw_device_path);
 #endif
diff --git a/vl.c b/vl.c
index 42617c2..25d5767 100644
--- a/vl.c
+++ b/vl.c
@@ -234,6 +234,8 @@ const char *prom_envs[MAX_PROM_ENVS];
 const char *nvram = NULL;
 int boot_menu;
 
+QTAILQ_HEAD(, FWBootEntry) fw_boot_order = QTAILQ_HEAD_INITIALIZER(fw_boot_order);
+
 int nb_numa_nodes;
 uint64_t node_mem[MAX_NODES];
 uint64_t node_cpumask[MAX_NODES];
@@ -722,6 +724,28 @@ static void restore_boot_devices(void *opaque)
     qemu_free(standard_boot_devices);
 }
 
+void add_boot_device_path(int32_t bootindex, char *fw_device_path)
+{
+    FWBootEntry *node = qemu_mallocz(sizeof(FWBootEntry)), *i;
+
+    node->bootindex = bootindex;
+    node->fw_device_path = fw_device_path;
+
+    printf("adding '%s' at index %d\n", fw_device_path, bootindex);
+    QTAILQ_FOREACH(i, &fw_boot_order, link) {
+        if (i->bootindex == bootindex) {
+            fprintf(stderr, "Two devices with same boot index %d (%s %s)\n",
+                    bootindex, i->fw_device_path, fw_device_path);
+            exit(1);
+        } else if (i->bootindex < bootindex) {
+            continue;
+        }
+        QTAILQ_INSERT_BEFORE(i, node, link);
+        return;
+    }
+    QTAILQ_INSERT_TAIL(&fw_boot_order, node, link);
+}
+
 static void numa_add(const char *optarg)
 {
     char option[128];
-- 
1.7.1

Re: [PATCHv2 0/8 RFC] boot order specification

[Kevin O'Connor]

On Sun, Oct 31, 2010 at 01:40:01PM +0200, Gleb Natapov wrote:
> This is current sate of the patch series for people to comment on.
> I tried to use open firmware naming scheme to specify device path names.
> 
> The patch series produce names like these:
> for pci machine:
> /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@0
> /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@1
> /pci@i0cf8/ata@1,1/ata-disk@1:0
> /pci@i0cf8/ata@1,1/ata-disk@1:1
> /pci@i0cf8/virtio-blk@3/virtio-disk@0
> /pci@i0cf8/ethernet@4/ethernet-phy@0
> /pci@i0cf8/ethernet@5/ethernet-phy@0
> 
> for isa machine:
> adding '/isa/fdc@03f1/floppy@0' at index 2
> adding '/isa/fdc@03f1/floppy@1' at index 1
> adding '/isa/ata@0170/ata-disk@0:0' at index 0
> adding '/isa/ata@0170/ata-disk@0:1' at index 3

Hi Gleb,

How will USB drives be identified?

I'm not sure how SeaBIOS will be able to line up something like
"/pci@i0cf8/ethernet@4/ethernet-phy@0" to an optionrom BEV.  Also, if
there is an optionrom with BCVs (eg, a scsi card), I'm not sure how
that would that would be identified.

-Kevin

[Qemu-devel] Re: [PATCHv2 0/8 RFC] boot order specification

[Kevin O'Connor]

On Sun, Oct 31, 2010 at 01:40:01PM +0200, Gleb Natapov wrote:
> This is current sate of the patch series for people to comment on.
> I tried to use open firmware naming scheme to specify device path names.
> 
> The patch series produce names like these:
> for pci machine:
> /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@0
> /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@1
> /pci@i0cf8/ata@1,1/ata-disk@1:0
> /pci@i0cf8/ata@1,1/ata-disk@1:1
> /pci@i0cf8/virtio-blk@3/virtio-disk@0
> /pci@i0cf8/ethernet@4/ethernet-phy@0
> /pci@i0cf8/ethernet@5/ethernet-phy@0
> 
> for isa machine:
> adding '/isa/fdc@03f1/floppy@0' at index 2
> adding '/isa/fdc@03f1/floppy@1' at index 1
> adding '/isa/ata@0170/ata-disk@0:0' at index 0
> adding '/isa/ata@0170/ata-disk@0:1' at index 3

Hi Gleb,

How will USB drives be identified?

I'm not sure how SeaBIOS will be able to line up something like
"/pci@i0cf8/ethernet@4/ethernet-phy@0" to an optionrom BEV.  Also, if
there is an optionrom with BCVs (eg, a scsi card), I'm not sure how
that would that would be identified.

-Kevin

Re: [PATCHv2 0/8 RFC] boot order specification

[Gleb Natapov]

On Sun, Oct 31, 2010 at 06:25:53PM -0400, Kevin O'Connor wrote:
> On Sun, Oct 31, 2010 at 01:40:01PM +0200, Gleb Natapov wrote:
> > This is current sate of the patch series for people to comment on.
> > I tried to use open firmware naming scheme to specify device path names.
> > 
> > The patch series produce names like these:
> > for pci machine:
> > /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@0
> > /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@1
> > /pci@i0cf8/ata@1,1/ata-disk@1:0
> > /pci@i0cf8/ata@1,1/ata-disk@1:1
> > /pci@i0cf8/virtio-blk@3/virtio-disk@0
> > /pci@i0cf8/ethernet@4/ethernet-phy@0
> > /pci@i0cf8/ethernet@5/ethernet-phy@0
> > 
> > for isa machine:
> > adding '/isa/fdc@03f1/floppy@0' at index 2
> > adding '/isa/fdc@03f1/floppy@1' at index 1
> > adding '/isa/ata@0170/ata-disk@0:0' at index 0
> > adding '/isa/ata@0170/ata-disk@0:1' at index 3
> 
> Hi Gleb,
> 
> How will USB drives be identified?
> 
USB bus has Open Firmware binding. I haven't look at the spec yet, but it
should be easy.

> I'm not sure how SeaBIOS will be able to line up something like
> "/pci@i0cf8/ethernet@4/ethernet-phy@0" to an optionrom BEV.  Also, if
> there is an optionrom with BCVs (eg, a scsi card), I'm not sure how
> that would that would be identified.

The way to parse  "/pci@i0cf8/ethernet@4/ethernet-phy@0" is this: each
element (between /.../) consist of node-name@unit-address. node-name
describes device/bus. unit-address is a device address on preceding node.
So pci@i0cf8 tells us that this is pci bus accessible through io
register 0x0cf8, ethernet@4 tells us that this is ethernet device in pci
slot 4 function 0, (ata@1,1 means ata device in slot 1 function 1).
ethernet-phy@0 means first phy on this ethernet device (usually there is
only one anyway). So if the pci card in slot 4 device 0 has optionrom
with BCV Seabios can associate bootindex with it easily given the 
device path above.

--
			Gleb.

[Qemu-devel] Re: [PATCHv2 0/8 RFC] boot order specification

[Gleb Natapov]

On Sun, Oct 31, 2010 at 06:25:53PM -0400, Kevin O'Connor wrote:
> On Sun, Oct 31, 2010 at 01:40:01PM +0200, Gleb Natapov wrote:
> > This is current sate of the patch series for people to comment on.
> > I tried to use open firmware naming scheme to specify device path names.
> > 
> > The patch series produce names like these:
> > for pci machine:
> > /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@0
> > /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@1
> > /pci@i0cf8/ata@1,1/ata-disk@1:0
> > /pci@i0cf8/ata@1,1/ata-disk@1:1
> > /pci@i0cf8/virtio-blk@3/virtio-disk@0
> > /pci@i0cf8/ethernet@4/ethernet-phy@0
> > /pci@i0cf8/ethernet@5/ethernet-phy@0
> > 
> > for isa machine:
> > adding '/isa/fdc@03f1/floppy@0' at index 2
> > adding '/isa/fdc@03f1/floppy@1' at index 1
> > adding '/isa/ata@0170/ata-disk@0:0' at index 0
> > adding '/isa/ata@0170/ata-disk@0:1' at index 3
> 
> Hi Gleb,
> 
> How will USB drives be identified?
> 
USB bus has Open Firmware binding. I haven't look at the spec yet, but it
should be easy.

> I'm not sure how SeaBIOS will be able to line up something like
> "/pci@i0cf8/ethernet@4/ethernet-phy@0" to an optionrom BEV.  Also, if
> there is an optionrom with BCVs (eg, a scsi card), I'm not sure how
> that would that would be identified.

The way to parse  "/pci@i0cf8/ethernet@4/ethernet-phy@0" is this: each
element (between /.../) consist of node-name@unit-address. node-name
describes device/bus. unit-address is a device address on preceding node.
So pci@i0cf8 tells us that this is pci bus accessible through io
register 0x0cf8, ethernet@4 tells us that this is ethernet device in pci
slot 4 function 0, (ata@1,1 means ata device in slot 1 function 1).
ethernet-phy@0 means first phy on this ethernet device (usually there is
only one anyway). So if the pci card in slot 4 device 0 has optionrom
with BCV Seabios can associate bootindex with it easily given the 
device path above.

--
			Gleb.

Re: [Qemu-devel] Re: [PATCHv2 0/8 RFC] boot order specification

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> On Sun, Oct 31, 2010 at 06:25:53PM -0400, Kevin O'Connor wrote:
>> On Sun, Oct 31, 2010 at 01:40:01PM +0200, Gleb Natapov wrote:
>> > This is current sate of the patch series for people to comment on.
>> > I tried to use open firmware naming scheme to specify device path names.
>> > 
>> > The patch series produce names like these:
>> > for pci machine:
>> > /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@0
>> > /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@1
>> > /pci@i0cf8/ata@1,1/ata-disk@1:0
>> > /pci@i0cf8/ata@1,1/ata-disk@1:1
>> > /pci@i0cf8/virtio-blk@3/virtio-disk@0
>> > /pci@i0cf8/ethernet@4/ethernet-phy@0
>> > /pci@i0cf8/ethernet@5/ethernet-phy@0
>> > 
>> > for isa machine:
>> > adding '/isa/fdc@03f1/floppy@0' at index 2
>> > adding '/isa/fdc@03f1/floppy@1' at index 1
>> > adding '/isa/ata@0170/ata-disk@0:0' at index 0
>> > adding '/isa/ata@0170/ata-disk@0:1' at index 3
>> 
>> Hi Gleb,
>> 
>> How will USB drives be identified?
>> 
> USB bus has Open Firmware binding. I haven't look at the spec yet, but it
> should be easy.
>
>> I'm not sure how SeaBIOS will be able to line up something like
>> "/pci@i0cf8/ethernet@4/ethernet-phy@0" to an optionrom BEV.  Also, if
>> there is an optionrom with BCVs (eg, a scsi card), I'm not sure how
>> that would that would be identified.
>
> The way to parse  "/pci@i0cf8/ethernet@4/ethernet-phy@0" is this: each
> element (between /.../) consist of node-name@unit-address. node-name
> describes device/bus. unit-address is a device address on preceding node.
> So pci@i0cf8 tells us that this is pci bus accessible through io
> register 0x0cf8, ethernet@4 tells us that this is ethernet device in pci
> slot 4 function 0, (ata@1,1 means ata device in slot 1 function 1).

Aren't "ethernet" and "ata" redundant there?

> ethernet-phy@0 means first phy on this ethernet device (usually there is
> only one anyway). So if the pci card in slot 4 device 0 has optionrom
> with BCV Seabios can associate bootindex with it easily given the 
> device path above.

Re: [Qemu-devel] Re: [PATCHv2 0/8 RFC] boot order specification

[Gleb Natapov]

On Thu, Nov 04, 2010 at 10:24:45AM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > On Sun, Oct 31, 2010 at 06:25:53PM -0400, Kevin O'Connor wrote:
> >> On Sun, Oct 31, 2010 at 01:40:01PM +0200, Gleb Natapov wrote:
> >> > This is current sate of the patch series for people to comment on.
> >> > I tried to use open firmware naming scheme to specify device path names.
> >> > 
> >> > The patch series produce names like these:
> >> > for pci machine:
> >> > /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@0
> >> > /pci@i0cf8/pci-isa-bridge@1/fdc@03f1/floppy@1
> >> > /pci@i0cf8/ata@1,1/ata-disk@1:0
> >> > /pci@i0cf8/ata@1,1/ata-disk@1:1
> >> > /pci@i0cf8/virtio-blk@3/virtio-disk@0
> >> > /pci@i0cf8/ethernet@4/ethernet-phy@0
> >> > /pci@i0cf8/ethernet@5/ethernet-phy@0
> >> > 
> >> > for isa machine:
> >> > adding '/isa/fdc@03f1/floppy@0' at index 2
> >> > adding '/isa/fdc@03f1/floppy@1' at index 1
> >> > adding '/isa/ata@0170/ata-disk@0:0' at index 0
> >> > adding '/isa/ata@0170/ata-disk@0:1' at index 3
> >> 
> >> Hi Gleb,
> >> 
> >> How will USB drives be identified?
> >> 
> > USB bus has Open Firmware binding. I haven't look at the spec yet, but it
> > should be easy.
> >
> >> I'm not sure how SeaBIOS will be able to line up something like
> >> "/pci@i0cf8/ethernet@4/ethernet-phy@0" to an optionrom BEV.  Also, if
> >> there is an optionrom with BCVs (eg, a scsi card), I'm not sure how
> >> that would that would be identified.
> >
> > The way to parse  "/pci@i0cf8/ethernet@4/ethernet-phy@0" is this: each
> > element (between /.../) consist of node-name@unit-address. node-name
> > describes device/bus. unit-address is a device address on preceding node.
> > So pci@i0cf8 tells us that this is pci bus accessible through io
> > register 0x0cf8, ethernet@4 tells us that this is ethernet device in pci
> > slot 4 function 0, (ata@1,1 means ata device in slot 1 function 1).
> 
> Aren't "ethernet" and "ata" redundant there?
> 
In case of PCI bus yes. If parent bus does not allow to query device
type they are not.

--
			Gleb.