On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
> 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.)
>
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? 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.
> > > 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 "/p...@i0cf8/s...@3/d...@0,0" or
> "/p...@i0cf8/ether...@4/ethernet-...@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 "/p...@i0cf8/r...@3/b...@0" or "/p...@i0cf8/r...@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.
The best qemu can do is to ask user what device user wants to boot from
and pass this information to Seabios in form of device path. Seabios (or
other firmware) has to figure out how to boot from the device or ignore
request if it can't. We can't provide the same functionality as Seabios'
f12 menu on qemu command line since content of the menu depend on run time.
>
> 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. "/p...@i0cf8/r...@4/bev" is not
much different from "/p...@i0cf8/ether...@4/ethernet-...@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.
>
> > > > 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.
>
"Optionrom is static" was my misunderstanding. As you say here optionrom
can create BEVs/BCVs at runtime which make it impossible for qemu to
know about them even if qemu examine optionroms of devices.
--
Gleb.
