[Qemu-devel] [PATCH 0/5] boot order specification

[Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

This is current sate of the patch series for people to comment on.
I dropped ioport double reservation checking from isa-bus and added
bus_id field for IDE bus since as Markus pointed out unit has different
meaning there.

This patch series produce names like:

ISA@03f1-03f5,03f7/fd@a
ISA@03f1-03f5,03f7/fd@b
PCI@0000:00:01.1/IDE@1:0
PCI@0000:00:01.1/IDE@1:1
PCI@0000:00:03.0/virtio-blk@0
PCI@0000:00:04.0/virtio-net@0

They will be passed to BIOS to determine boot order.

Gleb Natapov (5):
  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 bootindex parameter to net/block/fd device

 block_int.h       |    4 ++-
 hw/cs4231a.c      |    1 +
 hw/fdc.c          |   39 ++++++++++++++++++++++++++++++++
 hw/gus.c          |    4 +++
 hw/ide/cmd646.c   |    4 +-
 hw/ide/internal.h |    3 +-
 hw/ide/isa.c      |    4 ++-
 hw/ide/piix.c     |    4 +-
 hw/ide/qdev.c     |   40 ++++++++++++++++++++++++++++++++-
 hw/ide/via.c      |    4 +-
 hw/isa-bus.c      |   64 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 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 +
 hw/virtio-blk.c   |   20 ++++++++++++++++
 hw/virtio-net.c   |   20 ++++++++++++++++
 net.h             |    4 ++-
 sysemu.h          |    9 +++++++
 vl.c              |   24 +++++++++++++++++++
 24 files changed, 259 insertions(+), 11 deletions(-)

[Qemu-devel] [PATCH 1/5] 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 c159dcb..1f38d0d 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 6b57e0d..163ffba 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 4e306de..12938f5 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

Re: [Qemu-devel] [PATCH 1/5] Keep track of ISA ports ISA device is using in qdev.

[Anthony Liguori]

On 10/26/2010 05:48 AM, Gleb Natapov wrote:
> 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);
>    

A better way to do this would be to introduce isa_register_ioport.

We can take Avi's series first since that probably makes this easier to 
implement.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 1/5] Keep track of ISA ports ISA device is using in qdev.

[Gleb Natapov]

On Tue, Oct 26, 2010 at 08:25:14AM -0500, Anthony Liguori wrote:
> On 10/26/2010 05:48 AM, Gleb Natapov wrote:
> >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);
> 
> A better way to do this would be to introduce isa_register_ioport.
> 

That what Markus proposed and, in principal, I agree. I would like to
keep that out from this path series, but if it is not a big churn and
maintainers insists I can look at it. I need to do something anyway
while Markus is cooling down :)

> We can take Avi's series first since that probably makes this easier
> to implement.
> 
It is ready to go in, no?

--
			Gleb.

Re: [Qemu-devel] [PATCH 1/5] Keep track of ISA ports ISA device is using in qdev.

[Anthony Liguori]

On 10/26/2010 08:30 AM, Gleb Natapov wrote:
>> We can take Avi's series first since that probably makes this easier
>> to implement.
>>
>>      
> It is ready to go in, no?
>    

I think so but I waiting to give Blue Swirl a chance to comment a bit more.

Regards,

Anthony Liguori

> --
> 			Gleb.
>    

Re: [Qemu-devel] [PATCH 1/5] Keep track of ISA ports ISA device is using in qdev.

[Blue Swirl]

On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
> 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);

I'd prefer a system where the also register_ioport_xxx  (or even its
handle-returning equivalent) would be done by isa-bus.c (or pci.c).
Though maybe we could think of your patch as the first step.

[Qemu-devel] [PATCH 2/5] 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 |   39 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 12938f5..b2ddfb5 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)
@@ -187,4 +189,41 @@ static void isabus_register_devices(void)
     sysbus_register_withprop(&isabus_bridge_info);
 }
 
+static int find_range_end(ISADevice *d, int i)
+{
+    uint16_t p = d->ioports[i++];
+
+    while (i < d->nioports) {
+        if (d->ioports[i] - p != 1) {
+            break;
+        }
+        p = d->ioports[i++];
+    }
+    return i - 1;
+}
+
+static char *isabus_get_dev_path(DeviceState *dev)
+{
+    ISADevice *d = (ISADevice*)dev;
+    char path[100];
+    int i = 0, off = 0;
+
+    while (i < d->nioports) {
+        int e = find_range_end(d, i);
+        if (off)
+            path[off++] = ',';
+        if (i == e) {
+            off += snprintf(path + off, sizeof(path) - off, "%04x",
+                            d->ioports[i]);
+            i++;
+        } else {
+            off += snprintf(path + off, sizeof(path) - off, "%04x-%04x",
+                            d->ioports[i], d->ioports[e]);
+            i = e + 1;
+        }
+    }
+
+    return strdup(path);
+}
+
 device_init(isabus_register_devices)
-- 
1.7.1

[Qemu-devel] [PATCH 3/5] 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 163ffba..907d862 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 07483e8..d0b04a3 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 0808760..97a666d 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] [PATCH 4/5] Add get_dev_path callback to IDE bus.

[Gleb Natapov]

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

diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 97a666d..ab72a85 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,16 @@ 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[10];
+
+    snprintf(path, sizeof(path), "%d:%d", ((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] [PATCH 5/5] 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/fdc.c        |   36 ++++++++++++++++++++++++++++++++++++
 hw/ide/qdev.c   |   24 ++++++++++++++++++++++++
 hw/virtio-blk.c |   20 ++++++++++++++++++++
 hw/virtio-net.c |   20 ++++++++++++++++++++
 net.h           |    4 +++-
 sysemu.h        |    9 +++++++++
 vl.c            |   24 ++++++++++++++++++++++++
 8 files changed, 139 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/fdc.c b/hw/fdc.c
index 1f38d0d..9d0dff5 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)
@@ -1974,6 +1977,7 @@ static int isabus_fdc_init1(ISADevice *dev)
     int isairq = 6;
     int dma_chann = 2;
     int ret;
+    char devpath[30], *bus_name;
 
     register_ioport_read(iobase + 0x01, 5, 1,
                          &fdctrl_read_port, fdctrl);
@@ -1992,6 +1996,36 @@ static int isabus_fdc_init1(ISADevice *dev)
     qdev_set_legacy_instance_id(&dev->qdev, iobase, 2);
     ret = fdctrl_init_common(fdctrl);
 
+    if (ret) {
+        return ret;
+    }
+
+    if (isa->bootindexA < 0 && isa->bootindexB < 0) {
+        return 0;
+    }
+
+    if (!dev->qdev.parent_bus->info->get_dev_path) {
+        fprintf(stderr, "Can't create device path for floppy\n");
+        return 0;
+    }
+
+    bus_name = dev->qdev.parent_bus->info->get_dev_path(&dev->qdev);
+
+    if (isa->bootindexA >= 0) {
+        snprintf(devpath, sizeof(devpath), "%s@%s/fd@a",
+                 dev->qdev.parent_bus->info->name, bus_name);
+
+        add_boot_device_path(isa->bootindexA, strdup(devpath));
+    }
+
+    if (isa->bootindexB >= 0) {
+        snprintf(devpath, sizeof(devpath), "%s@%s/fd@b",
+                 dev->qdev.parent_bus->info->name, bus_name);
+
+        add_boot_device_path(isa->bootindexB, strdup(devpath));
+    }
+
+    qemu_free(bus_name);
     return ret;
 }
 
