Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1605127

Summary: RFE: QEMU firmware metadata format - libvirt support [RHEL-7]
Product: Red Hat Enterprise Linux 7 Reporter: Kashyap Chamarthy <kchamart>
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED WONTFIX QA Contact: Meina Li <meili>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.6CC: areis, astupnik, berrange, crobinso, dyuan, egallen, jdenemar, jsuchane, kchamart, knoel, lersek, lmen, mtessun, phrdina, rjones, tburke, xuzhang, yalzhang
Target Milestone: rcKeywords: FutureFeature, Upstream
Target Release: ---Flags: kchamart: needinfo? (mtessun)
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1609225 (view as bug list) Environment:
Last Closed: 2019-04-03 11:57:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1624009, 1686552    
Bug Blocks: 1369007    

Description Kashyap Chamarthy 2018-07-20 08:52:31 UTC
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

Comment 3 Kashyap Chamarthy 2018-07-20 09:51:35 UTC
Related bugs:

    https://bugzilla.redhat.com/show_bug.cgi?id=1295146 -- 
    RFE: provide a bios=uefi XML convenience option

    https://bugzilla.redhat.com/show_bug.cgi?id=1546084 -- 
    RFE: Define and provide firmware (OVMF, etc) metadata format and file

Comment 4 Laszlo Ersek 2018-07-27 13:03:24 UTC
*** Bug 1295146 has been marked as a duplicate of this bug. ***

Comment 15 Daniel Berrange 2019-02-01 15:49:05 UTC
FYI from libvirt side this entire effort in QEMU stems from this original libvirt patch series https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html  where we concluded we wanted to replace libvirt's list of OVMF files with metadata before continuing.

Comment 18 Michal Privoznik 2019-02-04 11:38:48 UTC
There is some discussion about future of pflash happenning on the list:

https://www.redhat.com/archives/libvir-list/2019-January/msg01004.html

It may have effect in firmware.json therefore I'd rather wait for bug 1624009 to be fixed first (it's also set as dependency for this bug) to avoid scratching my work and starting over again.

Comment 21 Michal Privoznik 2019-03-19 11:51:57 UTC
Patches are now pushed upstream:

1dd24167b8 news: Document firmware autoselection for QEMU driver
6d9542e340 qemuFirmwareFetchConfigs: Fix check for @privileged
68ade25372 qemu: Enable firmware autoselection
d433f3cdd8 qemuDomainDefValidate: Don't require SMM if automatic firmware selection enabled
43527af27c qemu_process: Call qemuFirmwareFillDomain
804d2003e6 qemu_firmware: Introduce qemuFirmwareFillDomain()
31eb3093c0 qemufirmwaretest: Test qemuFirmwareFetchConfigs()
3c876d2428 qemu_firmware: Introduce qemuFirmwareFetchConfigs
04406d87d2 test: Introduce qemufirmwaretest
8b5b80f4c5 qemu: Introduce basic skeleton for parsing firmware description
d947fa8a08 conf: Introduce firmware attribute to <os/>
d21f89cc1a conf: Introduce VIR_DOMAIN_LOADER_TYPE_NONE
cdd592553a virDomainLoaderDefParseXML: Allow loader path to be NULL
849a0cfef1 qemu_capabilities: Expose qemu <-> libvirt arch translators
23018c0823 qemu_domain: Separate NVRAM VAR store file name generation

v5.1.0-206-g1dd24167b8

Comment 22 RHEL Product and Program Management 2019-04-03 11:57:07 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.