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

[Kevin O'Connor]

On Thu, Dec 02, 2010 at 02:30:42PM +0200, Gleb Natapov wrote:
> On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
> > 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.

As before, a safe heuristic would be to request a rom boot for any
device with a pci rom that the user requests to boot from.

Note, your original proposal included a boot method:
/address@hidden/linuxboot.bin
I'm asking to extend this to be able to include roms on PCI devices.

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

Exactly - look at the F12 menu.  (Or, for bonus points, one could
write a program that scans roms on the booted coreboot system,
presents the user with a menu, and then writes the requested boot
method to "bootorder".)

Being able to specify which boot method is a requirement for me.  It
doesn't have to be pretty, but it does have to be possible.

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

Raise int 0x13 ah=0x48 - once the drive is mapped it will hook that
the 0x13 irq and handle the request (or jump to the bios handler for
drives it doesn't know about).

>Can we use "disconnect vector"
> to connect device temporarily get EDD and then disconnect?

No.

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

You've used this word "impossible" a few times - I'm afraid I don't
know what it means.

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

Bleh - there's no need for that.  Much more reliable is to record the
device path for builtin devices or the boot method (device path of
rom, plus bev/bcv instance) for rom based boots.

-Kevin