@@ -2050,6 +2084,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 ab72a85..f4b559b 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"
 
 /* --------------------------------- */
 
@@ -123,6 +124,8 @@ static int ide_drive_initfn(IDEDevice *dev)
     IDEState *s = bus->ifs + dev->unit;
     const char *serial;
     DriveInfo *dinfo;
+    char *ide_bus, *pbus, devpath[100];
+    DeviceState *pdev = bus->qbus.parent;
 
     serial = dev->serial;
     if (!serial) {
@@ -143,6 +146,27 @@ static int ide_drive_initfn(IDEDevice *dev)
     if (!dev->serial) {
         dev->serial = qemu_strdup(s->drive_serial_str);
     }
+
+    if (dev->conf.bootindex < 0) {
+        return 0;
+    }
+
+    if (!dev->qdev.parent_bus->info->get_dev_path ||
+        !pdev->parent_bus->info->get_dev_path) {
+        fprintf(stderr, "Can't create device path for IDE disk\n");
+        return 0;
+    }
+
+    ide_bus = dev->qdev.parent_bus->info->get_dev_path(&dev->qdev);
+    pbus = pdev->parent_bus->info->get_dev_path(pdev);
+
+    snprintf(devpath, sizeof(devpath), "%s@%s/%s@%s",
+             pdev->parent_bus->info->name, pbus, bus->qbus.info->name, ide_bus);
+
+    add_boot_device_path(dev->conf.bootindex, strdup(devpath));
+
+    qemu_free(ide_bus);
+    qemu_free(pbus);
     return 0;
 }
 
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index a1df26d..581ca56 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -504,6 +504,7 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf)
     int cylinders, heads, secs;
     static int virtio_blk_id;
     DriveInfo *dinfo;
+    char *bus_name, devpath[100];
 
     if (!conf->bs) {
         error_report("virtio-blk-pci: drive property not set");
@@ -542,6 +543,25 @@ 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) {
+        goto out;
+    }
+
+    if (!dev->parent_bus->info->get_dev_path) {
+        fprintf(stderr, "Can't create device path for virtio disk\n");
+        goto out;
+    }
+
+    bus_name = dev->parent_bus->info->get_dev_path(dev);
+
+    snprintf(devpath, sizeof(devpath), "%s@%s/virtio-blk@0",
+             dev->parent_bus->info->name, bus_name);
+
+    add_boot_device_path(conf->bootindex, strdup(devpath));
+
+    qemu_free(bus_name);
+
+out:
     return &s->vdev;
 }
 
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 7e1688c..bc8a7d1 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -966,6 +966,7 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf,
                               virtio_net_conf *net)
 {
     VirtIONet *n;
+    char devpath[100], *bus_name;
 
     n = (VirtIONet *)virtio_common_init("virtio-net", VIRTIO_ID_NET,
                                         sizeof(struct virtio_net_config),
@@ -1018,6 +1019,25 @@ 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) {
+        goto out;
+    }
+
+    if (!dev->parent_bus->info->get_dev_path) {
+        fprintf(stderr, "Can't create device path for virtio net\n");
+        goto out;
+    }
+
+    bus_name = dev->parent_bus->info->get_dev_path(dev);
+
+    snprintf(devpath, sizeof(devpath), "%s@%s/virtio-net@0",
+             dev->parent_bus->info->name, bus_name);
+
+    add_boot_device_path(conf->bootindex, strdup(devpath));
+
+    qemu_free(bus_name);
+
+out:
     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: [Qemu-devel] [PATCH 5/5] Add bootindex parameter to net/block/fd device

[Anthony Liguori]

On 10/26/2010 05:48 AM, Gleb Natapov wrote:
> 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/fdc.c        |   36 ++++++++++++++++++++++++++++++++++++
>   hw/ide/qdev.c   |   24 ++++++++++++++++++++++++
>   hw/virtio-blk.c |   20 ++++++++++++++++++++
>   hw/virtio-net.c |   20 ++++++++++++++++++++
>   net.h           |    4 +++-
>   sysemu.h        |    9 +++++++++
>   vl.c            |   24 ++++++++++++++++++++++++
>   8 files changed, 139 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/fdc.c b/hw/fdc.c
> index 1f38d0d..9d0dff5 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)
> @@ -1974,6 +1977,7 @@ static int isabus_fdc_init1(ISADevice *dev)
>       int isairq = 6;
>       int dma_chann = 2;
>       int ret;
> +    char devpath[30], *bus_name;
>
>       register_ioport_read(iobase + 0x01, 5, 1,
>                            &fdctrl_read_port, fdctrl);
> @@ -1992,6 +1996,36 @@ static int isabus_fdc_init1(ISADevice *dev)
>       qdev_set_legacy_instance_id(&dev->qdev, iobase, 2);
>       ret = fdctrl_init_common(fdctrl);
>
> +    if (ret) {
> +        return ret;
> +    }
> +
> +    if (isa->bootindexA<  0&&  isa->bootindexB<  0) {
> +        return 0;
> +    }
> +
> +    if (!dev->qdev.parent_bus->info->get_dev_path) {
> +        fprintf(stderr, "Can't create device path for floppy\n");
> +        return 0;
> +    }
> +
> +    bus_name = dev->qdev.parent_bus->info->get_dev_path(&dev->qdev);
> +
> +    if (isa->bootindexA>= 0) {
> +        snprintf(devpath, sizeof(devpath), "%s@%s/fd@a",
> +                 dev->qdev.parent_bus->info->name, bus_name);
> +
> +        add_boot_device_path(isa->bootindexA, strdup(devpath));
> +    }
>    

Even if we're passing a string to SeaBIOS, we should probably keep the 
components structured.  Looks like there's four pieces of data: 1) a bus 
name 2) a bus path 3) a device name 4) a device path.

We derive (1) from the qdev structure, why don't we derive (3) too?

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 5/5] Add bootindex parameter to net/block/fd device

[Gleb Natapov]

