Re: [Qemu-devel] edk2 submodule + binaries (Re: [PATCH V5 2/7] tests/acpi: add pxb/pxb-pcie tests)

[Laszlo Ersek]

On 07/19/16 11:06, Gerd Hoffmann wrote:
>   Hi,
> 
>>> There is no integration yet with QEMU, right? Having a set of binaries
>>> like with SeaBIOS
>>> makes sense?
>>
>> Yes, it makes sense.
> 
> Indeed.  edk2 isn't exactly small though.  Adding the submodule would
> make the release tarballs noticable larger, and the prebuild binaries
> are not exactly small too ...
> 
> I remember we discussed moving all the pre-built binaries to a separate
> repo a while back.  Maybe we should think about that idea again?
> 
>>> Are there any licensing issues?
>>
>> If QEMU can bundle 2-clause BSDL binaries, then there shouldn't be.
> 
> I think with the FatPkg issue finally solved now there shouldn't be
> fundamental roadblocks any more.
> 
> Next question would be which architectures we want build edk2 for?
> 
>  (1) x64 ovmf is clear.
> 
>  (2) ia32 ovmf too?  Will anybody use it?

There are three bitness-combinations:
- Ia32: both PEI and DXE phases are 32-bit
- Ia32X64: PEI is 32-bit, DXE is 64-bit
- X64: both PEI and DXE are 64-bit

The bitness of the DXE phase must match the bitness of the operatig
system. So Ia32 can only boot 32-bit OSes (*), and the other two can
only boot 64-bit OSes.

(*) This is a bit relaxed for Linux guests, because Linux supports being
booted on a 32-bit DXE phase firmware, and then switches to 64-bit
itself. IIRC the idea here was to enable 64-bit Linux to run on tablets
and similar hardware that has a 64-bit CPU, but only comes with a fully
32-bit firmware (see
<https://blogs.intel.com/evangelists/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems/>).
But, without such OS-level tricks, in general Ia32 DXE implies 32-bit OS.

Then the next question is, what's the status of 32-bit UEFI OSes? Simple:

- 32-bit UEFI Windows exists, but it doesn't boot on OVMF. I don't know
why. I've spend a lot of time debugging it, on and off, with the
(sporadic) help of a Microsoft developer. We narrowed it down somewhat,
but it remains unsolved.

- 32-bit Linux may exist, but the distros I tried are either not
official (see Fedlet
<https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/>)
or I didn't get any usable results with them (IIRC I tried 32-bit UEFI
Debain once before, and it didn't work at all; but I'm fuzzy on that,
sorry).

Matthew Garrett also advises against (fully) 32-bit firmware:
<https://mjg59.dreamwidth.org/26734.html>

The distinction between Ia32X64 and X64 is less clear cut. The
difference between them is inivisible to the user (the bitness of the
PEI phase is not exposed to the OS), but in practice there is one
visible difference: the combination

  SMM driver stack + X64 PEI + S3 resume enabled on QEMU

is not supported by edk2 at the moment. So if the binary should support
SMM + S3, and allow the user not to bother about disabling S3 on the
QEMU command line, then Ia32X64 is the better choice.

Furthermore, the SMM driver stack limits the firmware to pc-q35-2.5+
machine types (no i440fx at all, and no q35 earlier than 2.5). This
might not be useful for everyone, I'm not sure.

CSM should never be enabled (SeaBIOS is bundled with QEMU already).

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.

>  (3) ArmVirtPkg for aarch64 should be built IMO.

Yup.

>  (4) What about ArmVirtPkg for 32bit arm?

It is a supported configuration in edk2, but I don't know how useful it
would be. We should ask Ard I guess.

>  (5) There is ArmPlatformPkg/ArmVExpressPkg.
>      Anyone tried that with qemu-system-{arm,aarch64} -M vexpress-* ?

Historically I may have used it I think, but that was before the arrival
of ArmVirtPkg (nee ArmPlatformPkg/ArmVirtualizationPkg) for the "virt"
machine type.

> While being at it:  Is there any way to setup a 32bit arm guest with a
> bootloader, so you don't have to somehow copy the guest kernel from the
> image to boot?

I'm unaware of any limitation in ArmVirtPkg or edk2 that would prevent
this; I just think OS bother to support 32-bit UEFI even less on ARM
than they do on x86.

> At least the upstream kernel doesn't support acpi @ 32bit arm, so the
> guest kernel can't find and use the hardware info provided by
> ArmVirtPkg.  Instead it depends on the bootloader passing a fdt.  But
> the bootloaders (grub+uboot) expect a file with the fdt somewhere.

ArmVirtPkg gets a generated DTB from QEMU at the base of system memory,
stashes it safely, uses it, and (unless disabled explicitly by a node in
the DTB) exposes it to the UEFI OS through a dedicated UEFI system
configuration table. Linux is capable of using this sysconfig table
already, so those boot loaders should be taught the same, assuming
32-bit UEFI ARM is so important.

QEMU                   ArmVirtQemu
 | ----- DT via RAM ------> |
 | --- ACPI via fw_cfg ---> |
 | -- SMBIOS via fw_cfg --> |                               guest kernel
                            | ---- DT via UEFI config table ----> |
                            | --- ACPI via UEFI config table ---> |
                            | -- SMBIOS via UEFI config table --> |

(According to my last information, the upstream kernel still prefers DT
over ACPI. I'm aware of two methods to talk it out of that:
- "acpi=force" on the guest kernel cmdline (dynamically),
- the "-D PURE_ACPI_BOOT_ENABLE" ArmVirtQemu build option
<https://github.com/tianocore/edk2/commit/b359fb9115b2>, which
statically removes the right hand side "DT" edge from the above diagram.)

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

(or written in C:
<https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/Include/Guid/Fdt.h>.)

> There isn't a file in the first place for -M virt.

It's not necessary, see above. If you would like to investigate the DTB
that QEMU generates, you can use:

  $ qemu-system-(arm|aarch64) \
      -nographic -machine virt,dumpdtb=virt-dump.dtb
  $ dtc -I dtb -O dts <virt-dump.dtb | less

but that's not the right way to carry the DTB from QEMU to guest code
(at least on the "virt" machine type).

> 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.

Right, the generated DTB lists all the virtio-mmio transports.

>  So sdcard storage is the only option.  Hmm.

Not necessarily; it can be considered a UEFI GRUB enhancement IMO.

Thanks,
Laszlo