From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtnGM-0000Qd-1U for qemu-devel@nongnu.org; Fri, 02 Oct 2009 14:53:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtnGG-0000QN-GO for qemu-devel@nongnu.org; Fri, 02 Oct 2009 14:53:52 -0400 Received: from [199.232.76.173] (port=45861 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtnGG-0000QK-Dq for qemu-devel@nongnu.org; Fri, 02 Oct 2009 14:53:48 -0400 Received: from mail-qy0-f173.google.com ([209.85.221.173]:36861) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtnGG-0003nV-1L for qemu-devel@nongnu.org; Fri, 02 Oct 2009 14:53:48 -0400 Received: by qyk3 with SMTP id 3so1129282qyk.4 for ; Fri, 02 Oct 2009 11:53:47 -0700 (PDT) Message-ID: <4AC64C32.4020509@codemonkey.ws> Date: Fri, 02 Oct 2009 13:53:38 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Release plan for 0.12.0 References: <4AC29E4D.80707@us.ibm.com> <4AC4A487.1050003@us.ibm.com> <2a50f7880910011410u6afbb658hf99839fdb3e7bab1@mail.gmail.com> <4AC51DBA.7020609@codemonkey.ws> <2a50f7880910011741k65ac8dfbq2fc8c9f58f5fa8d9@mail.gmail.com> <4AC60037.6000001@codemonkey.ws> <2a50f7880910020958g3fe5eadehe5e5094c05b218d9@mail.gmail.com> <4AC64A5C.6010003@gmx.net> In-Reply-To: <4AC64A5C.6010003@gmx.net> 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: Carl-Daniel Hailfinger Cc: Anthony Liguori , Jordan Justen , qemu-devel@nongnu.org Carl-Daniel Hailfinger wrote: > On 02.10.2009 18:58, Jordan Justen wrote: > >> On Fri, Oct 2, 2009 at 06:29, Anthony Liguori wrote: >> >> >>> So I think the best way forward is to hold off on UEFI in mainline until we >>> can provide a single unified stack. >>> >>> >> While it is true that a separate machine type could potentially be >> viewed as increasing the testing requirements, I am not so sure. If >> QEMU has a UEFI+CSM solution, wouldn't we still have to test both UEFI >> based OS boot and the CSM based legacy OS boot? >> >> > > Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and > have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI > interface), wouldn't that solve all problems in one go? You get an > unified stack and don't have to mess around with different firmware > files because coreboot can read in a Qemu machine config option (or > NVRAM/CMOS) and select the interface based on that. > If you want to to work seamlessly, you need to check for the EFI system partition to see whether it's an EFI capable OS and then fallback gracefully to SeaBIOS boot. > The hardware init part would be identical for all variants, only the > interface would differ. coreboot works now and has the benefit of > supporting real hardware as well, so the difference between a setup > inside Qemu and a setup on real hardware is minimal. > Tianocore's OVMF project should provide all the required initialization for EFI on QEMU. > The coreboot solution would also avoid converting SeaBIOS because > SeaBIOS already works as coreboot payload (that's how coreboot > developers call the CSM). > I'll bite, what's the advantage of doing coreboot + SeaBIOS vs. SeaBIOS alone? Forget about EFI for the moment, should be considering switching to coreboot + SeaBIOS for 0.12? Regards, Anthony Liguori