[Rationale]
edk2 provides EFI ROM images to be used by KVM VMs. On x86 this can be used as an alternative to seabios. On arm64, however, there is no "seabios" option - edk2 is the *only* way to boot an arm64 guest using the kernel/ramdisk configured in the image. Without edk2, users have to manually extract the kernel/ramdisk/cmdline from the cloud image and provide them externally to qemu. This obviously isn't a reasonable way to e.g. manage OpenStack instances, as the kernel/ramdisk would have to be re-extracted and reconfigured on every kernel security update. We'd therefore like to be able to have qemu-system-x86 and qemu-system-arm depend on the corresponding edk2 binary for the architecture.
edk2 is currently in multiverse due to a licensing restriction on the FAT driver code. Microsoft has recently removed the non-DFSG restriction.
[Security]
edk2 had a couple of CVEs assigned in 2014: CVE-2014-4859, CVE-2014-4860, but it looks like those were the only 2.
[Quality assurance]
The binary packages don't require any configuration - they're basically just providing data files that can optionally be used by QEMU.
[Dependencies]
All build deps are in main, and all produced binary packages have no runtime dependencies.
[Standards compliance]
EDK2 is the sample implementation for UEFI from Intel - de facto standards-compliant.
[Maintenance]
Canonical supports OpenStack on arm64, for which this is a key component. Linaro is actively maintaining the virt bits upstream, and Canonical's HWE and Foundations team are maintaining the package for that purpose.
[Availability] anonscm. debian. org/cgit/ pkg-qemu/ edk2.git)
Pending upload of 0~20160408 upstream snapshot release (in progress: http://
[Rationale] ramdisk/ cmdline from the cloud image and provide them externally to qemu. This obviously isn't a reasonable way to e.g. manage OpenStack instances, as the kernel/ramdisk would have to be re-extracted and reconfigured on every kernel security update. We'd therefore like to be able to have qemu-system-x86 and qemu-system-arm depend on the corresponding edk2 binary for the architecture.
edk2 provides EFI ROM images to be used by KVM VMs. On x86 this can be used as an alternative to seabios. On arm64, however, there is no "seabios" option - edk2 is the *only* way to boot an arm64 guest using the kernel/ramdisk configured in the image. Without edk2, users have to manually extract the kernel/
edk2 is currently in multiverse due to a licensing restriction on the FAT driver code. Microsoft has recently removed the non-DFSG restriction.
[Security]
edk2 had a couple of CVEs assigned in 2014: CVE-2014-4859, CVE-2014-4860, but it looks like those were the only 2.
[Quality assurance]
The binary packages don't require any configuration - they're basically just providing data files that can optionally be used by QEMU.
[Dependencies]
All build deps are in main, and all produced binary packages have no runtime dependencies.
[Standards compliance] compliant.
EDK2 is the sample implementation for UEFI from Intel - de facto standards-
[Maintenance]
Canonical supports OpenStack on arm64, for which this is a key component. Linaro is actively maintaining the virt bits upstream, and Canonical's HWE and Foundations team are maintaining the package for that purpose.
[Background information]