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

[Laszlo Ersek]

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