From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPSZM-00005h-Rz for qemu-devel@nongnu.org; Tue, 19 Jul 2016 06:48:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPSZI-00067P-Ky for qemu-devel@nongnu.org; Tue, 19 Jul 2016 06:48:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPSZI-00067G-DS for qemu-devel@nongnu.org; Tue, 19 Jul 2016 06:48:04 -0400 Message-ID: <1468925281.28378.121.camel@redhat.com> From: Gerd Hoffmann Date: Tue, 19 Jul 2016 12:48:01 +0200 In-Reply-To: <54e1ba41-0a0f-59f9-c24b-bfa054fbba62@redhat.com> 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 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 Cc: Marcel Apfelbaum , Igor Mammedov , qemu-devel@nongnu.org, mst@redhat.com, pbonzini@redhat.com, ehabkost@redhat.com, peter.maydell@linaro.org, Ard Biesheuvel Hi, > > (2) ia32 ovmf too? Will anybody use it? >=20 > 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. >=20 > 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. > 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 >=20 > B1B621D5-F19C-41A5-830B-D9152C69AAE0 grub already does that on aarch64, but not on arm. So that should be fixable without too much effort. u-boot is out for -M virt due to missing virtio drivers. > $ qemu-system-(arm|aarch64) \ > -nographic -machine virt,dumpdtb=3Dvirt-dump.dtb > $ dtc -I dtb -O dts =20 > but that's not the right way to carry the DTB from QEMU to guest code Exactly. That just creates a reverse problem. Instead of copying the kernel from the image you now have to copy the dtb file to the image. > > There is one for the > > vexpress boards, which actually works (for v9). But it lists only the > > hardware physical vexpress boards have, any virtio-mmio devices you add > > are not listed there. >=20 > Right, the generated DTB lists all the virtio-mmio transports. But u-boot looks for dtb files in /boot/dtbs/$kernelver/ instead of using the one provided by qemu. So virtio isn't there (virtio-mmio @ vexpress works for a direct kernel boot). cheers, Gerd