Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Comment 18Michal 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 21Michal 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 22RHEL 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.
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