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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