On Tue, Oct 26, 2010 at 08:29:21AM -0500, Anthony Liguori wrote:
> On 10/26/2010 05:48 AM, Gleb Natapov wrote:
> >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/fdc.c        |   36 ++++++++++++++++++++++++++++++++++++
> >  hw/ide/qdev.c   |   24 ++++++++++++++++++++++++
> >  hw/virtio-blk.c |   20 ++++++++++++++++++++
> >  hw/virtio-net.c |   20 ++++++++++++++++++++
> >  net.h           |    4 +++-
> >  sysemu.h        |    9 +++++++++
> >  vl.c            |   24 ++++++++++++++++++++++++
> >  8 files changed, 139 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/fdc.c b/hw/fdc.c
> >index 1f38d0d..9d0dff5 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)
> >@@ -1974,6 +1977,7 @@ static int isabus_fdc_init1(ISADevice *dev)
> >      int isairq = 6;
> >      int dma_chann = 2;
> >      int ret;
> >+    char devpath[30], *bus_name;
> >
> >      register_ioport_read(iobase + 0x01, 5, 1,
> >                           &fdctrl_read_port, fdctrl);
> >@@ -1992,6 +1996,36 @@ static int isabus_fdc_init1(ISADevice *dev)
> >      qdev_set_legacy_instance_id(&dev->qdev, iobase, 2);
> >      ret = fdctrl_init_common(fdctrl);
> >
> >+    if (ret) {
> >+        return ret;
> >+    }
> >+
> >+    if (isa->bootindexA<  0&&  isa->bootindexB<  0) {
> >+        return 0;
> >+    }
> >+
> >+    if (!dev->qdev.parent_bus->info->get_dev_path) {
> >+        fprintf(stderr, "Can't create device path for floppy\n");
> >+        return 0;
> >+    }
> >+
> >+    bus_name = dev->qdev.parent_bus->info->get_dev_path(&dev->qdev);
> >+
> >+    if (isa->bootindexA>= 0) {
> >+        snprintf(devpath, sizeof(devpath), "%s@%s/fd@a",
> >+                 dev->qdev.parent_bus->info->name, bus_name);
> >+
> >+        add_boot_device_path(isa->bootindexA, strdup(devpath));
> >+    }
> 
> Even if we're passing a string to SeaBIOS, we should probably keep
> the components structured.  Looks like there's four pieces of data:
> 1) a bus name 2) a bus path 3) a device name 4) a device path.
> 
This is pretty much device dependant. For ide it is 1) grandparent bus
name 2) grandparent bus path 3) parent bus name 4) parent bus path.

For floppy it is 1) parent bus name 2) parent bus path 3) drive name
(since one device have two disk attached to boot from).

> We derive (1) from the qdev structure, why don't we derive (3) too?
> 
We can if they are stable. They are a little bit redundant though. For
instance floppy will have isa-fdc there, but we already know that we
are on isa bus from previous path element. The same with virtio. We will
have virtio-net-pci/virtio-blk-pci there. Looks like QDEVism that leaks
into ABI. I actually consider all nic devices to be like
"PCI@0000:00:03.0/net@0" since BIOS should not really care what nic
it is.

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Bernhard Kohl]

Am 26.10.2010 12:48, schrieb ext Gleb Natapov:
> This is current sate of the patch series for people to comment on.
> I dropped ioport double reservation checking from isa-bus and added
> bus_id field for IDE bus since as Markus pointed out unit has different
> meaning there.
>
> This patch series produce names like:
>
> ISA@03f1-03f5,03f7/fd@a
> ISA@03f1-03f5,03f7/fd@b
> PCI@0000:00:01.1/IDE@1:0
> PCI@0000:00:01.1/IDE@1:1
> PCI@0000:00:03.0/virtio-blk@0
> PCI@0000:00:04.0/virtio-net@0
>    

Are PCI pass-through devices (SR-IOV NICs) also supported?
I assume that hw/device-assignment.c is missing from the changed files.
Our systems highly depend on PXE booting from these devices.

> They will be passed to BIOS to determine boot order.
>
> Gleb Natapov (5):
>    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 bootindex parameter to net/block/fd device
>
>   block_int.h       |    4 ++-
>   hw/cs4231a.c      |    1 +
>   hw/fdc.c          |   39 ++++++++++++++++++++++++++++++++
>   hw/gus.c          |    4 +++
>   hw/ide/cmd646.c   |    4 +-
>   hw/ide/internal.h |    3 +-
>   hw/ide/isa.c      |    4 ++-
>   hw/ide/piix.c     |    4 +-
>   hw/ide/qdev.c     |   40 ++++++++++++++++++++++++++++++++-
>   hw/ide/via.c      |    4 +-
>   hw/isa-bus.c      |   64 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>   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 +
>   hw/virtio-blk.c   |   20 ++++++++++++++++
>   hw/virtio-net.c   |   20 ++++++++++++++++
>   net.h             |    4 ++-
>   sysemu.h          |    9 +++++++
>   vl.c              |   24 +++++++++++++++++++
>   24 files changed, 259 insertions(+), 11 deletions(-)
>
>
>    

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

On Tue, Oct 26, 2010 at 02:40:51PM +0200, Bernhard Kohl wrote:
> Am 26.10.2010 12:48, schrieb ext Gleb Natapov:
> >This is current sate of the patch series for people to comment on.
> >I dropped ioport double reservation checking from isa-bus and added
> >bus_id field for IDE bus since as Markus pointed out unit has different
> >meaning there.
> >
> >This patch series produce names like:
> >
> >ISA@03f1-03f5,03f7/fd@a
> >ISA@03f1-03f5,03f7/fd@b
> >PCI@0000:00:01.1/IDE@1:0
> >PCI@0000:00:01.1/IDE@1:1
> >PCI@0000:00:03.0/virtio-blk@0
> >PCI@0000:00:04.0/virtio-net@0
> 
> Are PCI pass-through devices (SR-IOV NICs) also supported?
Don't see any problem. They are regular PCI devices as seen by
guest, correct? So I expect path to them will look like this:
PCI@0000:00:04.0/nic@0

> I assume that hw/device-assignment.c is missing from the changed files.
> Our systems highly depend on PXE booting from these devices.
> 
The patch is only an example. I converted only virtio-net to support
bootindex ATM.
 
--
			Gleb.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Bernhard Kohl]

Am 26.10.2010 15:07, schrieb ext Gleb Natapov:
> On Tue, Oct 26, 2010 at 02:40:51PM +0200, Bernhard Kohl wrote:
>    
>> Am 26.10.2010 12:48, schrieb ext Gleb Natapov:
>>      
>>> This is current sate of the patch series for people to comment on.
>>> I dropped ioport double reservation checking from isa-bus and added
>>> bus_id field for IDE bus since as Markus pointed out unit has different
>>> meaning there.
>>>
>>> This patch series produce names like:
>>>
>>> ISA@03f1-03f5,03f7/fd@a
>>> ISA@03f1-03f5,03f7/fd@b
>>> PCI@0000:00:01.1/IDE@1:0
>>> PCI@0000:00:01.1/IDE@1:1
>>> PCI@0000:00:03.0/virtio-blk@0
>>> PCI@0000:00:04.0/virtio-net@0
>>>        
>> Are PCI pass-through devices (SR-IOV NICs) also supported?
>>      
> Don't see any problem. They are regular PCI devices as seen by
> guest, correct?

Yes, that's true. And we add a bootrom on the qemu command line.
But this is already working and would not be changed.

> So I expect path to them will look like this:
> PCI@0000:00:04.0/nic@0
>    

Yes, that would be fine. I assume that each boot NIC,
e.g. e1000 gets its name here.

>    
>> I assume that hw/device-assignment.c is missing from the changed files.
>> Our systems highly depend on PXE booting from these devices.
>>
>>      
> The patch is only an example. I converted only virtio-net to support
> bootindex ATM.
>
> --
> 			Gleb.
>
>    

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

