Re: [PATCHv6 00/16] boot order specification

Kevin O'Connor
2010-11-27T21:07:48Z

Trimming CC list, adding seabios list.

On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> > > Qemu does not know that Seabios needs optionrom to boot from a device.
> > > It knows even less about bcvs in option rom. Qemu knows about device
> > > itself, not how firmware boots from it.
> >
> > If the user wants to boot from a device and that device has an
> > optionrom, then it's a safe bet that the optionrom is needed to boot
> > from it.
> >
> 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.)

> > In any case, I'd rather have qemu know which devices seabios can boot
> > then have seabios try to figure out what rom to run from a device
> > path.
> You run all of them just like you do now. Information you get from qemu is
> only used for sorting BCV/BEV entries. BCV/BEV that does not have
> corespondent boot path in boot order list is put at the end.

If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
"/pci@i0cf8/ethernet@4/ethernet-phy@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@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
That is, if the machine needs to boot via a rom I'd prefer qemu state
that explicitly.

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

> > > BTW are you actually aware of any option rom with multiple BCVs and, if
> > > yes, how those BCVs differ?
> >
> > Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> > drive. I don't have a scsi card myself, but the support was added by
> > a user who ran into the problem first hand.
> Optionrom is static. How number of BCVs can depend on number of attached
> drives?

Not sure what you mean by "Optionrom is static". SeaBIOS unlocks the
memory, and the optionrom can and will modify itself with additional
PNP headers so that it can list multiple BCVs - one for each drive.
In particular, gPXE uses self modification to relocate parts of itself
into high ram.

-Kevin