Problem background ------------------ 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.
Suggested approach ------------------ 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 Boot) - 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 Boot) configuration. [*] Open question: Who, between QEMU and libvirt, should define the said firmware metadata format and file? References ----------  A past proposal from Gerd to create a sort of a "firmware registry" https://www.redhat.com/archives/virt-tools-list/2014-September/msg00145.html  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: https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html -- [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) - /usr/share/OVMF/OVMF_CODE.fd - /usr/share/OVMF/OVMF_VARS.fd - OpenSUSE (package: "qemu-ovmf-x86_64" -- and it has *35* files in that package): - /usr/share/qemu/ovmf-x86_64-opensuse-code.bin - /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 system keys): https://build.opensuse.org/package/view_file/openSUSE:Factory/ovmf/ovmf.spec?expand=1 - Fedora 27 (package: "edk2-ovmf", x86_64): - /usr/share/edk2/ovmf/OVMF_CODE.fd - /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd - /usr/share/edk2/ovmf/OVMF_VARS.fd - RHEL-7.4 (package: "OVMF", x86_64): - /usr/share/OVMF/OVMF_CODE.secboot.fd - /usr/share/OVMF/OVMF_VARS.fd - Gerd's firmware repo from Git: - /usr/share/edk2.git/ovmf-x64/OVMF_VARS-need-smm.fd - /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd -- /kashyap -- libvir-list mailing list firstname.lastname@example.org https://www.redhat.com/mailman/listinfo/libvir-list