[Qemu-devel] Re: [PATCHv6 00/16] boot order specification

[Kevin O'Connor]

On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 10:41:10AM -0500, Kevin O'Connor wrote:
> > On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> > > BEV should be easy. When you register BEV found on pci card you search
> > > for device path to that pci card to determine BEV's boot order.
> > 
> > SeaBIOS has two separate optionrom passes - one to extract the roms
> > from the cards and one to find BEVs and BCVs.  In order to correlate a
> > rom to a pci device SeaBIOS would have to keep track of each rom it
> > deploys and then correlate it during the BEV/BCV scan.
> > 
> Yeah. I looked at the Seabios code. The simplest would be to change
> device path to point to rom instead of pci device.  So if there is device
> path /address@hidden/address@hidden when rom is copied into the memory the 
> path
> is changed to be /address@hidden where addr is memory address where rom was
> copied.

Seabios would change its local copy of the path?

[...]
> > How will seabios even know it's a SCSI card?  All seabios sees is a
> > PCI device with a valid option rom bar.  Further, I don't see how
> > seabios will know which BCV is which lun.
> > 
> Seabios knows that this is SCSI card from its device class.

I assume "ethernet" would be from device class as well?

This seems fragile - it would require seabios to keep a list of device
classes to name mappings, and a user may not be able to boot from a
device if seabios isn't programmed for it (eg, a passthrough device).

> Unfortunately it looks like bcv does not provide enough info to know what
> target it corresponds too. I can't think of enything smart we can do
> here, so lets just treat all bcvs as same priority.

There's the product name and there's the order it was registered in
(ie, the third bcv on the rom).

[...]
> > > That just broken optionrom. I can't see how we can solve this without
> > > communicating with such optionrom and letting it know what device we
> > > want to boot from.
> > 
> > I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
> > states that optionroms can do this.  I don't know how many roms
> > actually do it.
> > 
> BSS tries to documents things post factum. I hope it doesn't encourage
> this type of option roms. But how it works if we have two scsi cards
> both have same option rom and each one of them tries to register bcv for
> all scsi card it found. Won't we have two bcvs registered for each scsi
> car then?

First optionrom finds all devices for that type of scsi card.  Second
optionrom detects that its drives have already been probed and resizes
itself to zero.

> > The BCV and BEVs have a "product name string" that could be used to
> > identify which one to boot.  Unfortunately, there isn't a good way for
> > qemu to find these strings (though maybe it could just hard code them
> > for roms it ships with).  SeaBIOS does show them in the boot menu, so
> > a user could manually copy them to a command line.
> > 
> Two disks can have same product name no? And qemu can't even know
> product names for pass through devices. Also I wouldn't worry about
> optioroms qemu ships. We can fix those.

The product name is supposed to be unique.  From the spec:

  The data within each header must be valid. Especially the `BCV' and
  `Pointer to Product Name String' fields. The BCV should point to a
  procedure that installs only that device into INT 13h services. It
  is strongly recommended that the Product Name String for each header
  uniquely identify the device to which that header belongs, so that
  when these strings are displayed to the user in a menu, the user can
  intelligently recognize and choose devices connected to that
  controller without having to open up the computer.

-Kevin