Upstream QEMU has recently merged[1] a QAPI schema file "that describes
the different uses and properties of virtual machine firmware".

Based on which it would be useful if libvirt can provide a way to pick
the correct firmware type via an XML attribute: <os
firmware="bios|efi"/>, thus picking the right firmware type based on
guest configuration, machine type, and whether Secure Boot is requested
for the guest or not.

Quoting Dan Berrangé's response from the QEMU RFE thread[2]:

[quote]
    From a libvirt POV, we want to make it possible to just ask for a
    firmware type eg for x86_64 we want to allow apps to just do either

      <os firmware="bios"/>

    or

      <os firmware="efi"/>

    and then have libvirt automatically provide the best firmware image
    path to QEMU. We'll still allow apps to provide an explicit path
    themselves if they really want to, because if nothing else that's
    useful for people who need to test out ad-hoc firmware builds.

    IOW, in general if you (sysadmin/mgmt app) want to enable EFI for a
    guest, you should never need to care about firmware paths. This will
    give libvirt QEMU driver parity with what's possible for vmware
    guests in this area.

    With this in mind, when we talk about providing metadata files for
    firmware below, we should bear in mind that we likely want this
    metadata to be general purpose, not something specific to OVMF.  IOW
    all existing QEMU firmware images, for all architetures should be
    covered & whatever custom firmware users might have.
[/quote]


[1] https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3a0adfc
[2] http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01983.html


Related reading
---------------

The QEMU RFE discussion:

    http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01978.html
    "Defining firmware (OVMF, et al) metadata format & file"

From the same thread, Dan Berrangé goes on to expand the problem and
desired solution:

    http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01983.html