mirror of
https://github.com/acidanthera/audk.git
synced 2025-04-08 17:05:09 +02:00
190ceafe3c
While fixing https://github.com/tianocore/edk2/pull/6092 (the fact that some OvmfPkg and ArmVirtPkg platforms included residual NetworkPkg components even when compiled with -D NETWORK_ENABLE=0), it was noted that OvmfPkg/Include/*/Shell*.inc files which apply the required fix logic are available and already used in some OvmfPkg platforms. This commit applies these files consistently within OvmfPkg. This has the side effect that some platforms now include one or more of HttpDynamicCommand, VariablePolicyDynamicCommand and LinuxInitrdDynamicShellCommand when they previously did not. It is believed that in all cases these changes are neutral (i.e. not necessarily needed, but not harmful, and with the benefit of now using shared code) or positive (i.e. they fix unintentional drift between platforms, and provide additional shell commands which may be useful in some cases). Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
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_GCC/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 |
+-------------------+----------------+