mirror of https://github.com/acidanthera/audk.git
23d04b58e2
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 |
||
|---|---|---|
| .. | ||
| ArmJunoPkg | ||
| ArmRealViewEbPkg | ||
| ArmVExpressPkg | ||
| ArmVirtualizationPkg | ||
| Bds | ||
| Documentation | ||
| Drivers | ||
| FileSystem/BootMonFs | ||
| Include | ||
| Library | ||
| MemoryInitPei | ||
| PlatformPei | ||
| PrePeiCore | ||
| PrePi | ||
| Scripts | ||
| Sec | ||
| ArmPlatformPkg-2ndstage.dsc | ||
| ArmPlatformPkg-2ndstage.fdf | ||
| ArmPlatformPkg.dec | ||
| ArmPlatformPkg.dsc | ||
| ArmPlatformPkg.fdf | ||
| Contributions.txt | ||
| License.txt | ||