From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtlSR-0003St-AU for qemu-devel@nongnu.org; Fri, 02 Oct 2009 12:58:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtlSM-0003Rv-EX for qemu-devel@nongnu.org; Fri, 02 Oct 2009 12:58:14 -0400 Received: from [199.232.76.173] (port=50110 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtlSL-0003Ro-Vw for qemu-devel@nongnu.org; Fri, 02 Oct 2009 12:58:10 -0400 Received: from mail-yw0-f176.google.com ([209.85.211.176]:56136) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtlSL-0001yl-It for qemu-devel@nongnu.org; Fri, 02 Oct 2009 12:58:09 -0400 Received: by ywh6 with SMTP id 6so667219ywh.4 for ; Fri, 02 Oct 2009 09:58:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4AC60037.6000001@codemonkey.ws> 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> Date: Fri, 2 Oct 2009 09:58:08 -0700 Message-ID: <2a50f7880910020958g3fe5eadehe5e5094c05b218d9@mail.gmail.com> Subject: Re: [Qemu-devel] Release plan for 0.12.0 From: Jordan Justen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , qemu-devel@nongnu.org On Fri, Oct 2, 2009 at 06:29, Anthony Liguori wrote= : > Jordan Justen wrote: >> >> On Thu, Oct 1, 2009 at 14:23, Anthony Liguori >> wrote: >> >>> >>> I see a CSM as a pre-requisite for merging a uefi rom. =A0A user can >>> already >>> use a uefi rom by simply using the -bios parameter so there's nothing >>> inhibiting testing. =A0My concern about introducing a new machine type = is >>> that >>> it would require duplicate testing and force the selection of uefi up >>> through the management tool stack. >>> >> >> I understand your points. =A0You want to keep a single machine type and >> try to support UEFI and legacy boots with that firmware. >> Unfortunately, I don't know that we will be able to provide that via >> OVMF. =A0There is no open source CSM for us to make use of. >> >> And, it is true that -bios can be used for OVMF by those with a >> particular interest in UEFI. =A0But for a more general audience, I think >> without the -M switch a Linux distribution couldn't package qemu in >> such a way that both a legacy bios and the OVMF firmware would be >> available. >> > > My concern is that if we provide separate machine types, it doubles our > testing since we have to test guests with both the BIOS firmware and the > UEFI firmware. =A0It also hurts usability since a user now has to make th= e > decision as to whether they want to use UEFI or not. =A0A user should not= have > to even know what EFI is. > > So I think the best way forward is to hold off on UEFI in mainline until = we > can provide a single unified stack. Ok. I understand if this is the way the QEMU project wants to proceed. I think it might delay UEFI support somewhat, but it certainly would be better for the user if they did not have to provide the correct command line to boot. 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? >>> OTH, uefi + a CSM based on SeaBIOS could be used as the default firmwar= e. >>> =A0I >>> don't think it's a reasonable target for 0.12 but I think if someone >>> actively worked on it, it would be possible for future releases. >>> >> >> I don't know of any efforts to create an open source CSM. =A0Is someone >> working on converting SeaBIOS to act as a CSM? >> > > There are multiple parties that seem to be interested in uefi for guests.= =A0I > expect that one of those parties will end up doing the work if that's the > requirement that we put down. > >> For tianocore.org & OVMF we would further be restricted by requiring a >> BSD licensed CSM. =A0Of course, if there was a SeaBIOS based CSM, then >> I'm sure OVMF could be modified to make use of it easily enough. =A0We >> just wouldn't be able to have the SeaBIOS CSM on tianocore.org and >> part of the normal tianocore.org OVMF releases. >> > > I don't think that's a big problem for us. Yes, I agree that this is would not be a problem for QEMU. In fact, I'd like to take back my opinion regarding how this may or may not be usable by tianocore.org and OVMF. Although we don't have GPL code hosted within any of our tianocore.org projects at this time, maybe this could change... I do know that we don't intend to start an open source CSM project on tianocore.org at this time. But, if such a project was started, I think we would support development via email on our edk2 dev list, and potentially even host the project on tianocore.org. So, I would invite anyone thinking of tackling such a task to join the edk2 dev list to discuss your work. Furthermore, if you'd like to request the project to be hosted on tianocore.org, feel free to ask our administrators. (As mentioned previously, we usually deal with the BSD license on tianocore.org, but please don't let this hold you back from asking questions, or requesting hosting of your project.) Thanks, -Jordan