On Tue, Oct 26, 2010 at 03:35:38PM +0200, Bernhard Kohl wrote:
> Am 26.10.2010 15:07, schrieb ext Gleb Natapov:
> >On Tue, Oct 26, 2010 at 02:40:51PM +0200, Bernhard Kohl wrote:
> >>Am 26.10.2010 12:48, schrieb ext Gleb Natapov:
> >>>This is current sate of the patch series for people to comment on.
> >>>I dropped ioport double reservation checking from isa-bus and added
> >>>bus_id field for IDE bus since as Markus pointed out unit has different
> >>>meaning there.
> >>>
> >>>This patch series produce names like:
> >>>
> >>>ISA@03f1-03f5,03f7/fd@a
> >>>ISA@03f1-03f5,03f7/fd@b
> >>>PCI@0000:00:01.1/IDE@1:0
> >>>PCI@0000:00:01.1/IDE@1:1
> >>>PCI@0000:00:03.0/virtio-blk@0
> >>>PCI@0000:00:04.0/virtio-net@0
> >>Are PCI pass-through devices (SR-IOV NICs) also supported?
> >Don't see any problem. They are regular PCI devices as seen by
> >guest, correct?
> 
> Yes, that's true. And we add a bootrom on the qemu command line.
> But this is already working and would not be changed.
> 
> >So I expect path to them will look like this:
> >PCI@0000:00:04.0/nic@0
> 
> Yes, that would be fine. I assume that each boot NIC,
> e.g. e1000 gets its name here.
> 
Each boot nic sits on different PCI bus, so in fact nic (or
virtio-net) part is somewhat redundant. Each nic with specified
bootindex will be listed here.

> >>I assume that hw/device-assignment.c is missing from the changed files.
> >>Our systems highly depend on PXE booting from these devices.
> >>
> >The patch is only an example. I converted only virtio-net to support
> >bootindex ATM.
> >
> >--
> >			Gleb.
> >

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Blue Swirl]

On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
> This is current sate of the patch series for people to comment on.
> I dropped ioport double reservation checking from isa-bus and added
> bus_id field for IDE bus since as Markus pointed out unit has different
> meaning there.
>
> This patch series produce names like:
>
> ISA@03f1-03f5,03f7/fd@a
> ISA@03f1-03f5,03f7/fd@b
> PCI@0000:00:01.1/IDE@1:0
> PCI@0000:00:01.1/IDE@1:1
> PCI@0000:00:03.0/virtio-blk@0
> PCI@0000:00:04.0/virtio-net@0
>
> They will be passed to BIOS to determine boot order.

We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
those would be OpenFirmware tree name. I think your names should then
become:
/pci/isa/fdc@3f1/fd@0
/pci/isa/fdc@3f1/fd@1
/pci/ide@0/1,0
/pci/ide@0/1,1
/pci/virtio-net@1
/pci/virtio-net@2

The PCI addressing scheme in OF was a bit twisty, I just invented
integers in place of those.

Anyway, I don't think we should invent yet another device path naming system.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote:
> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
> > This is current sate of the patch series for people to comment on.
> > I dropped ioport double reservation checking from isa-bus and added
> > bus_id field for IDE bus since as Markus pointed out unit has different
> > meaning there.
> >
> > This patch series produce names like:
> >
> > ISA@03f1-03f5,03f7/fd@a
> > ISA@03f1-03f5,03f7/fd@b
> > PCI@0000:00:01.1/IDE@1:0
> > PCI@0000:00:01.1/IDE@1:1
> > PCI@0000:00:03.0/virtio-blk@0
> > PCI@0000:00:04.0/virtio-net@0
> >
> > They will be passed to BIOS to determine boot order.
> 
> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
> those would be OpenFirmware tree name. I think your names should then
> become:
> /pci/isa/fdc@3f1/fd@0
> /pci/isa/fdc@3f1/fd@1
Why is it PCI?

> /pci/ide@0/1,0
> /pci/ide@0/1,1
Where pci address here?

> /pci/virtio-net@1
> /pci/virtio-net@2
And here?

And we will need to describe ROMs too. I planned to have something like:
ROM@romfilename for roms loaded with -option-rom command line option.

> 
> The PCI addressing scheme in OF was a bit twisty, I just invented
> integers in place of those.
> 
> Anyway, I don't think we should invent yet another device path naming system.
IS this format documented somewhere? I am not attached to specific
format at all.

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Blue Swirl]

On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote:
>> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
>> > This is current sate of the patch series for people to comment on.
>> > I dropped ioport double reservation checking from isa-bus and added
>> > bus_id field for IDE bus since as Markus pointed out unit has different
>> > meaning there.
>> >
>> > This patch series produce names like:
>> >
>> > ISA@03f1-03f5,03f7/fd@a
>> > ISA@03f1-03f5,03f7/fd@b
>> > PCI@0000:00:01.1/IDE@1:0
>> > PCI@0000:00:01.1/IDE@1:1
>> > PCI@0000:00:03.0/virtio-blk@0
>> > PCI@0000:00:04.0/virtio-net@0
>> >
>> > They will be passed to BIOS to determine boot order.
>>
>> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
>> those would be OpenFirmware tree name. I think your names should then
>> become:
>> /pci/isa/fdc@3f1/fd@0
>> /pci/isa/fdc@3f1/fd@1
> Why is it PCI?

I just assumed a PCI to ISA bridge.

>> /pci/ide@0/1,0
>> /pci/ide@0/1,1
> Where pci address here?
>
>> /pci/virtio-net@1
>> /pci/virtio-net@2
> And here?

That was the part I invented.

> And we will need to describe ROMs too. I planned to have something like:
> ROM@romfilename for roms loaded with -option-rom command line option.

I don't think OF has standard for those.

>>
>> The PCI addressing scheme in OF was a bit twisty, I just invented
>> integers in place of those.
>>
>> Anyway, I don't think we should invent yet another device path naming system.
> IS this format documented somewhere? I am not attached to specific
> format at all.

A lot of docs are here:
http://playground.sun.com/pub/p1275/home.html

Here's the PCI bindings doc:
http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

