From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [SeaBIOS] [PATCHv6 00/16] boot order specification Date: Thu, 2 Dec 2010 19:13:17 +0200 Message-ID: <20101202171317.GE2924@redhat.com> References: <20101128074534.GE6897@redhat.com> <20101128171543.GA21987@morn.localdomain> <20101128184734.GE14385@redhat.com> <20101130013402.GB3488@morn.localdomain> <20101130140100.GH2187@redhat.com> <20101201025332.GA6877@morn.localdomain> <20101201122740.GL2187@redhat.com> <20101202022540.GA23364@morn.localdomain> <20101202123042.GD2924@redhat.com> <20101202150716.11062.qmail@stuge.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: "Kevin O'Connor" , seabios@seabios.org, qemu-devel@nongnu.org, kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48500 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753792Ab0LBRNo (ORCPT ); Thu, 2 Dec 2010 12:13:44 -0500 Content-Disposition: inline In-Reply-To: <20101202150716.11062.qmail@stuge.se> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Dec 02, 2010 at 04:07:16PM +0100, Peter Stuge wrote: > Gleb Natapov wrote: > > BBS specification is broken since it doesn't provide a way for > > discovered boot method (BCV) to be linked back to a device it will > > boot from. Nothing we can do to fix this except moving to EFI (an > > hope the problem is fixed there). > > There is that option, or there could be some simple improvement of > our own, which works in QEMU and maybe even adds value to coreboot. > But then there would be a bit of novel development in firmware - that > can't be a good thing, right? > I am all for novel development in firmware, but unfortunately I do not see what can we do in Seabios + qemu to fix this shortcoming. The problem should be fixed in each and every option rom. Option rom may set device address somewhere in pnp header for instance. > > > Spec says that in that case user probably will want to adjust boot > > order anyway and will enter boot menu by itself. Sorry excuse for > > failing to provide proper functionality if you ask me :) > > I agree. I can not believe the absolute resistance to innovation in > this field. > Interested parties want everyone to move to EFI I guess. > Isn't the scope of BBS logic limited to boot time? (There are calls > to do settings, but that's no problem.) > > Maybe it would be possible for SeaBIOS to provide what looks like BBS > to the guest, but on the other side there is something more > intelligent going on, be it together with QEMU or coreboot? > > I don't how it can be done without cooperation with option roms. -- Gleb. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51235 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POCis-0002h0-OP for qemu-devel@nongnu.org; Thu, 02 Dec 2010 12:13:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1POCig-0004nB-PV for qemu-devel@nongnu.org; Thu, 02 Dec 2010 12:13:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1POCig-0004my-Ir for qemu-devel@nongnu.org; Thu, 02 Dec 2010 12:13:22 -0500 Date: Thu, 2 Dec 2010 19:13:17 +0200 From: Gleb Natapov Message-ID: <20101202171317.GE2924@redhat.com> References: <20101128074534.GE6897@redhat.com> <20101128171543.GA21987@morn.localdomain> <20101128184734.GE14385@redhat.com> <20101130013402.GB3488@morn.localdomain> <20101130140100.GH2187@redhat.com> <20101201025332.GA6877@morn.localdomain> <20101201122740.GL2187@redhat.com> <20101202022540.GA23364@morn.localdomain> <20101202123042.GD2924@redhat.com> <20101202150716.11062.qmail@stuge.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202150716.11062.qmail@stuge.se> Subject: [Qemu-devel] Re: [SeaBIOS] [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 , seabios@seabios.org, qemu-devel@nongnu.org, kvm@vger.kernel.org On Thu, Dec 02, 2010 at 04:07:16PM +0100, Peter Stuge wrote: > Gleb Natapov wrote: > > BBS specification is broken since it doesn't provide a way for > > discovered boot method (BCV) to be linked back to a device it will > > boot from. Nothing we can do to fix this except moving to EFI (an > > hope the problem is fixed there). > > There is that option, or there could be some simple improvement of > our own, which works in QEMU and maybe even adds value to coreboot. > But then there would be a bit of novel development in firmware - that > can't be a good thing, right? > I am all for novel development in firmware, but unfortunately I do not see what can we do in Seabios + qemu to fix this shortcoming. The problem should be fixed in each and every option rom. Option rom may set device address somewhere in pnp header for instance. > > > Spec says that in that case user probably will want to adjust boot > > order anyway and will enter boot menu by itself. Sorry excuse for > > failing to provide proper functionality if you ask me :) > > I agree. I can not believe the absolute resistance to innovation in > this field. > Interested parties want everyone to move to EFI I guess. > Isn't the scope of BBS logic limited to boot time? (There are calls > to do settings, but that's no problem.) > > Maybe it would be possible for SeaBIOS to provide what looks like BBS > to the guest, but on the other side there is something more > intelligent going on, be it together with QEMU or coreboot? > > I don't how it can be done without cooperation with option roms. -- Gleb.