ArmVirtualizationPkg: Intel BDS: load EFI-stubbed Linux kernel from fw_cfg

ArmVirtualizationPkg: Intel BDS: load EFI-stubbed Linux kernel from fw_cfg

A number of tools depend on passing the kernel image, the initial ramdisk,
and the kernel command line to the guest on the QEMU command line (options
-kernel, -initrd, -append, respectively). At the moment, these QEMU
options  work, but the guest kernel loaded this way is launched by a
minimal binary firmware that is dynamically composed by QEMU. As a
consequence, such a kernel has no UEFI environment.

This patch enables -kernel, -initrd, -append to work on top of the
ArmVirtualizationQemu firmware build. The approach it takes is different
from how the same functionality is implemented in OvmfPkg.

OvmfPkg contains a full-fledged Linux boot loader (see
"OvmfPkg/Library/PlatformBdsLib/QemuKernel.c" and
"OvmfPkg/Library/LoadLinuxLib/"). OVMF's LoadLinuxLib sets up the required
kernel environment in a sophisticated way (including x86-specific
artifacts like the GDT), calls ExitBootServices() itself (for legacy
kernels without EFI handover protocol), and jumps to the kernel (using x86
assembly).

In ArmVirtualizationPkg's PlatformIntelBdsLib, we require the kernel being
loaded to have an EFI stub -- that is, to be a genuine UEFI application.

(The EFI stub is not an additional burden for guest kernels -- the EFI
stub is a hard requirement anyway because it needs to process the DTB
heavily:
- it removes memory nodes,
- it removes memreserve entries,
- it adds UEFI properties to the "chosen" node,
- it calculates and installs virt-to-phys mappings with
  SetVirtualAddressMap() in a way that enables kexec [planned].

Kudos to Ard Biesheuvel for summarizing the above.)

An EFI-stubbed Linux guest kernel can be loaded with plain
gBS->LoadImage(). The EFI stub will look up its own
EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL instance (ie. the device path where
it has been loaded from), and it will locate the initial ramdisk named by
the "initrd" command line parameter as a *sibling file* on the same
device.

The initrd file is then loaded using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.

This approach enables the EFI stub to load the initial ramdisk from normal
EFI System Partitions, from remote PXE/TFTP directories -- and it enables
us to provide the initrd from memory as well.

In this patch:

- We download the kernel image, the initrd image, and the kernel command
  line, using QEMU's fw_cfg interface.

- We create a read-only EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instance that has
  just a root directory, with the three downloaded files in it.

- The handle that carries the simple file system has a single-node
  VenHw(...) device path (not counting the terminator node).

- We load the EFI-stubbed kernel (which is a UEFI application) with
  gBS->LoadImage(), passing "VenHw(...)/kernel" as device path. This
  causes gBS->LoadImage() to call back into our filesystem.

- Appended to the downloaded command line, we pass "initrd=initrd" to the
  EFI stub.

- Once the EFI stub is running, it loads the initial ramdisk from the
  "sibling" device path "VenHw(...)/initrd", also calling back into our
  filesystem.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16578 6f19259b-4bc3-4df7-8a09-765794883524