mirror of https://github.com/acidanthera/audk.git
6ced1e91ef
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 Add initial support for the new AmdSvsmLib library to OvmfPkg. The initial implementation fully implements the library interfaces. The SVSM presence check, AmdSvsmIsSvsmPresent(), determines the presence of an SVSM by checking if an SVSM has been advertised in the SEV-SNP Secrets Page. The VMPL API, AmdSvsmSnpGetVmpl(), returns the VMPL level at which OVMF is currently running. The CAA API, AmdSvsmSnpGetCaa(), returns the Calling Area Address when an SVSM is present, 0 otherwise. The PVALIDATE API, AmdSvsmSnpPvalidate(), copies the PVALIDATE logic from the BaseMemEncryptSevLib library for the initial implementation. The BaseMemEncryptSevLib library will be changed to use this new API so that the decision as to whether the SVSM is needed to perform the operation can be isolated to this library. The VMSA API, AmdSvsmSnpVmsaRmpAdjust(), copies the RMPUPDATE logic from the MpInitLib library for the initial implementation. The MpInitLib library will be changed to use this new API so that the decision as to whether the SVSM is needed to perform the operation can be isolated to this library. Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> |
||
---|---|---|
.. | ||
CloudHvDefines.fdf.inc | ||
CloudHvElfHeader.fdf.inc | ||
CloudHvX64.dsc | ||
CloudHvX64.fdf | ||
README |
README
CloudHv is a port of OVMF for the Cloud Hypervisor project. The Cloud Hypervisor project ---------------------------- Cloud Hypervisor is a Virtual Machine Monitor that runs on top of KVM. The project focuses on exclusively running modern, cloud workloads, on top of a limited set of hardware architectures and platforms. Cloud workloads refers to those that are usually run by customers inside a cloud provider. This means modern operating systems with most I/O handled by paravirtualised devices (i.e. virtio), no requirement for legacy devices, and 64-bit CPUs. https://github.com/cloud-hypervisor/cloud-hypervisor Design ------ Based on Cloud Hypervisor's motto to reduce the emulation as much as possible, the project logically decided to support the PVH boot specification as the only way of booting virtual machines. That includes both direct kernel boot and OVMF firmware which must be generated as PVH ELF binaries. PVH allows information like location of ACPI tables and location of guest RAM ranges to be shared without the need of an extra emulated device like a CMOS. Features -------- * Serial console * EFI shell * virtio-pci Build ----- The way to build the CloudHv target is as follows: OvmfPkg/build.sh -p OvmfPkg/CloudHv/CloudHvX64.dsc -a X64 -b DEBUG Usage ----- Assuming Cloud Hypervisor is already built, one can start a virtual machine as follows: ./cloud-hypervisor \ --cpus boot=1 \ --memory size=1G \ --kernel Build/CloudHvX64/DEBUG_GCC5/FV/CLOUDHV.fd \ --disk path=/path/to/disk.raw Releases -------- In edk2-stable202202, CloudHv is generated as data-only binary. Starting with edk2-stable202205, CloudHv is generated as a PVH ELF binary to reduce the amount of emulation needed from Cloud Hypervisor. For TDX, things are handled differently and PVH is not used, which is why the firmware is always generated as a data-only binary. +-------------------+----------------+ | | CloudHv | +-------------------+----------------+ | edk2-stable202202 | Data binary | +-------------------+----------------+ | edk2-stable202205 | PVH ELF binary | +-------------------+----------------+