From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52361 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMmk4-0006LK-9T for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:16:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PMmk3-00055F-63 for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:16:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:6154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PMmk2-000553-To for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:16:55 -0500 Date: Sun, 28 Nov 2010 21:16:52 +0200 From: Gleb Natapov Message-ID: <20101128191652.GG14385@redhat.com> References: <20101127162216.GA14385@redhat.com> <20101127164939.GA13605@morn.localdomain> <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> <20101128190029.6136.qmail@stuge.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101128190029.6136.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: seabios@seabios.org, qemu-devel@nongnu.org, kvm@vger.kernel.org On Sun, Nov 28, 2010 at 08:00:29PM +0100, Peter Stuge wrote: > Gleb Natapov wrote: > > There is no way for qemu to know about BCVs or BEVs > > This is very much the key point. > > In order to have command line control over the boot process, the > machine and the firmware must agree on things. > > I see two options: > > 1. QEMU works very very hard to provide a machine that will result in > a particular BBS program flow in firmware, in the end resulting in > the desired device being used for booting - as long as QEMU and the > firmware happen to have the same understanding of the BBS. > Since qemu knows nothing about BCVs and BEVs it can't implement 1 since it can't know what BBS flow will look like in Seabios. > 2. QEMU passes boot instructions to the firmware based on immediate, > common, structured data. What is this "immediate, common, structured data"? This is the crux of the problem really. > > The first option seems disgusting to me, because it has many > drawbacks and no benefits. > > The second option requires inventing something that goes beyond the > established BIOS standards, maybe a reason for it to see fierce > resistance, but it is the only thing that makes sense. > > Specifying boot device using PCI BDF is a great example of using > common structured data. That BDF exists both in machine and firmware > data models. The scope of BBS is limited to the firmware, so it is > not really practical for creating consistency in a dynamic machine. > B from BDF does not exists in machine data model. -- Gleb.