On Tue, Oct 26, 2010 at 05:00:25PM +0000, Blue Swirl wrote:
> On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote:
> >> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
> >> > This is current sate of the patch series for people to comment on.
> >> > I dropped ioport double reservation checking from isa-bus and added
> >> > bus_id field for IDE bus since as Markus pointed out unit has different
> >> > meaning there.
> >> >
> >> > This patch series produce names like:
> >> >
> >> > ISA@03f1-03f5,03f7/fd@a
> >> > ISA@03f1-03f5,03f7/fd@b
> >> > PCI@0000:00:01.1/IDE@1:0
> >> > PCI@0000:00:01.1/IDE@1:1
> >> > PCI@0000:00:03.0/virtio-blk@0
> >> > PCI@0000:00:04.0/virtio-net@0
> >> >
> >> > They will be passed to BIOS to determine boot order.
> >>
> >> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
> >> those would be OpenFirmware tree name. I think your names should then
> >> become:
> >> /pci/isa/fdc@3f1/fd@0
> >> /pci/isa/fdc@3f1/fd@1
> > Why is it PCI?
> 
> I just assumed a PCI to ISA bridge.
> 
> >> /pci/ide@0/1,0
> >> /pci/ide@0/1,1
> > Where pci address here?
> >
> >> /pci/virtio-net@1
> >> /pci/virtio-net@2
> > And here?
> 
> That was the part I invented.
> 
> > And we will need to describe ROMs too. I planned to have something like:
> > ROM@romfilename for roms loaded with -option-rom command line option.
> 
> I don't think OF has standard for those.
> 
> >>
> >> The PCI addressing scheme in OF was a bit twisty, I just invented
> >> integers in place of those.
> >>
> >> Anyway, I don't think we should invent yet another device path naming system.
> > IS this format documented somewhere? I am not attached to specific
> > format at all.
> 
> A lot of docs are here:
> http://playground.sun.com/pub/p1275/home.html
Search for flat, device or tree returns nothing on this page.

But looking elsewhere I found some description of DTS. It is very
elaborate and looks like this:

/pci@xxx {
plenty of info here
}

The only example of /pci@xxx that I found is here
http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
format.

> 
> Here's the PCI bindings doc:
> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf
The funny thing is that pci address used in /pci@ example from wiki
above is incorrect according to this spec.

And I thought ACPI spec is confusing :) Can you clarify things a little
bit please?

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Blue Swirl]

On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Tue, Oct 26, 2010 at 05:00:25PM +0000, Blue Swirl wrote:
>> On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <gleb@redhat.com> wrote:
>> > On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote:
>> >> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
>> >> > This is current sate of the patch series for people to comment on.
>> >> > I dropped ioport double reservation checking from isa-bus and added
>> >> > bus_id field for IDE bus since as Markus pointed out unit has different
>> >> > meaning there.
>> >> >
>> >> > This patch series produce names like:
>> >> >
>> >> > ISA@03f1-03f5,03f7/fd@a
>> >> > ISA@03f1-03f5,03f7/fd@b
>> >> > PCI@0000:00:01.1/IDE@1:0
>> >> > PCI@0000:00:01.1/IDE@1:1
>> >> > PCI@0000:00:03.0/virtio-blk@0
>> >> > PCI@0000:00:04.0/virtio-net@0
>> >> >
>> >> > They will be passed to BIOS to determine boot order.
>> >>
>> >> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
>> >> those would be OpenFirmware tree name. I think your names should then
>> >> become:
>> >> /pci/isa/fdc@3f1/fd@0
>> >> /pci/isa/fdc@3f1/fd@1
>> > Why is it PCI?
>>
>> I just assumed a PCI to ISA bridge.
>>
>> >> /pci/ide@0/1,0
>> >> /pci/ide@0/1,1
>> > Where pci address here?
>> >
>> >> /pci/virtio-net@1
>> >> /pci/virtio-net@2
>> > And here?
>>
>> That was the part I invented.
>>
>> > And we will need to describe ROMs too. I planned to have something like:
>> > ROM@romfilename for roms loaded with -option-rom command line option.
>>
>> I don't think OF has standard for those.
>>
>> >>
>> >> The PCI addressing scheme in OF was a bit twisty, I just invented
>> >> integers in place of those.
>> >>
>> >> Anyway, I don't think we should invent yet another device path naming system.
>> > IS this format documented somewhere? I am not attached to specific
>> > format at all.
>>
>> A lot of docs are here:
>> http://playground.sun.com/pub/p1275/home.html
> Search for flat, device or tree returns nothing on this page.
>
> But looking elsewhere I found some description of DTS. It is very
> elaborate and looks like this:
>
> /pci@xxx {
> plenty of info here
> }
>
> The only example of /pci@xxx that I found is here
> http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
> format.

That's FDT, it's a bit different.

There are some trees here:
http://penguinppc.org/historical/dev-trees-html/trees-index.html

For example dual G4 500 has several /pci@xyz nodes.

>>
>> Here's the PCI bindings doc:
>> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf
> The funny thing is that pci address used in /pci@ example from wiki
> above is incorrect according to this spec.
>
> And I thought ACPI spec is confusing :) Can you clarify things a little
> bit please?

Perhaps you should start by reading the main OF document, it can be found in:
http://www.openfirmware.info/IEEE_1275-1994

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

On Tue, Oct 26, 2010 at 07:57:00PM +0000, Blue Swirl wrote:
> On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Oct 26, 2010 at 05:00:25PM +0000, Blue Swirl wrote:
> >> On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> > On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote:
> >> >> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
> >> >> > This is current sate of the patch series for people to comment on.
> >> >> > I dropped ioport double reservation checking from isa-bus and added
> >> >> > bus_id field for IDE bus since as Markus pointed out unit has different
> >> >> > meaning there.
> >> >> >
> >> >> > This patch series produce names like:
> >> >> >
> >> >> > ISA@03f1-03f5,03f7/fd@a
> >> >> > ISA@03f1-03f5,03f7/fd@b
> >> >> > PCI@0000:00:01.1/IDE@1:0
> >> >> > PCI@0000:00:01.1/IDE@1:1
> >> >> > PCI@0000:00:03.0/virtio-blk@0
> >> >> > PCI@0000:00:04.0/virtio-net@0
> >> >> >
> >> >> > They will be passed to BIOS to determine boot order.
> >> >>
> >> >> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
> >> >> those would be OpenFirmware tree name. I think your names should then
> >> >> become:
> >> >> /pci/isa/fdc@3f1/fd@0
> >> >> /pci/isa/fdc@3f1/fd@1
> >> > Why is it PCI?
> >>
> >> I just assumed a PCI to ISA bridge.
> >>
> >> >> /pci/ide@0/1,0
> >> >> /pci/ide@0/1,1
> >> > Where pci address here?
> >> >
> >> >> /pci/virtio-net@1
> >> >> /pci/virtio-net@2
> >> > And here?
> >>
> >> That was the part I invented.
> >>
> >> > And we will need to describe ROMs too. I planned to have something like:
> >> > ROM@romfilename for roms loaded with -option-rom command line option.
> >>
> >> I don't think OF has standard for those.
> >>
> >> >>
> >> >> The PCI addressing scheme in OF was a bit twisty, I just invented
> >> >> integers in place of those.
> >> >>
> >> >> Anyway, I don't think we should invent yet another device path naming system.
> >> > IS this format documented somewhere? I am not attached to specific
> >> > format at all.
> >>
> >> A lot of docs are here:
> >> http://playground.sun.com/pub/p1275/home.html
> > Search for flat, device or tree returns nothing on this page.
> >
> > But looking elsewhere I found some description of DTS. It is very
> > elaborate and looks like this:
> >
> > /pci@xxx {
> > plenty of info here
> > }
> >
> > The only example of /pci@xxx that I found is here
> > http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
> > format.
> 
> That's FDT, it's a bit different.
> 
> There are some trees here:
> http://penguinppc.org/historical/dev-trees-html/trees-index.html
> 
> For example dual G4 500 has several /pci@xyz nodes.
> 
Yes, it has: /pci@f0000000 for instance. Now lets try to decipher 
address f0000000 according to pci2_1.pdf below. It says:
The text representation of a PCI address is one of the following forms:
         DD
         DD,F
         [n]i[t]DD,F,RR,NNNNNNNN
         [n]m[t][p]DD,F,RR,NNNNNNNN
         [n]x[p]DD,F,RR,NNNNNNNNNNNNNNNN
    where:
         DD                         is an ASCII hexadecimal number in the range 0...1F
         F                          is an ASCII numeral in the range 0...7
         RR                         is an ASCII hexadecimal number in the range 0...FF
         NNNNNNNN                   is an ASCII hexadecimal number in the range 0...FFFFFFFF
         NNNNNNNNNNNNNNNN           is an ASCII hexadecimal number in the range 0...FFFFFFFFFFFFFFFF
         [n]                        is the letter 'n', whose presence is optional
         [t]                        is the letter 't', whose presence is optional
         [p]                        is the letter 'p', whose presence is optional
         i                          is the letter 'i'
         m                          is the letter 'm'
         x                          is the letter 'x'
         ,                          is the character ',' (comma)

