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

[Kevin O'Connor]

On Sat, Nov 27, 2010 at 07:06:19PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> > > Yeah. I looked at the Seabios code. The simplest would be to change
> > > device path to point to rom instead of pci device.  So if there is device
> > > path /address@hidden/address@hidden when rom is copied into the memory 
> > > the path
> > > is changed to be /address@hidden where addr is memory address where rom 
> > > was
> > > copied.
> > Seabios would change its local copy of the path?
> Yes.

Thinking about this further - since the optionrom must be 2k aligned
there are only 96 spots a rom can be in.  So, it should be simple to
just have optionrom_setup() declare a "u16 romaddr_to_bdf[96]".

> > > > How will seabios even know it's a SCSI card?  All seabios sees is a
> > > > PCI device with a valid option rom bar.  Further, I don't see how
> > > > seabios will know which BCV is which lun.
> > > > 
> > > Seabios knows that this is SCSI card from its device class.
> > 
> > This seems fragile - it would require seabios to keep a list of device
> > classes to name mappings, and a user may not be able to boot from a
> > device if seabios isn't programmed for it (eg, a passthrough device).
> > 
> Seabios can ignore device name from device path since the same
> information is present in pci config space of the device. So the device path
> can be /address@hidden/address@hidden or /address@hidden/@4 Seabios can 
> detect that device
> is scsi just by looking at config space of pci device in slot 4 function 0.

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.

> For, scsi I think, proper solution would be to have Seabios support for
> scsi controller emulated by qemu. This will make all devices bootable from
> BCV known to Seabios and will not require option rom. The only problem
> then will be with pass through devices, but since now only the whole
> scsi controller can be passed through not individual targets qemu can
> point device path only to the controller and not individual targets too.

I'm okay with adding scsi support to seabios.  However, the problem
doesn't go away as network booting still requires a rom.

> > > Unfortunately it looks like bcv does not provide enough info to know what
> > > target it corresponds too. I can't think of enything smart we can do
> > > here, so lets just treat all bcvs as same priority.
> > 
> > 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.

-Kevin