[Qemu-devel] [PATCH 2/2] Add boot index documentation.

[Qemu-devel] [PATCH 2/2] Add boot index documentation.

[Gleb Natapov]

---
 docs/bootindex.txt |   42 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)
 create mode 100644 docs/bootindex.txt

diff --git a/docs/bootindex.txt b/docs/bootindex.txt
new file mode 100644
index 0000000..9609c7f
--- /dev/null
+++ b/docs/bootindex.txt
@@ -0,0 +1,42 @@
+= Bootindex property =
+
+Block and net devices have bootindex property. This property is used to
+determine the order in which firmware will consider devices for booting
+guest OS. If bootindex property is not set for a device it gets lowest
+boot priority. There is no particular order in which devices with unset
+bootindex property will be considered for booting, but they will still be
+bootable.
+
+== Example ==
+
+Lets assume we have QEMU machine with two NICs (virtio, e1000) and two
+disks (IDE, virtio):
+
+qemu -drive file=disk1.img,if=none,id=disk1
+     -device ide-drive,drive=disk1,bootindex=4
+     -drive file=disk2.img,if=none,id=disk2
+     -device virtio-blk-pci,drive=disk2,bootindex=3
+     -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0,bootindex=2
+     -netdev type=user,id=net1 -device e1000,netdev=net1,bootindex=1
+
+Given command like above firmware should try to boot guest OS from e1000
+NIC if this fails it should try virtio NIC next, if this fails too it
+should try virtio disk and then IDE disk.
+
+== Limitations ==
+
+1. Some firmware has limitation on order in which devices can be
+considered for booting. For instance PC bios boot specification allows
+only one disk to be bootable. If boot from disk fails for some reason
+bios cannot retry booting from other disk. It still can try to boot from
+floppy or net though.
+
+2. Sometimes firmware cannot map device path QEMU wants firmware to boot
+from to boot method. It doesn't happen for devices firmware can natively
+boot from, but if firmware relies on option rom for booting, and same
+option rom is used for booting from more then one device, firmware may
+not be able to ask option rom to boot from particular device reliably.
+For instance with PC bios if scsi HBA has three bootable devices target1,
+target3, target5, connected to it option rom will create boot method for
+each of them, but it is not possible to map boot method back to specific
+target. This is a shortcoming of PC bios boot specification.
-- 
1.7.2.3

[Qemu-devel] [PATCH 1/2] Add bootindex handling into usb storage device.

[Gleb Natapov]

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

diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 0a95d8d..46642a8 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -560,6 +560,7 @@ static int usb_msd_initfn(USBDevice *dev)
         }
     }
 
+    add_boot_device_path(s->conf.bootindex, &dev->qdev, "/disk@0,0");
     return 0;
 }
 
@@ -624,6 +625,7 @@ static USBDevice *usb_msd_init(const char *filename)
 static struct USBDeviceInfo msd_info = {
     .product_desc   = "QEMU USB MSD",
     .qdev.name      = "usb-storage",
+    .qdev.fw_name      = "storage",
     .qdev.size      = sizeof(MSDState),
     .init           = usb_msd_initfn,
     .handle_packet  = usb_generic_handle_packet,
-- 
1.7.2.3

[Qemu-devel] [PATCH 2/2] Add boot index documentation.

[Gleb Natapov]

Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
 docs/bootindex.txt |   42 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)
 create mode 100644 docs/bootindex.txt

diff --git a/docs/bootindex.txt b/docs/bootindex.txt
new file mode 100644
index 0000000..9609c7f
--- /dev/null
+++ b/docs/bootindex.txt
@@ -0,0 +1,42 @@
+= Bootindex property =
+
+Block and net devices have bootindex property. This property is used to
+determine the order in which firmware will consider devices for booting
+guest OS. If bootindex property is not set for a device it gets lowest
+boot priority. There is no particular order in which devices with unset
+bootindex property will be considered for booting, but they will still be
+bootable.
+
+== Example ==
+
+Lets assume we have QEMU machine with two NICs (virtio, e1000) and two
+disks (IDE, virtio):
+
+qemu -drive file=disk1.img,if=none,id=disk1
+     -device ide-drive,drive=disk1,bootindex=4
+     -drive file=disk2.img,if=none,id=disk2
+     -device virtio-blk-pci,drive=disk2,bootindex=3
+     -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0,bootindex=2
+     -netdev type=user,id=net1 -device e1000,netdev=net1,bootindex=1
+
+Given command like above firmware should try to boot guest OS from e1000
+NIC if this fails it should try virtio NIC next, if this fails too it
+should try virtio disk and then IDE disk.
+
+== Limitations ==
+
+1. Some firmware has limitation on order in which devices can be
+considered for booting. For instance PC bios boot specification allows
+only one disk to be bootable. If boot from disk fails for some reason
+bios cannot retry booting from other disk. It still can try to boot from
+floppy or net though.
+
+2. Sometimes firmware cannot map device path QEMU wants firmware to boot
+from to boot method. It doesn't happen for devices firmware can natively
+boot from, but if firmware relies on option rom for booting, and same
+option rom is used for booting from more then one device, firmware may
+not be able to ask option rom to boot from particular device reliably.
+For instance with PC bios if scsi HBA has three bootable devices target1,
+target3, target5, connected to it option rom will create boot method for
+each of them, but it is not possible to map boot method back to specific
+target. This is a shortcoming of PC bios boot specification.
-- 
1.7.2.3

