audk/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h

56 lines
1.8 KiB
C
Raw Normal View History

/** @file
Head file for BDS Platform specific code
Copyright (c) 2004 - 2008, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
distribution. The full text of the license may be found at
http://opensource.org/licenses/bsd-license.php
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
**/
#ifndef _INTEL_BDS_PLATFORM_H_
#define _INTEL_BDS_PLATFORM_H_
#include <Library/BaseLib.h>
#include <Library/BaseMemoryLib.h>
#include <Library/DebugLib.h>
#include <Library/DevicePathLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/UefiRuntimeServicesTableLib.h>
VOID
PlatformBdsEnterFrontPage (
IN UINT16 TimeoutDefault,
IN BOOLEAN ConnectAllHappened
);
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
2015-01-02 13:08:33 +01:00
/**
Download the kernel, the initial ramdisk, and the kernel command line from
QEMU's fw_cfg. Construct a minimal SimpleFileSystem that contains the two
image files, and load and start the kernel from it.
The kernel will be instructed via its command line to load the initrd from
the same Simple FileSystem.
@retval EFI_NOT_FOUND Kernel image was not found.
@retval EFI_OUT_OF_RESOURCES Memory allocation failed.
@retval EFI_PROTOCOL_ERROR Unterminated kernel command line.
@return Error codes from any of the underlying
functions. On success, the function doesn't
return.
**/
EFI_STATUS
EFIAPI
TryRunningQemuKernel (
VOID
);
#endif // _INTEL_BDS_PLATFORM_H