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

[Gleb Natapov]

On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote:
> 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?
> 
Yes.

> [...]
> > > 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?
> 
Yes.

> 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).
> 
Seabios can ignore device name from device path since the same
information is present in pci config space of the device. So the device path
can be /address@hidden/address@hidden or /address@hidden/@4 Seabios can detect 
that device
is scsi just by looking at config space of pci device in slot 4 function 0.

For, scsi I think, proper solution would be to have Seabios support for
scsi controller emulated by qemu. This will make all devices bootable from
BCV known to Seabios and will not require option rom. The only problem
then will be with pass through devices, but since now only the whole
scsi controller can be passed through not individual targets qemu can
point device path only to the controller and not individual targets too.

> > 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).
Doesn't help much if we can't correlate bcv to device path.

> 
> [...]
> > > > 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.
> 
The spec is "strongly recommended", not requires, but I guess if product
violates this recommendation it will have the same problem on real HW
too.

--
                        Gleb.