Nothing resembles f0000000. There is also 2.2.1.1 Numerical Representation
but no luck there too. This number is illegal according to it. May be
this is memory address PCI bar is mapped into? But according to which
spec? And this kind of addressing has no meaning as interface between
qemu and firmware since qemu does not map PCI bars.

> >>
> >> Here's the PCI bindings doc:
> >> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf
> > The funny thing is that pci address used in /pci@ example from wiki
> > above is incorrect according to this spec.
> >
> > And I thought ACPI spec is confusing :) Can you clarify things a little
> > bit please?
> 
> Perhaps you should start by reading the main OF document, it can be found in:
> http://www.openfirmware.info/IEEE_1275-1994
Perhaps. But searching for PCI there returns nothing. What section
exactly should enlighten me? One interesting thing I found at the
beginning:
 1.1 Purpose and scope
 This document describes a software architecture for the firmware that
 controls a computer before the operating system has begun execution

Interfaces between firmware and OS is not always suitable for
qemu->guest communication.

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Blue Swirl]

On Tue, Oct 26, 2010 at 8:34 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Tue, Oct 26, 2010 at 07:57:00PM +0000, Blue Swirl wrote:
>> On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov <gleb@redhat.com> wrote:
>> > On Tue, Oct 26, 2010 at 05:00:25PM +0000, Blue Swirl wrote:
>> >> On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <gleb@redhat.com> wrote:
>> >> > On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote:
>> >> >> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
>> >> >> > This is current sate of the patch series for people to comment on.
>> >> >> > I dropped ioport double reservation checking from isa-bus and added
>> >> >> > bus_id field for IDE bus since as Markus pointed out unit has different
>> >> >> > meaning there.
>> >> >> >
>> >> >> > This patch series produce names like:
>> >> >> >
>> >> >> > ISA@03f1-03f5,03f7/fd@a
>> >> >> > ISA@03f1-03f5,03f7/fd@b
>> >> >> > PCI@0000:00:01.1/IDE@1:0
>> >> >> > PCI@0000:00:01.1/IDE@1:1
>> >> >> > PCI@0000:00:03.0/virtio-blk@0
>> >> >> > PCI@0000:00:04.0/virtio-net@0
>> >> >> >
>> >> >> > They will be passed to BIOS to determine boot order.
>> >> >>
>> >> >> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
>> >> >> those would be OpenFirmware tree name. I think your names should then
>> >> >> become:
>> >> >> /pci/isa/fdc@3f1/fd@0
>> >> >> /pci/isa/fdc@3f1/fd@1
>> >> > Why is it PCI?
>> >>
>> >> I just assumed a PCI to ISA bridge.
>> >>
>> >> >> /pci/ide@0/1,0
>> >> >> /pci/ide@0/1,1
>> >> > Where pci address here?
>> >> >
>> >> >> /pci/virtio-net@1
>> >> >> /pci/virtio-net@2
>> >> > And here?
>> >>
>> >> That was the part I invented.
>> >>
>> >> > And we will need to describe ROMs too. I planned to have something like:
>> >> > ROM@romfilename for roms loaded with -option-rom command line option.
>> >>
>> >> I don't think OF has standard for those.
>> >>
>> >> >>
>> >> >> The PCI addressing scheme in OF was a bit twisty, I just invented
>> >> >> integers in place of those.
>> >> >>
>> >> >> Anyway, I don't think we should invent yet another device path naming system.
>> >> > IS this format documented somewhere? I am not attached to specific
>> >> > format at all.
>> >>
>> >> A lot of docs are here:
>> >> http://playground.sun.com/pub/p1275/home.html
>> > Search for flat, device or tree returns nothing on this page.
>> >
>> > But looking elsewhere I found some description of DTS. It is very
>> > elaborate and looks like this:
>> >
>> > /pci@xxx {
>> > plenty of info here
>> > }
>> >
>> > The only example of /pci@xxx that I found is here
>> > http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
>> > format.
>>
>> That's FDT, it's a bit different.
>>
>> There are some trees here:
>> http://penguinppc.org/historical/dev-trees-html/trees-index.html
>>
>> For example dual G4 500 has several /pci@xyz nodes.
>>
> Yes, it has: /pci@f0000000 for instance. Now lets try to decipher
> address f0000000 according to pci2_1.pdf below. It says:
> The text representation of a PCI address is one of the following forms:
>         DD
>         DD,F
>         [n]i[t]DD,F,RR,NNNNNNNN
>         [n]m[t][p]DD,F,RR,NNNNNNNN
>         [n]x[p]DD,F,RR,NNNNNNNNNNNNNNNN
>    where:
>         DD                         is an ASCII hexadecimal number in the range 0...1F
>         F                          is an ASCII numeral in the range 0...7
>         RR                         is an ASCII hexadecimal number in the range 0...FF
>         NNNNNNNN                   is an ASCII hexadecimal number in the range 0...FFFFFFFF
>         NNNNNNNNNNNNNNNN           is an ASCII hexadecimal number in the range 0...FFFFFFFFFFFFFFFF
>         [n]                        is the letter 'n', whose presence is optional
>         [t]                        is the letter 't', whose presence is optional
>         [p]                        is the letter 'p', whose presence is optional
>         i                          is the letter 'i'
>         m                          is the letter 'm'
>         x                          is the letter 'x'
>         ,                          is the character ',' (comma)
>
> Nothing resembles f0000000. There is also 2.2.1.1 Numerical Representation
> but no luck there too. This number is illegal according to it. May be
> this is memory address PCI bar is mapped into? But according to which
> spec?

For PPC yes, but that depends on the system. This is described in the
common spec.

>And this kind of addressing has no meaning as interface between
> qemu and firmware since qemu does not map PCI bars.

No, but we still need to identify the devices. This could still be a
useful way to address them so that also the BIOS can identify them.
For example, this 0xf0000000 can be used by BIOS to probe for a PCI
controller.

