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

[Kevin O'Connor]

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.

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

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

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

-Kevin