From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtiCX-0000kd-7C for qemu-devel@nongnu.org; Fri, 02 Oct 2009 09:29:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtiCS-0000dA-JV for qemu-devel@nongnu.org; Fri, 02 Oct 2009 09:29:36 -0400 Received: from [199.232.76.173] (port=35400 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtiCS-0000d1-DD for qemu-devel@nongnu.org; Fri, 02 Oct 2009 09:29:32 -0400 Received: from mail-qy0-f173.google.com ([209.85.221.173]:45152) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtiCR-0004FX-Tk for qemu-devel@nongnu.org; Fri, 02 Oct 2009 09:29:32 -0400 Received: by qyk3 with SMTP id 3so860569qyk.4 for ; Fri, 02 Oct 2009 06:29:31 -0700 (PDT) Message-ID: <4AC60037.6000001@codemonkey.ws> Date: Fri, 02 Oct 2009 08:29:27 -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> In-Reply-To: <2a50f7880910011741k65ac8dfbq2fc8c9f58f5fa8d9@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: Anthony Liguori , qemu-devel@nongnu.org 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. A user can already >> use a uefi rom by simply using the -bios parameter so there's nothing >> inhibiting testing. My 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. You 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. There 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. But 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. It also hurts usability since a user now has to make the decision as to whether they want to use UEFI or not. A 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. >> OTH, uefi + a CSM based on SeaBIOS could be used as the default firmware. I >> 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. Is someone > working on converting SeaBIOS to act as a CSM? > There are multiple parties that seem to be interested in uefi for guests. I 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. Of course, if there was a SeaBIOS based CSM, then > I'm sure OVMF could be modified to make use of it easily enough. We > 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. Regards, Anthony Liguori