From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MunXL-0003cc-Vr for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:23:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MunXH-0003bn-5o for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:23:35 -0400 Received: from [199.232.76.173] (port=52137 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MunXG-0003bi-Kd for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:23:30 -0400 Received: from mail.gmx.net ([213.165.64.20]:35270) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MunXF-0003ui-RP for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:23:30 -0400 Message-ID: <4AC9F34F.80105@gmx.net> Date: Mon, 05 Oct 2009 15:23:27 +0200 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0 References: <4AC51DBA.7020609@codemonkey.ws> <4AC60037.6000001@codemonkey.ws> <2a50f7880910020958g3fe5eadehe5e5094c05b218d9@mail.gmail.com> <4AC64A5C.6010003@gmx.net> <4AC64C32.4020509@codemonkey.ws> <4AC67326.6080603@gmx.net> <2a50f7880910021528v742c39e8sd334b318c577fb71@mail.gmail.com> <4AC6872E.6060103@gmx.net> <2a50f7880910021732k68ae1a97qc7307ac52a225371@mail.gmail.com> <20091003173006.595.qmail@stuge.se> <2a50f7880910031449k13090dcdr8440d89ccb7fcfe9@mail.gmail.com> <1254607096.12717.10.camel@tetris> <4AC8F80C.2050702@us.ibm.com> <4AC8F9F2.3030508@coresystems.de> <4AC9EE84.1010803@us.ibm.com> In-Reply-To: <4AC9EE84.1010803@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Coreboot , Stefan Reinauer , qemu-devel@nongnu.org, ron minnich , Jordan Justen , Patrick Georgi On 05.10.2009 15:03, Anthony Liguori wrote: > Stefan Reinauer wrote: >> Anthony Liguori wrote: >> >>> Patrick Georgi wrote: >>> >>>> With coreboot, seabios and Duet, it should be reasonably simple to >>>> provide a single BIOS image that selects (based on nvram - ie. >>>> configuration) which interface to provide: PCBIOS or UEFI. >>>> >>> That isn't terribly useful for QEMU because it implies that QEMU needs >>> to make the decision about which one to use. If QEMU was capable of >>> making that decision without user intervention, then we could just >>> select to load PCBIOS or UEFI. >>> >> Are you guys sure you want to go down that road rather than using an >> UEFI with a CSM? > > We'll I've been advocating UEFI + CSM (based on SeaBIOS) so I'm not > sure what you meant by 'that road'. What about SeaBIOS + CSM (based on DUET)? That allows you to continue using all the Qemu specific init code in SeaBIOS and optionally load UEFI if some hardware needs it. A SeaBIOS based CSM will probably never get merged/supported at tianocore.org because of licensing, but the SeaBIOS + DUET solution should be supportable by upstream. I can't speak for Patrick, but he probably was concerned about making EFI the default with BIOS as fallback instead of the other way round. Forcing any EFI capable (or semi-capable) OS to be booted with EFI instead of leaving the choice in the hand of the user (NVRAM) or picking the sane default (what almost all boards out there are doing) sounds like a non-sustainable way for Qemu. >> This was attempted for Open Firmware and never happened during its life >> time. I doubt there is any incentive for vendors to ship devices without >> legacy option roms, especially since there is no advantage in doing so. >> > > We'll be stuck with legacy option roms for a long, long time. But I > also expect there will be a few devices out there that only provide > EFI modules. I expect that it will be some time before we see such devices (maybe only at trade show demos if at all). It will start to get interesting once such EFI modules have to interact with classic option ROMs. Regards, Carl-Daniel -- http://www.hailfinger.org/