On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
> 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 "/p...@i0cf8/r...@4.0/b...@0" 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.
>
Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
natively boot from has optionrom. What Seabios will do in such situation
and how qemu can know it? Besides qemu support tries to be firmware
agnostic.
> 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.
You run all of them just like you do now. Information you get from qemu is
only used for sorting BCV/BEV entries. BCV/BEV that does not have
corespondent boot path in boot order list is put at the end.
>
> > > > > 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.
Optionrom is static. How number of BCVs can depend on number of attached
drives?
>
> 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
--
Gleb.
