Patches posted upstream.

  https://listman.redhat.com/archives/libvir-list/2023-February/237806.html

Patches merged upstream.

  commit 22207713cf8e82ab792acb3412720702938bfc81
  Author: Andrea Bolognani <abologna>
  Date:   Tue Feb 7 18:59:00 2023 +0100

    qemu: Add support for QCOW2 format firmware
    
    https://bugzilla.redhat.com/show_bug.cgi?id=2161965
    
    Signed-off-by: Andrea Bolognani <abologna>
    Reviewed-by: Michal Privoznik <mprivozn>

  v9.1.0-46-g22207713cf

Hi Andrea,

What I wonder is whether this new feature is only applicable to aarch? If yes, we need to update the Hardware field to aarch64.

I also think this bug may depend on some other edk2 RFE bugs which can provide code files, like /usr/share/AAVMF/AAVMF_CODE.qcow2. Could you refine this bug in more detail? 

Thanks.

(In reply to Meina Li from comment #3)
> What I wonder is whether this new feature is only applicable to aarch? If
> yes, we need to update the Hardware field to aarch64.

The implementation is completely architecture-independent and there
is nothing preventing the use of qcow2 builds on x86_64, but it seems
that only aarch64 would really benefit from their use so in practice
this could be considered an Arm-specific feature.

> I also think this bug may depend on some other edk2 RFE bugs which can
> provide code files, like /usr/share/AAVMF/AAVMF_CODE.qcow2. Could you refine
> this bug in more detail? 

Yeah, the libvirt part can't really be tested until edk2 builds that
contain qcow2 images are produced.

Gerd, is that work tracked anywhere? I'm only aware of Bug 2131254,
which tracks the QEMU part.

> > I also think this bug may depend on some other edk2 RFE bugs which can
> > provide code files, like /usr/share/AAVMF/AAVMF_CODE.qcow2. Could you refine
> > this bug in more detail? 
> 
> Yeah, the libvirt part can't really be tested until edk2 builds that
> contain qcow2 images are produced.

Fedora RPMS have qcow2 images for a while now (aarch64 only):

# ll /usr/share/edk2/aarch64/
total 206396
-rw-r--r--. 1 root root  2117632 Mar 21 16:20 QEMU_EFI-pflash.qcow2
-rw-r--r--. 1 root root 67108864 Mar 21 16:18 QEMU_EFI-pflash.raw
-rw-r--r--. 1 root root  2117632 Mar 21 16:20 QEMU_EFI-silent-pflash.qcow2
-rw-r--r--. 1 root root 67108864 Mar 21 16:19 QEMU_EFI-silent-pflash.raw
-rw-r--r--. 1 root root  2097152 Mar 21 16:18 QEMU_EFI.fd
-rw-r--r--. 1 root root  2097152 Mar 21 16:19 QEMU_EFI.silent.fd
-rw-r--r--. 1 root root   786432 Mar 21 16:18 QEMU_VARS.fd
-rw-r--r--. 1 root root   806912 Mar 21 16:20 vars-template-pflash.qcow2
-rw-r--r--. 1 root root 67108864 Mar 21 16:18 vars-template-pflash.raw

No firmware.json file shipped yet because that obviously depends
on libvirt being able to handle qcow2 files being listed there.

Once 9.2.0 is released I can add those (and a rpm conflict to
libvirt versions older than 9.2.0).

> Gerd, is that work tracked anywhere? I'm only aware of Bug 2131254,
> which tracks the QEMU part.

There is no rhel edk2 bug for that (yet).

More patches pushed upstream.

  commit 420a7a255058002155dbb68790a9f61091ddc7fa
  Author: Andrea Bolognani <abologna>
  Date:   Mon Mar 27 19:30:48 2023 +0200

    qemu: Default to raw firmware for existing domains
    
    The changes to the output files are the exact opposite of
    those from commit 22207713cf8e: this is proof that the fix is
    working as intended, and that existing domains will keep using
    raw firmware images regardless of whether or not qcow2 images
    are available on the system and have higher priority.
    
    New domains will keep picking whatever firmware is considered
    the preferred one according to the order of descriptors, as
    evidenced by the fact that the recently introduced
    firmware-auto-efi-abi-update-aarch64 test case is unaffected.
    
    Signed-off-by: Andrea Bolognani <abologna>
    Reviewed-by: Martin Kletzander <mkletzan>

  v9.2.0-rc1-5-g420a7a2550

For future reference, below is the complete list of commits that make
up the feature.

  420a7a2550 qemu: Default to raw firmware for existing domains
  6bafa74d62 tests: Add firmware-auto-efi-abi-update-aarch64 test case
  d7aaa715bd tests: Introduce DO_TEST_CAPS_ARCH_LATEST_ABI_UPDATE()
  f099d3fe10 qemu: Move validation check out of postparse
  e493a2ed73 conf: Move validation check out of postparse
  6d0d416f41 conf: Don't explicitly set the secure-boot feature
  24ad99d76d qemu: Automatically add firmware type/features information
  50d68c1d10 qemu: Don't drop firmware type/features information
  a0065f9728 conf: Don't format firmware type/features when migrating
  ccf4aa37a0 conf: Remove some firmware validation checks
  04568019c6 qemu: Always go through firmware autoselection
  63859189e6 qemu: Discard requires-smm firmware when loader.secure=no
  8b96a17019 qemu: Introduce qemuFirmwareMatchesPaths()
  3030010fa9 tests: Fix firmware descriptor masking test
  bf6a6f90a9 tests: Add more tests for manual Secure Boot configuration
  66e5c43a03 tests: Add firmware-auto-efi-loader-path
  d8d06f0a4a tests: Fix firmware-auto-efi-loader-path-nonstandard
  bfb507853a tests: Rename a few firmware tests
  b62d1b30ae qemu: Fix memory leaks in firmware selection code
  4b2799fdaa news: Document support for QCOW2 format firmware
  c85d7e3647 news: Document changes to firmware autoselection
  a50fb7dada docs: Document firmware format attribute
  44fb7659cc tests: Add more firmware tests
  22207713cf qemu: Add support for QCOW2 format firmware
  807e4c375a conf: Accept QCOW2 firmware format
  d283e1bd19 qemu: Propagate firmware format
  0569c6a13c qemu: Filter firmwares based on format
  9c39840673 drivers: Reject unsupported firmware formats
  1a6469e81f conf: Parse firmware format
  b3b81e60e4 conf: Change handling for empty NVRAM path
  e057a29b76 qemu: Introduce qemuFirmwareEnsureNVRAM()
  d4383682c4 qemu: Move qemuDomainNVRAMPathFormat() to qemu_firmware
  9567f3ba1f qemu: Move firmware selection from startup to postparse
  68b80a705c conf: Export virDomainDefOSValidate()
  ba5b338ee3 tests: Add descriptors for QCOW2 format firmware builds
  4b2d79fa7f qemu: Don't pick firmware with unsupported format
  22d0b644de qemu: Don't pick firmware that requires SMM when smm=off
  b4c3e4f39f qemu: Clear os.firmwareFeatures after autoselection
  6981019ed1 qemu: Only fill nvramTemplate for local sources
  19ce6573e9 qemu: Add convenience local variables
  572ab7cb76 conf: Introduce virDomainLoaderDefNew()
  c6bff86ae1 conf: Introduce virDomainLoaderDefParseXMLLoader()
  79e7d2c602 qemu: Introduce qemuDomainDefBootPostParse()
  7e12610387 qemu: Introduce qemuDomainDefMachinePostParse()
  6f1c6534a8 tests: Add more firmware tests
  54f90a825e tests: Enable qemuxml2xml for more firmware tests
  1fa20cd87c tests: Unify input files for firmware tests
  87ab00fdcb tests: Move firmware tests to CAPS_LATEST
  df551718a1 tests: Use x86_64 for all x86 firmware tests
  32f9342b5b tests: Rename firmware-manual-efi-rw* tests
  2adc24fc6a tests: Set nvramDir in qemuxml2xmltest
  f3d0857f2e docs: Fix documentation for loader.stateless attribute

Hi Gerd,

The libvirt patches for this bug have already been pushed. So when do you plan to implement the edk2 builds part? 
If there's a related edk2 bug on this, please help to link it to this bug.

Thanks.

> If there's a related edk2 bug on this, please help to link it to this bug.

It's bug 2186754 now.

> The libvirt patches for this bug have already been pushed. So when do you
> plan to implement the edk2 builds part?

Next week (when nothing else gets into the way).

Meanwhile: Fedora 37, 38, rawhide should have packages in updates-testing.

Alternatively try https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/
This does also provides eln + c9s + rhel9 builds (although rhel9 is x86_64 only
so not very useful in this case).

> The libvirt patches for this bug have already been pushed. So when do you
> plan to implement the edk2 builds part? 

Oh, and qemu 8.0 is needed too to actually observe the
memory footprint improvements we are aiming for.

Hi Andrea,

As we said before, only aarch64 would really benefit from this feature. And also from the edk2 developer's comments: https://bugzilla.redhat.com/show_bug.cgi?id=2186754#c9, we can see edk2 doesn't plan to use qcow2 images for other arches expect aarch64.

So based on these, could we move this bug to only aarch64? And then we only consider verifying this bug on aarch64 but not other arches. Because judging from the current situation of this bug, we need to verify it on x86_64.

Thanks.

Hi Andrea,

Sorry for forgetting to add needinfo in comment 11. Could you help to check the issues in it?

Thanks.

Awesome work!

What are the related QEMU commits?

Thanks!

(In reply to Laszlo Ersek from comment #13)
> What are the related QEMU commits?

This bug is for the libvirt part. I have no idea :)

You should ask in Bug 2131254, which tracks the QEMU part.

(In reply to Meina Li from comment #11)
> Hi Andrea,
> 
> As we said before, only aarch64 would really benefit from this feature. And
> also from the edk2 developer's comments:
> https://bugzilla.redhat.com/show_bug.cgi?id=2186754#c9, we can see edk2
> doesn't plan to use qcow2 images for other arches expect aarch64.
> 
> So based on these, could we move this bug to only aarch64? And then we only
> consider verifying this bug on aarch64 but not other arches. Because judging
> from the current situation of this bug, we need to verify it on x86_64.

So, it's true that only aarch64 will benefit from qcow2 images, and
based on that a decision has been made to *not* provide qcow2 images
on x86_64. Based on that, it would make sense to make the bug
aarch64-only.

However, in order to implement support for qcow2 images I had to make
pretty impactful changes to how firmware selection works in libvirt
in general. This affects x86_64 just as much as it does aarch64, so I
think it would be a good idea to look into extending whatever
validation is currently performed in that area to cover the new
behavior.

How do you think we should proceed? Keep this bug as it is now, using
it to cover both the qcow2 image support (aarch64 only) and the other
changes to firmware autoselection (all architectures)? Make this bug
aarch64 only and open a separate bug tracking the other changes?

Hi Andrea,

To distinguish bug clearly, we prefer to make this bug aarch64 only and open a separate bug tracking the other changes. Could you help to open another bug and add the related patches? I'm afraid I would miss some patches if I create it.

In addition, Do you know whether the libvirt code for different arches will be placed in different paths for maintenance? If no, I think we can directly move this bug to aarch64 only.

Thank you very much.

(In reply to Meina Li from comment #16)
> Hi Andrea,
> 
> To distinguish bug clearly, we prefer to make this bug aarch64 only and open
> a separate bug tracking the other changes. Could you help to open another
> bug

Done: Bug 2196178.

> and add the related patches? I'm afraid I would miss some patches if I
> create it.

All the patches have been merged as of libvirt 9.2.0, so there's
really no need to list them separately at this point.

> In addition, Do you know whether the libvirt code for different arches will
> be placed in different paths for maintenance?

All the changes are architecture-independent.

> If no, I think we can directly
> move this bug to aarch64 only.

Done.

Do negative test in X86_64 arch.
Test Version:
libvirt-9.3.0-1.el9.x86_64
qemu-kvm-8.0.0-1.el9.x86_64

Test Steps:
S1: Define a guest with qcow2 format loader.
1. Prepare a guest xml with qcow2 format loader.
  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-rhel9.2.0'>hvm</type>
    <loader format='qcow2'/>
  </os>
2. Define the guest.
# virsh define rhel.xml 
error: Failed to define domain from rhel.xml
error: operation failed: Unable to find any firmware to satisfy 'efi'
S2: Define a guest with qcow2 format nvram
1. Prepare a guest xml with qcow2 format nvram.
  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-rhel9.2.0'>hvm</type>
    <nvram format='qcow2'/>
  </os>
2. Define the guest.
# virsh define rhel.xml 
error: Failed to define domain from rhel.xml
error: operation failed: Unable to find any firmware to satisfy 'efi'

Can get an expected error message in X86_64 arch.

Change status to verified based on latest test result in comment#19

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: libvirt security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:6409