>> >>
>> >> Here's the PCI bindings doc:
>> >> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf
>> > The funny thing is that pci address used in /pci@ example from wiki
>> > above is incorrect according to this spec.
>> >
>> > And I thought ACPI spec is confusing :) Can you clarify things a little
>> > bit please?
>>
>> Perhaps you should start by reading the main OF document, it can be found in:
>> http://www.openfirmware.info/IEEE_1275-1994
> Perhaps. But searching for PCI there returns nothing. What section
> exactly should enlighten me? One interesting thing I found at the
> beginning:
>  1.1 Purpose and scope
>  This document describes a software architecture for the firmware that
>  controls a computer before the operating system has begun execution
>
> Interfaces between firmware and OS is not always suitable for
> qemu->guest communication.

That can be true.

Next idea: If QEMU passed a FDT to BIOS, then the original boot device
problem could be solved by decorating various tree nodes with
"QEMU,boot" tags.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

On Tue, Oct 26, 2010 at 08:49:09PM +0000, Blue Swirl wrote:
> On Tue, Oct 26, 2010 at 8:34 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Oct 26, 2010 at 07:57:00PM +0000, Blue Swirl wrote:
> >> On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> > On Tue, Oct 26, 2010 at 05:00:25PM +0000, Blue Swirl wrote:
> >> >> On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> >> > On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote:
> >> >> >> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <gleb@redhat.com> wrote:
> >> >> >> > This is current sate of the patch series for people to comment on.
> >> >> >> > I dropped ioport double reservation checking from isa-bus and added
> >> >> >> > bus_id field for IDE bus since as Markus pointed out unit has different
> >> >> >> > meaning there.
> >> >> >> >
> >> >> >> > This patch series produce names like:
> >> >> >> >
> >> >> >> > ISA@03f1-03f5,03f7/fd@a
> >> >> >> > ISA@03f1-03f5,03f7/fd@b
> >> >> >> > PCI@0000:00:01.1/IDE@1:0
> >> >> >> > PCI@0000:00:01.1/IDE@1:1
> >> >> >> > PCI@0000:00:03.0/virtio-blk@0
> >> >> >> > PCI@0000:00:04.0/virtio-net@0
> >> >> >> >
> >> >> >> > They will be passed to BIOS to determine boot order.
> >> >> >>
> >> >> >> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for
> >> >> >> those would be OpenFirmware tree name. I think your names should then
> >> >> >> become:
> >> >> >> /pci/isa/fdc@3f1/fd@0
> >> >> >> /pci/isa/fdc@3f1/fd@1
> >> >> > Why is it PCI?
> >> >>
> >> >> I just assumed a PCI to ISA bridge.
> >> >>
> >> >> >> /pci/ide@0/1,0
> >> >> >> /pci/ide@0/1,1
> >> >> > Where pci address here?
> >> >> >
> >> >> >> /pci/virtio-net@1
> >> >> >> /pci/virtio-net@2
> >> >> > And here?
> >> >>
> >> >> That was the part I invented.
> >> >>
> >> >> > And we will need to describe ROMs too. I planned to have something like:
> >> >> > ROM@romfilename for roms loaded with -option-rom command line option.
> >> >>
> >> >> I don't think OF has standard for those.
> >> >>
> >> >> >>
> >> >> >> The PCI addressing scheme in OF was a bit twisty, I just invented
> >> >> >> integers in place of those.
> >> >> >>
> >> >> >> Anyway, I don't think we should invent yet another device path naming system.
> >> >> > IS this format documented somewhere? I am not attached to specific
> >> >> > format at all.
> >> >>
> >> >> A lot of docs are here:
> >> >> http://playground.sun.com/pub/p1275/home.html
> >> > Search for flat, device or tree returns nothing on this page.
> >> >
> >> > But looking elsewhere I found some description of DTS. It is very
> >> > elaborate and looks like this:
> >> >
> >> > /pci@xxx {
> >> > plenty of info here
> >> > }
> >> >
> >> > The only example of /pci@xxx that I found is here
> >> > http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
> >> > format.
> >>
> >> That's FDT, it's a bit different.
> >>
> >> There are some trees here:
> >> http://penguinppc.org/historical/dev-trees-html/trees-index.html
> >>
> >> For example dual G4 500 has several /pci@xyz nodes.
> >>
> > Yes, it has: /pci@f0000000 for instance. Now lets try to decipher
> > address f0000000 according to pci2_1.pdf below. It says:
> > The text representation of a PCI address is one of the following forms:
> >         DD
> >         DD,F
> >         [n]i[t]DD,F,RR,NNNNNNNN
> >         [n]m[t][p]DD,F,RR,NNNNNNNN
> >         [n]x[p]DD,F,RR,NNNNNNNNNNNNNNNN
> >    where:
> >         DD                         is an ASCII hexadecimal number in the range 0...1F
> >         F                          is an ASCII numeral in the range 0...7
> >         RR                         is an ASCII hexadecimal number in the range 0...FF
> >         NNNNNNNN                   is an ASCII hexadecimal number in the range 0...FFFFFFFF
> >         NNNNNNNNNNNNNNNN           is an ASCII hexadecimal number in the range 0...FFFFFFFFFFFFFFFF
> >         [n]                        is the letter 'n', whose presence is optional
> >         [t]                        is the letter 't', whose presence is optional
> >         [p]                        is the letter 'p', whose presence is optional
> >         i                          is the letter 'i'
> >         m                          is the letter 'm'
> >         x                          is the letter 'x'
> >         ,                          is the character ',' (comma)
> >
> > Nothing resembles f0000000. There is also 2.2.1.1 Numerical Representation
> > but no luck there too. This number is illegal according to it. May be
> > this is memory address PCI bar is mapped into? But according to which
> > spec?
> 
> For PPC yes, but that depends on the system. This is described in the
> common spec.
> 
Can you point me to PDF and page to read? I am lost in all this specs
especially as I can't find the link between specs and reality.

> >And this kind of addressing has no meaning as interface between
> > qemu and firmware since qemu does not map PCI bars.
> 
> No, but we still need to identify the devices. This could still be a
PCI address does this perfectly (for PCI devices).

> useful way to address them so that also the BIOS can identify them.
Qemu does not map PCI bars so it can't produce this number.

> For example, this 0xf0000000 can be used by BIOS to probe for a PCI
> controller.
How? This is just random address in PCI hole as far as qemu is conserned.

> 
> >> >>
> >> >> Here's the PCI bindings doc:
> >> >> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf
> >> > The funny thing is that pci address used in /pci@ example from wiki
> >> > above is incorrect according to this spec.
> >> >
> >> > And I thought ACPI spec is confusing :) Can you clarify things a little
> >> > bit please?
> >>
> >> Perhaps you should start by reading the main OF document, it can be found in:
> >> http://www.openfirmware.info/IEEE_1275-1994
> > Perhaps. But searching for PCI there returns nothing. What section
> > exactly should enlighten me? One interesting thing I found at the
> > beginning:
> >  1.1 Purpose and scope
> >  This document describes a software architecture for the firmware that
> >  controls a computer before the operating system has begun execution
> >
> > Interfaces between firmware and OS is not always suitable for
> > qemu->guest communication.
> 
> That can be true.
> 
> Next idea: If QEMU passed a FDT to BIOS, then the original boot device
> problem could be solved by decorating various tree nodes with
> "QEMU,boot" tags.

