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

[Kevin O'Connor]

On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
> > On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> > > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > > > I am using open firmware naming scheme to specify device path names.
> > > > In this version: added SCSI bus support. Pass boot order list as file
> > > > to firmware.
> > > > 
> > > > Names look like this on pci machine:
> > [...]
> > > > /address@hidden/address@hidden,2/address@hidden/address@hidden/address@hidden
> > > > /address@hidden/linuxboot.bin
> > 
> > What's the plan for handling optionroms (ie, BCVs and BEVs)?  This is
> > an area which is a bit tricky - mainly due to legacy BIOS crud.
> > 
> > An option rom can register either a BEV (eg, gpxe on a network card),
> > or it can register one or more BCVs (eg, a scsi card registering two
> > drives).  How do we say boot from the optionrom on the second nic
> > card?  If you have a scsi card, how do we communicate that its second
> > drive should be the c: drive?
> > 
> 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.

>BCV
> should be the same, but since one PCI card may register several
> BCVs the problem is more complex. Device path has not only path to
> SCSI PCI card but to specific target,lun too. For instance this path
> /address@hidden/address@hidden,2/address@hidden,0 points to SCSI card in pci 
> slot 3 function 2
> target 1 lun 1. The question is if BCV provides us with enough information
> to know what target/lun it is going to boot.

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.

BTW, I assume you're suggesting that if a disk is found first in the
list then seabios should make that drive the c: and make hard drive
booting be the first thing attempted?  (This is what the seabios boot
menu does.)

> > The ugly thing about BCVs is that they are not necessarily registered
> > in the rom for the device that controls it.  So, if you have two of
> > the same type of scsi card, each with two drives, it's possible for
> > the optionrom to put all four drives in the rom of the first scsi
> > card.
> > 
> 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.

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.

>There can be also legacy optionrom that just hooks
> into int19 during init and hijack booting process entirely. I think
> those problems exist on real HW too.

That's a separate problem which I wouldn't worry too much about.  The
only roms that I've seen do this today are roms we have the source for
and can change.

-Kevin