Re: [Qemu-devel] [PATCH 1/2] Add bootindex handling into usb storage device.

[Gleb Natapov]

ping?

On Sun, Jan 02, 2011 at 05:07:30PM +0200, Gleb Natapov wrote:
> 
> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  hw/usb-msd.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/usb-msd.c b/hw/usb-msd.c
> index 0a95d8d..46642a8 100644
> --- a/hw/usb-msd.c
> +++ b/hw/usb-msd.c
> @@ -560,6 +560,7 @@ static int usb_msd_initfn(USBDevice *dev)
>          }
>      }
>  
> +    add_boot_device_path(s->conf.bootindex, &dev->qdev, "/disk@0,0");
>      return 0;
>  }
>  
> @@ -624,6 +625,7 @@ static USBDevice *usb_msd_init(const char *filename)
>  static struct USBDeviceInfo msd_info = {
>      .product_desc   = "QEMU USB MSD",
>      .qdev.name      = "usb-storage",
> +    .qdev.fw_name      = "storage",
>      .qdev.size      = sizeof(MSDState),
>      .init           = usb_msd_initfn,
>      .handle_packet  = usb_generic_handle_packet,
> -- 
> 1.7.2.3
> 

--
			Gleb.

Re: [Qemu-devel] [PATCH 2/2] Add boot index documentation.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  docs/bootindex.txt |   42 ++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 42 insertions(+), 0 deletions(-)
>  create mode 100644 docs/bootindex.txt

Good stuff.  Just a bit short on commas and articles ;)

>
> diff --git a/docs/bootindex.txt b/docs/bootindex.txt
> new file mode 100644
> index 0000000..9609c7f
> --- /dev/null
> +++ b/docs/bootindex.txt
> @@ -0,0 +1,42 @@
> += Bootindex property =
> +
> +Block and net devices have bootindex property. This property is used to
> +determine the order in which firmware will consider devices for booting
> +guest OS. If bootindex property is not set for a device it gets lowest

the guest OS.  If the bootindex property is not set for a device, it gets lowest
~~~               ~~~                                           ~

> +boot priority. There is no particular order in which devices with unset
> +bootindex property will be considered for booting, but they will still be
> +bootable.
> +
> +== Example ==
> +
> +Lets assume we have QEMU machine with two NICs (virtio, e1000) and two
> +disks (IDE, virtio):
> +
> +qemu -drive file=disk1.img,if=none,id=disk1
> +     -device ide-drive,drive=disk1,bootindex=4
> +     -drive file=disk2.img,if=none,id=disk2
> +     -device virtio-blk-pci,drive=disk2,bootindex=3
> +     -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0,bootindex=2
> +     -netdev type=user,id=net1 -device e1000,netdev=net1,bootindex=1
> +
> +Given command like above firmware should try to boot guest OS from e1000
> +NIC if this fails it should try virtio NIC next, if this fails too it
> +should try virtio disk and then IDE disk.

Given the command above, firmware should try to boot from the e1000 NIC
first.  If this fails, it should try the virtio NIC next, if this fails
too, it should try the virtio disk, and then the IDE disk.

> +
> +== Limitations ==
> +
> +1. Some firmware has limitation on order in which devices can be
> +considered for booting. For instance PC bios boot specification allows
> +only one disk to be bootable. If boot from disk fails for some reason
> +bios cannot retry booting from other disk. It still can try to boot from
> +floppy or net though.

1. Some firmware has limitations on which devices can be considered for
booting.  For instance, the PC BIOS boot specification allows only one
disk to be bootable.  If boot from disk fails for some reason, the BIOS
won't retry booting from other disk.  It still can try to boot from
floppy or net, though.

