From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [SeaBIOS] [PATCHv6 00/16] boot order specification Date: Sun, 28 Nov 2010 21:16:52 +0200 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 To: seabios@seabios.org, qemu-devel@nongnu.org, kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36849 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753866Ab0K1TRN (ORCPT ); Sun, 28 Nov 2010 14:17:13 -0500 Content-Disposition: inline In-Reply-To: <20101128190029.6136.qmail@stuge.se> Sender: kvm-owner@vger.kernel.org List-ID: 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.