[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & fil
[Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file
Wed, 7 Mar 2018 15:49:51 +0100
The various OVMF binary file names and paths are slightly different[+]
for each Linux distribution. And each high-level management tool
(libguestfs, oVirt, `virt-manager` and OpenStack Nova) is inventing its
own approach to detect and configure the said OVMF files. This email
thread is about arriving at some common understanding to make this a bit
more "unified" by addressing these needs in QEMU and libvirt.
Based on an upstream discussion on 'virt-tools' mailing list and some
Bugzillas, Gerd Hoffmann, Laszlo Ersek and Dan Berrangé had a suggestion
to define a firmware metadata format and file (example in ):
- For each firmware file we need a metadata file in a well defined
location, e.g. /usr/share/qemu/bios/ that lists stuff like:
- Path to the firmware binary
- Path to the pre-built OVMF 'vars' file (if any)
- Support architectures - associated QEMU feature flags (Secure
- If the binary provides / requires SMM (System Management Mode)
Essentially, QEMU would define[*] the file format, and provide
metadata files from any ROMs it ships directly. If Linux
distributions / vendors ship extra ROMs like OVMF, etc then they
should provide suitable metadata files.
- Libvirt can read these metadata files and then pick the correct
firmware binary based on the settings for the guest.
- Management tools can then wire up the libvirt-based OVMF SB (Secure
[*] Open question: Who, between QEMU and libvirt, should define the said
firmware metadata format and file?
 A past proposal from Gerd to create a sort of a "firmware registry"
 A libvirt upstream RFE bug requesting to simplify handling UEFI
https://bugzilla.redhat.com/show_bug.cgi?id=1295146 -- RFE: provide
a bios=uefi XML convenience option
 DanPB wrote a PoC in libvirt:
-- [libvirt] [PATCH 0/3] Make UEFI firmware config simpler
But later came to the conclusion that it is flawed, and said we go
the route of "Suggested approach" mentioned earlier).
[*] OVMF package path names for different distributions
- Debian (https://packages.debian.org/stretch/all/ovmf/filelist)
- OpenSUSE (package: "qemu-ovmf-x86_64" -- and it has *35*
files in that package):
- /usr/share/qemu/ovmf-x86_64-opensuse-vars.bin [...]
Their RPM spec file gives some hints (where all the files with
'ms' means signed with MS keys; the files with 'opensuse-4096'
means signed with OpenSUSE 4096 bit CA keys -- I think that's one
of the points of Secure Boot, to let people have control over
- Fedora 27 (package: "edk2-ovmf", x86_64):
- RHEL-7.4 (package: "OVMF", x86_64):
- Gerd's firmware repo from Git:
- [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file,
Kashyap Chamarthy <=