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

[Gleb Natapov]

On Thu, Dec 02, 2010 at 09:01:25PM -0500, Kevin O'Connor wrote:
> 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.
> 
I already posted here code that maps PCI rom to PCI device path. Why do
you still insist on artificial path like /pci/address@hidden

> > > 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".)
> 
If you propose that then you probably misunderstand the problem I am
trying to tackle. Qemu should be able to specify boot order for newly
created machine with arbitrary HW configuration without making user
to look at F12 menu. Actually at this point there is not human user
at all. All the process from machine creation till OS installation is
completely unattended. Looking at the BBS spec in several places they
say that if NV ram is corrupted bios should use some predefined default
boot order. This "predefined default boot order" is what qemu tries to
pass to Seabios to use correct boot device without user's input.

To make it clear "unattended" part is absolute requirement.

> 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.
For you problem solution is very easy and described in BBS spec. You
just need two numbers IPL to boot from and which BCV is first. No need
for device paths at all. In fact Seabios already tracks IPL order this
way the only thing missing is to track BCV order.

> 
> > > >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.
> 
And is it possible to call BCV and then restore int13 vector?
So to find out what device each BCV belongs too we do:
  foreach(bcv)
    call_bcv(bcv)
    int 1348
    restor(int13) 

After that we call  call_bcv(bcv) but in correct order.

> > > 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.
It means that I do not have a solution and you do not propose one either :)
It seems we were trying to solve differed problems though. I hope now it is
much more clear what I am trying to achieve with proposed bootorder
patches.

> 
> >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.
> 
Why is this much more reliable? Suppose user has scsi card with 3 devices
id3 id5 id6. Three BCVs was created for them and user chose to boot
from BCV3(id6). He added /pci/address@hidden/address@hidden to his coreboot's 
bootorder
file. Now he adds one more device to this scsi bus with id1. On the next
boot 4 BCVs will be created and now id6 is bootable by BCV4 instead
BCV3. The result is unbootable system.

--
                        Gleb.