From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36446 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5PK3-0006Aa-50 for qemu-devel@nongnu.org; Mon, 11 Oct 2010 16:50:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5PK0-00032t-PW for qemu-devel@nongnu.org; Mon, 11 Oct 2010 16:50:14 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:36332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5PK0-00032W-Lp for qemu-devel@nongnu.org; Mon, 11 Oct 2010 16:50:12 -0400 Received: by iwn34 with SMTP id 34so2602910iwn.4 for ; Mon, 11 Oct 2010 13:50:11 -0700 (PDT) Message-ID: <4CB37880.5090400@codemonkey.ws> Date: Mon, 11 Oct 2010 15:50:08 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios References: <20101011101855.GA25030@redhat.com> <4CB2E7D0.1010702@redhat.com> <4CB2FDF2.1020705@redhat.com> <20101011121634.GB28008@redhat.com> <4CB36A20.5020106@codemonkey.ws> <20101011195955.GA5218@redhat.com> <4CB373DD.50307@codemonkey.ws> <20101011203653.GC5218@redhat.com> In-Reply-To: <20101011203653.GC5218@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Kevin Wolf , seabios@seabios.org, Gerd Hoffmann , qemu-devel@nongnu.org On 10/11/2010 03:36 PM, Gleb Natapov wrote: > On Mon, Oct 11, 2010 at 03:30:21PM -0500, Anthony Liguori wrote: > >> On 10/11/2010 02:59 PM, Gleb Natapov wrote: >> >>> No boot rom should do that. extboot wreaks havoc when it is used. >>> And since virtio is now supported by bios there is no reason to use it. >>> >> You don't really have a choice. You could be doing hardware >> passthrough and the ROM on the card may hijack int19. >> >> > Then this particular HW would be broken on real HW too and will not > respect BIOS settings. But the code we provide should work properly. > > >>> Whoever needs scsi boot should add it to seabios too. >>> >> I don't disagree. >> >> I think the best thing to do is to let SeaBIOS create a boot order >> table that contains descriptive information and then advertise that >> to QEMU. >> >> > What for? Why this step is needed? > > >> QEMU can then try to associate the list of bootable devices with >> it's own set of devices and select a preferred order that it can >> then give back to SeaBIOS. SeaBIOS can then present that list to >> the user for additional refinement. >> >> > Why not skip your first step and let QEMU create boot order list and > pass it into Seabios. If menu=on option is present user will be able to > override the default from Seabios. > Because SeaBIOS is definitive and QEMU is not. We can ask SeaBIOS to boot from SCSI LUN 3 on PCI address X.Y.Z but that doesn't mean that it can figure out what that means. If it can't, how do we communicate that to the user? If SeaBIOS communicates its list to QEMU then we can at least display that list in the monitor in the same way that it's displayed to the guest. That means that we can reorder in the monitor and potentially can persistent the boot device list in a more meaningful way. Regards, Anthony Liguori > -- > Gleb. >