> +
> +2. Sometimes firmware cannot map device path QEMU wants firmware to boot
> +from to boot method. It doesn't happen for devices firmware can natively
> +boot from, but if firmware relies on option rom for booting, and same
> +option rom is used for booting from more then one device, firmware may
> +not be able to ask option rom to boot from particular device reliably.
> +For instance with PC bios if scsi HBA has three bootable devices target1,
> +target3, target5, connected to it option rom will create boot method for
> +each of them, but it is not possible to map boot method back to specific
> +target. This is a shortcoming of PC bios boot specification.

2. Sometimes, firmware cannot map the device path QEMU wants firmware to
boot from to a boot method.  It doesn't happen for devices the firmware
can natively boot from, but if firmware relies on an option ROM for
booting, and the same option ROM is used for booting from more then one
device, the firmware may not be able to ask the option ROM to boot from
a particular device reliably.  For instance with PC BIOS, if a SCSI HBA
has three bootable devices target1, target3, target5 connected to it,
the option ROM will have a boot method for each of them, but it is not
possible to map from boot method back to a specific target.  This is a
shortcoming of PC BIOS boot specification.

Re: [Qemu-devel] [PATCH 1/2] Add bootindex handling into usb storage device.

[Markus Armbruster]

Gleb Natapov <gleb@redhat.com> writes:

> Signed-off-by: Gleb Natapov <gleb@redhat.com>
> ---
>  hw/usb-msd.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/hw/usb-msd.c b/hw/usb-msd.c
> index 0a95d8d..46642a8 100644
> --- a/hw/usb-msd.c
> +++ b/hw/usb-msd.c
> @@ -560,6 +560,7 @@ static int usb_msd_initfn(USBDevice *dev)
>          }
>      }
>  
> +    add_boot_device_path(s->conf.bootindex, &dev->qdev, "/disk@0,0");
>      return 0;
>  }
>  
> @@ -624,6 +625,7 @@ static USBDevice *usb_msd_init(const char *filename)
>  static struct USBDeviceInfo msd_info = {
>      .product_desc   = "QEMU USB MSD",
>      .qdev.name      = "usb-storage",
> +    .qdev.fw_name      = "storage",
>      .qdev.size      = sizeof(MSDState),
>      .init           = usb_msd_initfn,
>      .handle_packet  = usb_generic_handle_packet,

Out of curiosity, could you explain the logic behind fw name (as
returned by qdev_fw_name()) and suffix (as passed to
add_boot_device_path())?

    qdev            fw name     suffix
    ----------------------------------------
    isa-fdc         fdc         /floppy@0
    scsi-disk       disk        ,0
    ide-drive       drive       /disk@0
    usb-storage     storage     /disk@0,0
    virtio-blk-pci  virtio-blk  /disk@0,0

Re: [Qemu-devel] [PATCH 1/2] Add bootindex handling into usb storage device.

[Gleb Natapov]

On Fri, Jan 28, 2011 at 02:34:19PM +0100, Markus Armbruster wrote:
> Gleb Natapov <gleb@redhat.com> writes:
> 
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > ---
> >  hw/usb-msd.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/hw/usb-msd.c b/hw/usb-msd.c
> > index 0a95d8d..46642a8 100644
> > --- a/hw/usb-msd.c
> > +++ b/hw/usb-msd.c
> > @@ -560,6 +560,7 @@ static int usb_msd_initfn(USBDevice *dev)
> >          }
> >      }
> >  
> > +    add_boot_device_path(s->conf.bootindex, &dev->qdev, "/disk@0,0");
> >      return 0;
> >  }
> >  
> > @@ -624,6 +625,7 @@ static USBDevice *usb_msd_init(const char *filename)
> >  static struct USBDeviceInfo msd_info = {
> >      .product_desc   = "QEMU USB MSD",
> >      .qdev.name      = "usb-storage",
> > +    .qdev.fw_name      = "storage",
> >      .qdev.size      = sizeof(MSDState),
> >      .init           = usb_msd_initfn,
> >      .handle_packet  = usb_generic_handle_packet,
> 
> Out of curiosity, could you explain the logic behind fw name (as
> returned by qdev_fw_name()) and suffix (as passed to
> add_boot_device_path())?
They are defined by open firmware bus binding specs. You can find most
of them here: http://playground.sun.com/1275/bindings/. FW name is not
terribly important for SeaBIOS though. SeaBIOS ignores this part of
device name when it matches device path.

> 
>     qdev            fw name     suffix
>     ----------------------------------------
>     isa-fdc         fdc         /floppy@0
>     scsi-disk       disk        ,0
>     ide-drive       drive       /disk@0
>     usb-storage     storage     /disk@0,0
>     virtio-blk-pci  virtio-blk  /disk@0,0
virtio-blk-pci will be seen as scsi since it uses scsi pci class for pci
device.

--
			Gleb.