qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin O'Connor
Subject: [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
Date: Sat, 27 Nov 2010 13:40:12 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote:
> > I don't think seabios should try to parse the path.  Instead, I think
> > seabios should build a name for each device it finds using the same
> > algorithm that qemu uses and then just do a string compare to see if
> > there is a match.
> > 
> > Also, if qemu wants seabios to boot from a rom, I think it should tell
> > seabios that - something like 
> > "/address@hidden/address@hidden/address@hidden" to mean make
> > the drive declared by the rom on pci device 4 function 0 in the first
> > found bcv the c: drive.
> > 
> Qemu does not know that Seabios needs optionrom to boot from a device.
> It knows even less about bcvs in option rom. Qemu knows about device
> itself, not how firmware boots from it.

If the user wants to boot from a device and that device has an
optionrom, then it's a safe bet that the optionrom is needed to boot
from it.

In any case, I'd rather have qemu know which devices seabios can boot
then have seabios try to figure out what rom to run from a device
path.

> > > > There's the product name and there's the order it was registered in
> > > > (ie, the third bcv on the rom).
> > > Doesn't help much if we can't correlate bcv to device path.
> > 
> > I'm confused by this.  SeaBIOS can't boot the device in this situation
> > - it can only run a rom.  I think qemu should try to send info on
> > which rom to run, not which device to boot.  Each rom is uniquely
> > identifiable by the pci device it came from (or fw_cfg slot), and each
> > BCV can be identified by either its instance or its product name.
> > 
> For Qemu those optionroms are just binary blobs. It doesn't know why they
> are needed at all (there is no difference for qemu between vga rom and
> e1000 rom). 
> 
> BTW are you actually aware of any option rom with multiple BCVs and, if
> yes, how those BCVs differ?

Multiple BCVs - yes.  A SCSI card will define a BCV for each attached
drive.  I don't have a scsi card myself, but the support was added by
a user who ran into the problem first hand.

I don't know if there are SCSI card roms that will register all the
drives on multiple cards in the first rom.  I wouldn't be surprised if
there are because of the scarcity of space in the 0xc0000-0xf0000
space.  (Having secondary optionroms resize themselves to zero would
be a big savings.)

-Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]