Re: [Qemu-devel] [PATCH 11/14] tests: acpi: add AVMF firmware blobs

[Laszlo Ersek]

Hello Michael,

On 01/16/19 17:01, Michael S. Tsirkin wrote:
> On Wed, Jan 16, 2019 at 01:29:53PM +0100, Igor Mammedov wrote:
>> On Tue, 15 Jan 2019 21:47:49 +0100
>> Laszlo Ersek <address@hidden> wrote:
>>
>>> On 01/15/19 16:41, Igor Mammedov wrote:
>>>> Add firmware blobs built with PcdAcpiTestSupport=TRUE,
>>>> that puts RSDP address in RAM after 1Mb aligned GUID
>>>>   AB87A6B1-2034-BDA0-71BD-375007757785
>>>> so that tests could scan and find it in RAM once firmware's
>>>> initialized ACPI tables.
>>>>
>>>> Signed-off-by: Igor Mammedov <address@hidden>
>>>> ---
>>>>  Makefile              |   3 ++-
>>>>  pc-bios/avmf.img      | Bin 0 -> 2097152 bytes
>>>>  pc-bios/avmf_vars.img | Bin 0 -> 786432 bytes
>>>>  3 files changed, 2 insertions(+), 1 deletion(-)
>>>>  create mode 100644 pc-bios/avmf.img
>>>>  create mode 100644 pc-bios/avmf_vars.img  
>>>
>>> "AVMF" is not a great name. "AAVMF" is a downstream name alright, but
>>> many dislike it in upstream use. "edk2-aarch64" or "edk2-ArmVirtQemu"
>>> would be more precise, but those are verbose. Sigh, why are names so
>>> hard. What does everyone think?
>> I'm fine with either version.
>>  
>>> Also, do you have to care about the license of firmware images built
>>> from edk2 when bundling such images? Since edk2 commit 9a67ba261fe9
>>> ("ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.",
>>> 2018-12-14), you cannot build the ArmVirtQemu (aka AAVMF) firmware
>>> without OpenSSL. Thus, the resultant license is 2-BSDL + OpenSSL -- for
>>> now anyway.
>>>
>>> Because, in the near future, that might change again. edk2 is in the
>>> process of moving to Apache-2.0, and OpenSSL will also move (AFAICT) to
>>> Apache-2.0 starting with release 3.0.0. (See commit 151333164ece,
>>> "Change license to the Apache License v2.0", 2018-12-06.)
>> That's another reason to look into EFI app approach (a simple one without
>> dependencies) ans let distro to provide firmware image.
> 
> That will mean supporting very old firmware with the app.
> I'm all for the EFI app approach for modularity
> but I think we should include the batteries with this toy.

There are two approaches here. (Both require that edk2 be present in the
QEMU source tree as a submodule, and both require QEMU to receive a
script for building edk2 in *some* way.)


(1) Carry the bios-tables-test helper UEFI app as an "out of tree"
module, from the perspective of edk2; carry it natively in the QEMU tree.

* Edk2 supports this use case as a first class citizen.

* In this case, the UEFI application is permitted to link only such
libraries from edk2 that the resultant binary inherit no platform
dependencies. The app can only be made dependent on a minimum UEFI spec
release, if necessary. The resultant binary can be run on any conformant
UEFI implementation, including physical hardware.

An example for "platform dependency prohibition" is that the X64 build
of the app could not print debug messages to the QEMU debug port (like
the rest of OVMF does), only to the UEFI console. On OVMF, that console
would direct the debug messages to the serial port and the graphics card.

Regarding a minimum UEFI spec release, the oldest UEFI spec I have on my
disk is "2.3.1, Errata C", dated "June 27, 2012". I'm not aware of
anything in the helper app that requires more recent spec features.

* Should we have to extend the UEFI app with a feature, we could easily
do that in sync with the consumer QEMU test code.

* The build output to commit to the QEMU repo would be an ISO image
containing the UEFI binary as a "boot loader". It would not contain
OpenSSL bits. The derived license would be a combination of core edk2's
license and our out-of-edk2-module's license.


(2) Carry the bios-tables-test helper *functionality* (not necessarily a
standalone UEFI application) in edk2; add a custom build flag to the
OVMF and ArmVirtQemu firmware platforms to enable the helper functionality.

* In this case, the test helper logic is permitted to rely on platform
internals. For example, on X64, it could print debug messages to the
QEMU debug port, like the rest of OVMF does.

* Whenever a new feature became necessary, edk2 would get new patches,
then QEMU would bump the submodule commit reference accordingly.

* The build output to commit to the QEMU repo would be a custom firmware
image (built with the special build flag mentioned above), and no other
bootable media would be formatted / saved. The custom firmware image
would contain OpenSSL bits. The image's license would be derived from
edk2 and from the OpenSSL submodule used by edk2.

* Also, the custom firmware image would not be suitable for "production"
use, so it couldn't be at once bundled under pc-bios as well -- that
would remain a separate RFE.


Since last night, I have some rough patches for (1), including the
QEMU-side Makefile + build script.

Regarding (2), I also have the edk2-native code ready (I had posted it a
few weeks back -- that's what Igor used now). For the QEMU side of
approach (2), I reckon I could reuse most of the build script I already
have for (1).

Could we please decide for (1) vs (2), before I put more work into (1)?

Thanks
Laszlo