From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtppN-0004Gd-Mi for qemu-devel@nongnu.org; Fri, 02 Oct 2009 17:38:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtppJ-0004Cp-QR for qemu-devel@nongnu.org; Fri, 02 Oct 2009 17:38:13 -0400 Received: from [199.232.76.173] (port=42919 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtppJ-0004Cc-Hk for qemu-devel@nongnu.org; Fri, 02 Oct 2009 17:38:09 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:60935) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MtppI-0003Dw-S0 for qemu-devel@nongnu.org; Fri, 02 Oct 2009 17:38:09 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n92LX76m021662 for ; Fri, 2 Oct 2009 15:33:07 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n92LbqAl150110 for ; Fri, 2 Oct 2009 15:37:53 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n92LbqsG018556 for ; Fri, 2 Oct 2009 15:37:52 -0600 Message-ID: <4AC672AD.2020808@us.ibm.com> Date: Fri, 02 Oct 2009 16:37:49 -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> <2a50f7880910021357i2b441f5flb98b1fa41c5f2150@mail.gmail.com> In-Reply-To: <2a50f7880910021357i2b441f5flb98b1fa41c5f2150@mail.gmail.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: Jordan Justen Cc: Carl-Daniel Hailfinger , qemu-devel@nongnu.org Jordan Justen wrote: > Carl-Daniel, > > Interesting. So, where can I download a QEMU bios rom to boot a UEFI > OS with this solution? > > Can you explain what coreboot+tianocore means? Which parts of > tianocore do you use in this situation? > > If your solution can accomplish all of what you say, I'm not sure how > OVMF would be able to compete against in terms of being included with > QEMU. Part of the reason for starting OVMF was to help enable UEFI > support within VM's such as QEMU. If OVMF was utilized by QEMU it > definitely would have been a bit of a boost for our efforts, but if > QEMU accomplishes UEFI support via another path, then overall we will > still be happy. > FWIW, I looked more closely at Coreboot + SeaBIOS today. It's much less functional than just SeaBIOS alone. There really is no additional functionality because all payloads that Coreboot can run already run directly under QEMU (or under SeaBIOS). With respect to Coreboot + SeaBIOS + UEFI, AFAIK, you cannot have multiple payloads without using essentially a payload switcher (like Bayou). The problem with this though is your just deferring the EFI/BIOS choice to the user in a different place. What we need is a mechanism to transparently choose UEFI or SeaBIOS depending on whether the guest is EFI aware. I think option roms further complicate the matter because we would need a gPXE EFI module to support network boot. That makes the switch logic even more complicated. For PCI passthrough, I assume that the legacy option ROMs have to be loaded through a CSM so if we want to enable PCI passthrough, we really need a proper CSM. -- Regards, Anthony Liguori