We will never agree on FDT implementation in qemu. Besides for PC you
don't really need it.  All devices either can be enumerated or at well
known to BIOS locations. And looking at the specs I'd rather go re-read
ACPI spec twice :) They have even examples there! If we had FDT in qemu
already I would agree with you that passing part of it to BIOS is a
reasonable solution for boot order problem, but implementing FDT to
solve it is overkill.

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Scott Wood]

On Tue, 26 Oct 2010 22:34:51 +0200
Gleb Natapov <gleb@redhat.com> wrote:

> On Tue, Oct 26, 2010 at 07:57:00PM +0000, Blue Swirl wrote:
> > On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > > But looking elsewhere I found some description of DTS. It is very
> > > elaborate and looks like this:
> > >
> > > /pci@xxx {
> > > plenty of info here
> > > }
> > >
> > > The only example of /pci@xxx that I found is here
> > > http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
> > > format.
> > 
> > That's FDT, it's a bit different.
> > 
> > There are some trees here:
> > http://penguinppc.org/historical/dev-trees-html/trees-index.html
> > 
> > For example dual G4 500 has several /pci@xyz nodes.
> > 
> Yes, it has: /pci@f0000000 for instance. Now lets try to decipher 
> address f0000000 according to pci2_1.pdf below. It says:
> The text representation of a PCI address is one of the following forms:
>          DD
>          DD,F
>          [n]i[t]DD,F,RR,NNNNNNNN
>          [n]m[t][p]DD,F,RR,NNNNNNNN
>          [n]x[p]DD,F,RR,NNNNNNNNNNNNNNNN
>     where:
>          DD                         is an ASCII hexadecimal number in the range 0...1F
>          F                          is an ASCII numeral in the range 0...7
>          RR                         is an ASCII hexadecimal number in the range 0...FF
>          NNNNNNNN                   is an ASCII hexadecimal number in the range 0...FFFFFFFF
>          NNNNNNNNNNNNNNNN           is an ASCII hexadecimal number in the range 0...FFFFFFFFFFFFFFFF
>          [n]                        is the letter 'n', whose presence is optional
>          [t]                        is the letter 't', whose presence is optional
>          [p]                        is the letter 'p', whose presence is optional
>          i                          is the letter 'i'
>          m                          is the letter 'm'
>          x                          is the letter 'x'
>          ,                          is the character ',' (comma)
> 
> Nothing resembles f0000000. There is also 2.2.1.1 Numerical Representation
> but no luck there too. This number is illegal according to it.

The encoding above applies to unit addresses inside the PCI bus node.

The unit address of the PCI controller node itself is encoded according
to its parent bus.

> May be this is memory address PCI bar is mapped into?

It should correspond to the node's reg property.

What's in the reg property depends on the binding for that particular
PCI controller.

-Scott

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

On Tue, Oct 26, 2010 at 04:14:24PM -0500, Scott Wood wrote:
> On Tue, 26 Oct 2010 22:34:51 +0200
> Gleb Natapov <gleb@redhat.com> wrote:
> 
> > On Tue, Oct 26, 2010 at 07:57:00PM +0000, Blue Swirl wrote:
> > > On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > > > But looking elsewhere I found some description of DTS. It is very
> > > > elaborate and looks like this:
> > > >
> > > > /pci@xxx {
> > > > plenty of info here
> > > > }
> > > >
> > > > The only example of /pci@xxx that I found is here
> > > > http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
> > > > format.
> > > 
> > > That's FDT, it's a bit different.
> > > 
> > > There are some trees here:
> > > http://penguinppc.org/historical/dev-trees-html/trees-index.html
> > > 
> > > For example dual G4 500 has several /pci@xyz nodes.
> > > 
> > Yes, it has: /pci@f0000000 for instance. Now lets try to decipher 
> > address f0000000 according to pci2_1.pdf below. It says:
> > The text representation of a PCI address is one of the following forms:
> >          DD
> >          DD,F
> >          [n]i[t]DD,F,RR,NNNNNNNN
> >          [n]m[t][p]DD,F,RR,NNNNNNNN
> >          [n]x[p]DD,F,RR,NNNNNNNNNNNNNNNN
> >     where:
> >          DD                         is an ASCII hexadecimal number in the range 0...1F
> >          F                          is an ASCII numeral in the range 0...7
> >          RR                         is an ASCII hexadecimal number in the range 0...FF
> >          NNNNNNNN                   is an ASCII hexadecimal number in the range 0...FFFFFFFF
> >          NNNNNNNNNNNNNNNN           is an ASCII hexadecimal number in the range 0...FFFFFFFFFFFFFFFF
> >          [n]                        is the letter 'n', whose presence is optional
> >          [t]                        is the letter 't', whose presence is optional
> >          [p]                        is the letter 'p', whose presence is optional
> >          i                          is the letter 'i'
> >          m                          is the letter 'm'
> >          x                          is the letter 'x'
> >          ,                          is the character ',' (comma)
> > 
> > Nothing resembles f0000000. There is also 2.2.1.1 Numerical Representation
> > but no luck there too. This number is illegal according to it.
> 
> The encoding above applies to unit addresses inside the PCI bus node.
> 
> The unit address of the PCI controller node itself is encoded according
> to its parent bus.
> 
Ah so to talk to pci controller OS writes to 0xf0000000?
http://penguinppc.org/historical/dev-trees-html/g4_agp_500_1.html has 3
such pci definitions:
/pci@f0000000
/pci@f2000000
/pci@f4000000
If G4 500 has 3 PCI domains it all makes perfect sense then.

> > May be this is memory address PCI bar is mapped into?
> 
> It should correspond to the node's reg property.
> 
> What's in the reg property depends on the binding for that particular
> PCI controller.
> 
> -Scott

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Scott Wood]

On Wed, 27 Oct 2010 10:57:12 +0200
Gleb Natapov <gleb@redhat.com> wrote:

> On Tue, Oct 26, 2010 at 04:14:24PM -0500, Scott Wood wrote:
> > On Tue, 26 Oct 2010 22:34:51 +0200
> > Gleb Natapov <gleb@redhat.com> wrote:
> > 
> > > Nothing resembles f0000000. There is also 2.2.1.1 Numerical Representation
> > > but no luck there too. This number is illegal according to it.
> > 
> > The encoding above applies to unit addresses inside the PCI bus node.
> > 
> > The unit address of the PCI controller node itself is encoded according
> > to its parent bus.
> > 
> Ah so to talk to pci controller OS writes to 0xf0000000?

Possibly, though I'm not familiar with Apple's PCI bindings.  It may be
e.g. the beginning of I/O or memory space instead (especially given
the large alignment and offset between successive buses).

On Freescale's PCI nodes it's the address of the PCI controller's
internal registers.

-Scott