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

[Gleb Natapov]

On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
> On Wed, Dec 01, 2010 at 02:27:40PM +0200, Gleb Natapov wrote:
> > On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote:
> > > BTW, what's the plan for handling SCSI adapters?  Lets say a user has
> > > a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
> > > bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
> > > lun3.  I understand this use case may not be important for qemu, but
> > > I'd like to use the same code on coreboot.  Being able to boot from
> > > any drive is important - it doesn't have to autodetect, but it should
> > > be possible.
> > > 
> > We can't. Option rom does not give us back enough information to do so.
> > Form device path we know exactly what id:lun boot should be done from,
> > but pnp_data does not have information to map BCV back to id:lun. I do
> > not see how coreboot can provide better information to Seabios then
> > qemu here.
> 
> You're thinking in terms of which device to boot, which does make this
> difficult.  However, it's equally valid to think in terms of which
> boot method to invoke, which makes this easy.
It is not. Because boot methods are enumerated by a guest at runtime.
Qemu knows absolutely nothing about them. I am thinking in terms of
devices because this is the only thing I have in qemu. BBS specification
is broken since it doesn't provide a way for discovered boot method
(BCV) to be linked back to a device it will boot from. Nothing we can do
to fix this except moving to EFI (an hope the problem is fixed there).

> 
> We could tell the coreboot user to edit the "bootorder" file and add
> "/address@hidden/address@hidden" (second rom on 4th pci device - the exact 
> syntax
> of the name is not important).
> 
But how user should knows that second rom (I think you mean "second BCV")
on pci device 4.0 will boot from the new scsi cdrom that he just connected?
How can he tell that it should put second BCV there and not third or fifth
without running Seabios first and looking at F12 menu? Depending on
option rom implementation even F12 menu can have not enough information
for user to guess which boot entry he should use to boot from the device
because product name that is used to distinguish between different boot
entires should be unique, but not necessary provide useful information
about device according to spec. (Both gpxe and lsi 8xx_64.rom provide device
address as part of product name; gpxe puts pci address there and 8xx_64.rom
puts ID LUN). Another important point is that BCV number can change when new
device is added to scsi bus, so next boot will mysteriously fail. Important
property of device path that it is stable and does not depend on HW 
configuration.

> >BTW to create proper EDD entry for SCSI boot device BIOS also
> > needs too map BCV to id:lun. How it can be done? 
> 
> It's the responsibility of the rom to build the EDD info.  I don't
> know if all roms do this - I don't believe it's possible to get at the
> EDD info until after the drive has been mapped (ie, too late to use it
> for boot ordering).
How can we get to EDD info after device is mapped? Looking at Seabios
implementation it builds EDD table on the fly when int_1348 is called
and it does it only for internal devices. Can we use "disconnect vector"
to connect device temporarily get EDD and then disconnect?

> 
> > SCSI _is_ important for qemu. Not HBA  we have now, but something supported
> > by recent operation systems out of the box. When such HBA will be emulated
> > in qemu we will add native Seabios support for it.
> 
> I understand.  However, we'll still need to support arbitrary rom
> based BEVs and BCVs, so the use case is still important.
> 
We can't do something that is impossible. For coreboot Seabios should
implement what BBS spec says i.e enumerate all BCVs, present boot menu
to the user, record number of BCVs and user's choice on non-volatile
storage (CMOS). On next boot use recorded user's choice unless number of
BCVs changes, otherwise present boot menu again. This is of course
broken too since number of BCVs may not change even if HW configuration
changes substantially. Spec says that in that case user probably
will want to adjust boot order anyway and will enter boot menu by
itself. Sorry excuse for failing to provide proper functionality if you
ask me :)

--
                        Gleb.