From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44267 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNeRc-0006m4-Bb for qemu-devel@nongnu.org; Tue, 30 Nov 2010 23:37:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNRgI-0003AG-7L for qemu-devel@nongnu.org; Tue, 30 Nov 2010 09:59:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNRgH-00039s-VP for qemu-devel@nongnu.org; Tue, 30 Nov 2010 09:59:46 -0500 Date: Tue, 30 Nov 2010 16:59:36 +0200 From: Gleb Natapov Message-ID: <20101130145936.GI2187@redhat.com> References: <20101127170619.GB14385@redhat.com> <20101127174726.GA15238@morn.localdomain> <20101127181541.GC14385@redhat.com> <20101127184012.GA17455@morn.localdomain> <20101127190424.GD14385@redhat.com> <20101127210744.GA21727@morn.localdomain> <20101128074534.GE6897@redhat.com> <20101128171543.GA21987@morn.localdomain> <4CF38585.7030502@redhat.com> <20101130015509.GC3488@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101130015509.GC3488@morn.localdomain> Subject: [Qemu-devel] Re: [PATCHv6 00/16] boot order specification List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: seabios@seabios.org, Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org 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.