** This bug was initially created as a copy of Bug #2131254 ** Needed to take advantage of the format's support for sparseness, which along with recent QEMU changes will significantly reduce the memory usage of VMs on aarch64. ** Summary for the original bug ** On aarch64 the edk2 code flash and vars flash are padded to 64MB. This is not necessary on other archs. The FW expects the code being mapped at offset 0 and vars being mapping at offset 64MB. As QEMU currently packs one flash after the other so, the padding makes sure both flashes are at the right offset. We would like to remove the padding and teach qemu to map the vars flash at 64MB offset even if the code flash is smaller.
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