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

[Gleb Natapov]

On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
> Hi Gleb,
> 
> On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> > Anthony, Blue
> > 
> > No comments on this patch series for almost a week. Can it be applied?
> 
> My apologies - I haven't had time to review.
> 
> > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > > I am using open firmware naming scheme to specify device path names.
> > > In this version: added SCSI bus support. Pass boot order list as file
> > > to firmware.
> > > 
> > > Names look like this on pci machine:
> [...]
> > > /address@hidden/address@hidden,2/address@hidden/address@hidden/address@hidden
> > > /address@hidden/linuxboot.bin
> 
> What's the plan for handling optionroms (ie, BCVs and BEVs)?  This is
> an area which is a bit tricky - mainly due to legacy BIOS crud.
> 
> An option rom can register either a BEV (eg, gpxe on a network card),
> or it can register one or more BCVs (eg, a scsi card registering two
> drives).  How do we say boot from the optionrom on the second nic
> card?  If you have a scsi card, how do we communicate that its second
> drive should be the c: drive?
> 
BEV should be easy. When you register BEV found on pci card you search
for device path to that pci card to determine BEV's boot order. BCV
should be the same, but since one PCI card may register several
BCVs the problem is more complex. Device path has not only path to
SCSI PCI card but to specific target,lun too. For instance this path
/address@hidden/address@hidden,2/address@hidden,0 points to SCSI card in pci 
slot 3 function 2
target 1 lun 1. The question is if BCV provides us with enough information
to know what target/lun it is going to boot. Another problem is with
device passthroug where if we pass entire SCSI PCI card to a guest we
cannot specify particular target to boot from. This can be solved by
allowing adding boot device paths from command line.

For SCSI the optimal solution would be to have SCSI support for device
QEMU emulates built in in Seabios itself. It is just that current device
QEMU emulates is so old and so buggy that it is not worth to support it.
 
> The ugly thing about BCVs is that they are not necessarily registered
> in the rom for the device that controls it.  So, if you have two of
> the same type of scsi card, each with two drives, it's possible for
> the optionrom to put all four drives in the rom of the first scsi
> card.
> 
That just broken optionrom. I can't see how we can solve this without
communicating with such optionrom and letting it know what device we
want to boot from. There can be also legacy optionrom that just hooks
into int19 during init and hijack booting process entirely. I think
those problems exist on real HW too.

--
                        Gleb.