From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPVxU-00075u-9w for qemu-devel@nongnu.org; Tue, 19 Jul 2016 10:25:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPVxP-0000yW-7v for qemu-devel@nongnu.org; Tue, 19 Jul 2016 10:25:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPVxP-0000y9-2N for qemu-devel@nongnu.org; Tue, 19 Jul 2016 10:25:11 -0400 References: <1468774394-23009-1-git-send-email-marcel@redhat.com> <1468774394-23009-3-git-send-email-marcel@redhat.com> <20160718153459.7aba3a1c@nial.brq.redhat.com> <2c3931eb-ae8b-51c7-5a6b-9166a459c87a@redhat.com> <578D2EC6.6080807@redhat.com> <1468919198.28378.100.camel@redhat.com> <54e1ba41-0a0f-59f9-c24b-bfa054fbba62@redhat.com> <1468925281.28378.121.camel@redhat.com> <3d9e3ab4-86ae-40a9-3436-c04eb31dc9fa@redhat.com> From: Marcel Apfelbaum Message-ID: <578E383F.70103@redhat.com> Date: Tue, 19 Jul 2016 17:25:03 +0300 MIME-Version: 1.0 In-Reply-To: <3d9e3ab4-86ae-40a9-3436-c04eb31dc9fa@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] edk2 submodule + binaries (Re: [PATCH V5 2/7] tests/acpi: add pxb/pxb-pcie tests) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , Gerd Hoffmann Cc: Igor Mammedov , qemu-devel@nongnu.org, mst@redhat.com, pbonzini@redhat.com, ehabkost@redhat.com, peter.maydell@linaro.org, Ard Biesheuvel On 07/19/2016 02:42 PM, Laszlo Ersek wrote: > On 07/19/16 12:48, Gerd Hoffmann wrote: >> Hi, >> >>>> (2) ia32 ovmf too? Will anybody use it? >>> >>> Then the next question is, what's the status of 32-bit UEFI OSes? Simple: >> >>> [ summary: bad ] >> >> Yep, that matches the impression I have. >> Guess we don't want bother then. >> >>> Enabling Secure Boot in the OVMF binary is orthogonal to all of the >>> above, but it has a licensing impact. It embeds (a subset of) OpenSSL in >>> the binary, and changes the terms from "2-clause BSDL" to "2-clause BSDL >>> and OpenSSL license" ("and" in the restrictive, not permissive, sense). >>> I'm unsure if QEMU is willing and able to distribute such binaries. >>> >>> For the widest and simplest usability, X64 (without the SMM driver stack >>> and without Secure Boot) is likely the best. >> >> Yes (also note the smm-enabled one doesn't run on i440fx). >> >> So the options I see are (a) build without smm or (b) build two >> variants. > > I think people who just want to run "UEFI payloads" are served well > enough by SMM-less. There are some developers who would benefit from a > -D SMM_REQUIRE build as well, but that would be because they actually > focus on SMM, I believe, so they can build their own firmware. > > If this is about the convenience of QEMU end-users, then I vote (a). I'd > certainly like to avoid fielding bug reports that boil down to "I booted > the -D SMM_REQUIRE build on i440fx". > I agree. For x86_64, OVMF 64-bit binaries without SMM or secure-boot support are enough for a wide "audience". Thanks, Marcel [...]