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

[Gleb Natapov]

On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote:
> 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]".
> 
That will work too.

> > > > > 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.
> 
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.

> > 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.
But bev can be only one, so we do not have this problem with bev. Boot
priority of a bev is boot priority of pci device it was loaded from.

> 
> > > > 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.
> 
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?

--
                        Gleb.