From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57231 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMmUF-0007ti-Rk for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:00:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PMmUE-0002Pk-8Z for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:00:35 -0500 Received: from foo.birdnet.se ([213.88.146.6]:49360 helo=foo.stuge.se) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PMmUD-0002PI-Rm for qemu-devel@nongnu.org; Sun, 28 Nov 2010 14:00:34 -0500 Message-ID: <20101128190029.6136.qmail@stuge.se> Date: Sun, 28 Nov 2010 20:00:29 +0100 From: Peter Stuge References: <20101127154110.GA11197@morn.localdomain> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101128074534.GE6897@redhat.com> 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 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. 2. QEMU passes boot instructions to the firmware based on immediate, common, structured data. 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. //Peter