[SeaBIOS] [PATCHv6 00/16] boot order specification

[Kevin O'Connor]

On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> > > natively boot from has optionrom. What Seabios will do in such situation
> > > and how qemu can know it? Besides qemu support tries to be firmware
> > > agnostic.
> > 
> > In such a situation, under my proposal, users wouldn't be able to
> > specify a default boot from their scsi drive until after qemu was also
> > upgraded to know seabios could boot native scsi.  (Or, they'd only be
> > able to do it by adding in a command-line option.)
> > 
> If scsi card has optionrom with only one bcv then Seabios can determine
> its boot order from device path, so why not provide user with this
> option today?

It's unclear to me how SeaBIOS is supposed to do that.

>Besides qemu may be used to emulates sparc with openbios and
> this combination may be able to boot from scsi device. Qemu is not just
> x86 emulator running Seabios. If there is problem with scsi boot we let
> management know, so it will not create unbootable configuration. Today it
> is impossible to boot guest from scsi in qemu btw.

Qemu can send in "/pci at i0cf8/scsi at 3/disk at 0,0" - it's just unclear what
seabios is supposed to do with it.  (If "ignore it" is the answer,
that's fine with me.)

> > If qemu sends in "/pci at i0cf8/scsi at 3/disk at 0,0" or
> > "/pci at i0cf8/ethernet at 4/ethernet-phy at 0" it will expect seabios to boot
> > from the appropriate device.  In both cases, seabios would need to run
> > a rom in order to fulfill that request.  Trying to figure out which
> > rom is quite painful.  That's why I'd prefer to see qemu instead pass
> > in something like "/pci at i0cf8/rom at 3/bcv at 0" or "/pci at i0cf8/rom at 4/bev".
> > That is, if the machine needs to boot via a rom I'd prefer qemu state
> > that explicitly.
> It is painful in Seabios it is impossible in qemu at all. There is no
> way for qemu to know about BCVs or BEVs in optionroms especially
> considering that they are created at runtime like you say bellow.

It's not impossible - qemu could code up rules for when to request a
rom boot and when to request a native boot.  That may seem ugly, but
(as near as I can tell) it's basically what you've asked seabios to
do.  If nothing else, qemu has the option to let the user pass in an
explicit request via the command-line.

> > BTW, in the situation where seabios has native device support (eg,
> > ATA), I don't have any concerns.  (The names are a bit verbose, but
> > that's not really an issue.)
> This + network booting are the may use case really. And I do not see
> what problem we have with BEV devices. "/pci at i0cf8/rom at 4/bev" is not
> much different from "/pci at i0cf8/ethernet at 4/ethernet-phy at 0" since there
> can be only one bev per pci device. It is easy for Seabios to see that
> to boot from pci device in slot 4 func 0 it has to execute BEV. 

I'm still stuck on how seabios is supposed to know it's an ethernet
card.  Sure, seabios could hardcode translations from classid to
strings, but that seems fragile.  What happens when the user wants to
boot from myranet, or fiberchannel, or whatnot?

Maybe we can compromise here - if the user selects booting from a
device, and qemu sees there is a rom for that device, then qemu can
specify two boot options:

/pci at i0cf8/ethernet at 4/ethernet-phy at 0
/pci at i0cf8/rom at 4

SeaBIOS will ignore the first entry, and act on the second entry.  If
at some later point seabios knows how to natively boot from the device
(eg, scsi), then it will use the first entry and ignore the second.

BTW, how are PCI locations specified in these paths?  They should have
a (bus, dev, fn) - your examples only seem to show dev.  How are the
other parts specified?

-Kevin