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

[Gleb Natapov]

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:
> > 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.
> 
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. The same with roms that are copied from qemu. When rom memory
is later scanned for bevs/bcvs it will be easy to find boot priority of
each one of them.

> >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.
> 
Seabios knows that this is SCSI card from its device class.
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.

> 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.)
Yes.

> 
> > > 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.
> 
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?

> 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.

> >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.
> 
Agree.

--
                        Gleb.