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

[Gleb Natapov <gleb@redhat.com>]

On Mon, Nov 29, 2010 at 08:55:09PM -0500, Kevin O'Connor wrote:
> On Mon, Nov 29, 2010 at 11:50:45AM +0100, Gerd Hoffmann wrote:
> > >>If scsi card has optionrom with only one bcv then Seabios can determine
> > >>its boot order from device path, so why not provide user with this
> > >>option today?
> > >It's unclear to me how SeaBIOS is supposed to do that.
> > Try to keep track of which bcv/bev belongs to which pci device?  It
> > should surely work for devices supported by seabios natively.
> 
> No issues for any device with native support.  I'm okay with the
> proposed syntax.
> 
> > SeaBIOS should also know which device's rom registered which entry.
> 
> It doesn't today, but that shouldn't be an issue to add.
> 
> > It might become tricky though in case there are multiple identical
> > devices are present, say two e1000 cards, where the first rom could
> > register entries for both cards ...
> 
> Right - here's where things get complicated.
> 
I don't see how it can be solved at all given that bev->productname
doesn't have any structure so it can't be parsed back to device's pci
address.

> > >Maybe we can compromise here - if the user selects booting from a
> > >device, and qemu sees there is a rom for that device, then qemu can
> > >specify two boot options:
> > >
> > >/pci@i0cf8/ethernet@4/ethernet-phy@0
> > >/pci@i0cf8/rom@4
> > >
> > >SeaBIOS will ignore the first entry, and act on the second entry.
> > 
> > SeaBIOS should be able to operate just fine with the first entry.
> > "ethernet@4" means "the nic at bus address 4".  As this is a PCI bus
> > "4" is the pci address.  So SeaBIOS would just look what entries it
> > has for "00:04.0", run the rom, and ignore the "/ethernet-phy@0"
> > part as it can't handle it.
> 
> Right - I'm not happy about trying to parse out openbios device
> descriptors though.  The natural flow (as I see it) is for seabios to
> find all the boot methods in the system and then see which ones have
> been requested to be prioritized.  Trying to do fuzzy matching of
> found device to requested device just seems like an unnecessary pain
> IMO.
> 
> >When booting via rom it can either just pick
> > the first entry unconditionally (probably good enougth in 99% of the
> > cases) or do some guesswork based on the order the entries are
> > registered.
> 
> I guess that's the crux of the matter - I'd rather not do guessing in
> the firmware.  The emulator is in a much better position to do
> heuristics and guessing - if nothing else, the emulator can allow the
> user to pass it in on the command-line.
> 
Actually Seabios is in a much better position to do this heuristics
since only at runtime all IPLs are knows. What heuristics you think
emulator can implement?

> > >BTW, how are PCI locations specified in these paths?  They should have
> > >a (bus, dev, fn) - your examples only seem to show dev.  How are the
> > >other parts specified?
> > 
> > fn is optional for fn=0, IIRC the syntax is "$class@$dev,$fn".
> > 
> > Bus is specified via location in the tree, i.e. you'll see the
> > bridge for the secondary pci bus in the path, like this:
> > 
> > /pci@i0cf8/bridge@7/ethernet@3/...
> > 
> > (not sure it is actually named 'bridge' in the openfirmware specs though).
> 
> Thanks.
> 
> -Kevin

--
			Gleb.