From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPTPk-0004QX-Bb for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:42:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPTPg-0002R2-6C for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:42:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPTPf-0002Qv-U2 for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:42:12 -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> From: Laszlo Ersek Message-ID: <3d9e3ab4-86ae-40a9-3436-c04eb31dc9fa@redhat.com> Date: Tue, 19 Jul 2016 13:42:08 +0200 MIME-Version: 1.0 In-Reply-To: <1468925281.28378.121.camel@redhat.com> Content-Type: text/plain; charset=utf-8 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: Gerd Hoffmann Cc: Marcel Apfelbaum , Igor Mammedov , qemu-devel@nongnu.org, mst@redhat.com, pbonzini@redhat.com, ehabkost@redhat.com, peter.maydell@linaro.org, Ard Biesheuvel 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". >> Anyway, I digress. Point is, GRUB is already UEFI capable (I don't know >> uboot), so GRUB should be able to look up the DTB sysconfig table, and >> use that. The sysconfig table in question is identified by the GUID >> >> B1B621D5-F19C-41A5-830B-D9152C69AAE0 > > grub already does that on aarch64, Huh, indeed. I see "grub-core/loader/arm64/fdt.c". What does UEFI grub need the DTB for in the first place? Hm... looks like it pokes initrd information into it. Interesting. > but not on arm. > So that should be fixable without too much effort. I guess so. I'll mention though that "just" for passing in the initrd, the DTB shouldn't be necessary, at least if the kernel is built with the EFI stub. Then "initrd=filename" can be passed on the kernel command line, and the EFI stub should load it, using UEFI services, from the same directory that the vmlinuz binary (= itself) came from. ... I can never keep the 37 ways to boot the linux kernel in my mind for longer than 2 minutes. :/ Thanks Laszlo