[PATCH 0/5] qemu: Fixes to firmware selection
See [1] for the discussion motivating these changes. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/U33UE... Andrea Bolognani (5): tests: Tweak descriptor for combined firmware tests: Add firmware-auto-efi-sev-snp qemu: Fix matching for stateless/combined firmware qemu: Fix matching for read/write firmware news: Update for firmware selection fixes NEWS.rst | 6 +++ src/qemu/qemu_firmware.c | 39 +++++++++++++------ .../usr/share/qemu/firmware/90-combined.json | 4 +- tests/qemufirmwaretest.c | 2 +- ...ware-auto-efi-rw-pflash.x86_64-latest.args | 36 +++++++++++++++++ ...mware-auto-efi-rw-pflash.x86_64-latest.err | 1 - ...mware-auto-efi-rw-pflash.x86_64-latest.xml | 6 ++- .../firmware-auto-efi-rw.x86_64-latest.args | 36 +++++++++++++++++ .../firmware-auto-efi-rw.x86_64-latest.err | 1 - .../firmware-auto-efi-rw.x86_64-latest.xml | 6 ++- ...auto-efi-sev-snp.x86_64-latest+amdsev.args | 37 ++++++++++++++++++ ...auto-efi-sev-snp.x86_64-latest+amdsev.xml} | 9 ++++- .../firmware-auto-efi-sev-snp.xml | 20 ++++++++++ tests/qemuxmlconftest.c | 8 +++- 14 files changed, 190 insertions(+), 21 deletions(-) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args copy tests/qemuxmlconfdata/{firmware-auto-efi-rw-pflash.x86_64-latest.xml => firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml} (76%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml -- 2.50.1
This kind of firmware build is not shipped in Fedora, where most descriptors in our test suite come from, so we had to make it up. It was based off the Secure Boot-enabled edk2 build, and the filename it points to is the same. That has been fine so far since it's not actually being picked up by any of the test cases, but that's going to change soon and when it does we want to be able to avoid any confusion. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- .../qemufirmwaredata/usr/share/qemu/firmware/90-combined.json | 4 ++-- tests/qemufirmwaretest.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/qemufirmwaredata/usr/share/qemu/firmware/90-combined.json b/tests/qemufirmwaredata/usr/share/qemu/firmware/90-combined.json index 2c8381adf7..8ecac440b4 100644 --- a/tests/qemufirmwaredata/usr/share/qemu/firmware/90-combined.json +++ b/tests/qemufirmwaredata/usr/share/qemu/firmware/90-combined.json @@ -1,5 +1,5 @@ { - "description": "OVMF with SB+SMM, SB enabled, MS certs enrolled", + "description": "OVMF with SB+SMM, SB enabled, MS certs enrolled (combined)", "interface-types": [ "uefi" ], @@ -7,7 +7,7 @@ "device": "flash", "mode": "combined", "executable": { - "filename": "/usr/share/edk2/ovmf/OVMF.secboot.fd", + "filename": "/usr/share/edk2/ovmf/OVMF.combined.fd", "format": "raw" } }, diff --git a/tests/qemufirmwaretest.c b/tests/qemufirmwaretest.c index f16ea526ff..a4fb5c9b9c 100644 --- a/tests/qemufirmwaretest.c +++ b/tests/qemufirmwaretest.c @@ -317,7 +317,7 @@ mymain(void) "/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd:" "/usr/share/edk2/ovmf/OVMF_CODE_4M.qcow2:/usr/share/edk2/ovmf/OVMF_VARS_4M.qcow2:" "/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd:" - "/usr/share/edk2/ovmf/OVMF.secboot.fd:NULL:" + "/usr/share/edk2/ovmf/OVMF.combined.fd:NULL:" "/usr/share/edk2/ovmf/OVMF.amdsev.fd:NULL:" "/usr/share/edk2/ovmf/OVMF.inteltdx.secboot.fd:NULL", VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS, -- 2.50.1
On 7/31/25 09:45, Andrea Bolognani via Devel wrote:
This kind of firmware build is not shipped in Fedora, where most descriptors in our test suite come from, so we had to make it up. It was based off the Secure Boot-enabled edk2 build, and the filename it points to is the same.
That has been fine so far since it's not actually being picked up by any of the test cases, but that's going to change soon and when it does we want to be able to avoid any confusion.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- .../qemufirmwaredata/usr/share/qemu/firmware/90-combined.json | 4 ++-- tests/qemufirmwaretest.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
This change seems fine independent of the others. Reviewed-by: Jim Fehlig <jfehlig@suse.com> Regards, Jim
This test case demonstrates how firmware autoselection doesn't currently work correctly for domains using SEV-SNP: the descriptor for a suitable firmware exists, and yet it doesn't get picked up. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- ...-auto-efi-sev-snp.x86_64-latest+amdsev.err | 1 + ...-auto-efi-sev-snp.x86_64-latest+amdsev.xml | 38 +++++++++++++++++++ .../firmware-auto-efi-sev-snp.xml | 20 ++++++++++ tests/qemuxmlconftest.c | 5 +++ 4 files changed, 64 insertions(+) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.err b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.err new file mode 100644 index 0000000000..3edb2b3451 --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.err @@ -0,0 +1 @@ +operation failed: Unable to find 'efi' firmware that is compatible with the current configuration diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml new file mode 100644 index 0000000000..81ac7888ea --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml @@ -0,0 +1,38 @@ +<domain type='kvm'> + <name>guest</name> + <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid> + <memory unit='KiB'>1048576</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static'>1</vcpu> + <os firmware='efi'> + <type arch='x86_64' machine='pc-q35-10.0'>hvm</type> + <loader format='raw'/> + <boot dev='hd'/> + </os> + <features> + <acpi/> + </features> + <cpu mode='custom' match='exact' check='none'> + <model fallback='forbid'>qemu64</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='usb' index='0' model='none'/> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pcie-root'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <audio id='1' type='none'/> + <watchdog model='itco' action='reset'/> + <memballoon model='none'/> + </devices> + <launchSecurity type='sev-snp'> + <policy>0x00030000</policy> + </launchSecurity> +</domain> diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml new file mode 100644 index 0000000000..ea980c06c2 --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml @@ -0,0 +1,20 @@ +<domain type='kvm'> + <name>guest</name> + <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid> + <memory unit='KiB'>1048576</memory> + <vcpu placement='static'>1</vcpu> + <os firmware='efi'> + <type arch='x86_64' machine='pc-q35-10.0'>hvm</type> + </os> + <features> + <acpi/> + </features> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='usb' model='none'/> + <memballoon model='none'/> + </devices> + <launchSecurity type="sev-snp"> + <policy>0x30000</policy> + </launchSecurity> +</domain> diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c index 678d2efbc3..272d314195 100644 --- a/tests/qemuxmlconftest.c +++ b/tests/qemuxmlconftest.c @@ -1477,6 +1477,11 @@ mymain(void) DO_TEST_CAPS_ARCH_LATEST_ABI_UPDATE("firmware-auto-efi-format-loader-raw", "aarch64"); DO_TEST_CAPS_LATEST("firmware-auto-efi-format-mismatch"); + DO_TEST_CAPS_ARCH_LATEST_FULL("firmware-auto-efi-sev-snp", "x86_64", + ARG_FLAGS, FLAG_EXPECT_FAILURE, + ARG_CAPS_VARIANT, "+amdsev", + ARG_END); + DO_TEST_CAPS_LATEST("clock-utc"); DO_TEST_CAPS_LATEST("clock-localtime"); DO_TEST_CAPS_LATEST("clock-localtime-basis-localtime"); -- 2.50.1
On 7/31/25 09:45, Andrea Bolognani via Devel wrote:
This test case demonstrates how firmware autoselection doesn't currently work correctly for domains using SEV-SNP: the descriptor for a suitable firmware exists, and yet it doesn't get picked up.
On my test system, autoselection for SEV-SNP guests does work after making the firmware descriptor changes suggested by Gerd https://src.fedoraproject.org/fork/kraxel/rpms/edk2/c/5146a0c3e9bf821d045e0c... It fails for SEV and SEV-ES guests. As a first step, I tried "importing" the descriptor changes to tests/qemufirmwaredata/, but as always I'm fighting with fixing up the tests :-/. Regards, Jim
On Tue, Aug 12, 2025 at 05:26:19PM -0600, Jim Fehlig wrote:
On 7/31/25 09:45, Andrea Bolognani via Devel wrote:
This test case demonstrates how firmware autoselection doesn't currently work correctly for domains using SEV-SNP: the descriptor for a suitable firmware exists, and yet it doesn't get picked up.
On my test system, autoselection for SEV-SNP guests does work after making the firmware descriptor changes suggested by Gerd
https://src.fedoraproject.org/fork/kraxel/rpms/edk2/c/5146a0c3e9bf821d045e0c...
It fails for SEV and SEV-ES guests. As a first step, I tried "importing" the descriptor changes to tests/qemufirmwaredata/, but as always I'm fighting with fixing up the tests :-/.
Patch importing the changes attached. Can you be more specific about the issue you're experiencing for SEV(-ES) guests? Based on the patch, the behavior doesn't seem to change at all there. Are you able to successfully start those guests when you use unmodified libvirt and edk2? Then again, the existing SEV tests look... Questionable. They all use the i440fx machine type and default (BIOS) firmware, whereas according to the documentation[1] you really want q35 and UEFI. So at best our test coverage is lacking. Stressing again the fact that I know very little about SEV and its variants, my impression is that generally speaking stateless firmware is preferred for the use case; however in Fedora the descriptors for "regular" edk2 builds with no Secure Boot[2] advertise support for the "amd-sev" and "amd-sev-es" firmware features, and since they sort before the SEV-specific builds[3] libvirt will pick them up unless you specifically ask for the firmware to be stateless. Not sure if the best way to get out of this situation is to shuffle the descriptors around, drop the SEV-specific features from other descriptors, or tweak the libvirt algorithm so that it will prefer stateless firmware for SEV unless told otherwise. Very much interested in hearing everyone's thoughts on the topic. [1] https://libvirt.org/kbase/launch_security_sev.html [2] /usr/share/qemu/firmware/5*-edk2-ovmf-*-x64-nosb.json [3] /usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsev*.json -- Andrea Bolognani / Red Hat / Virtualization
On 8/13/25 09:01, Andrea Bolognani wrote:
On Tue, Aug 12, 2025 at 05:26:19PM -0600, Jim Fehlig wrote:
On 7/31/25 09:45, Andrea Bolognani via Devel wrote:
This test case demonstrates how firmware autoselection doesn't currently work correctly for domains using SEV-SNP: the descriptor for a suitable firmware exists, and yet it doesn't get picked up.
On my test system, autoselection for SEV-SNP guests does work after making the firmware descriptor changes suggested by Gerd
https://src.fedoraproject.org/fork/kraxel/rpms/edk2/c/5146a0c3e9bf821d045e0c...
It fails for SEV and SEV-ES guests. As a first step, I tried "importing" the descriptor changes to tests/qemufirmwaredata/, but as always I'm fighting with fixing up the tests :-/.
Patch importing the changes attached.
Thanks! My trial and error approach to fixing the test suite would have eventually got there :-).
Can you be more specific about the issue you're experiencing for SEV(-ES) guests?
I'm seeing the same issue we were trying to solve for SNP guests with this series ERROR operation failed: Unable to find 'efi' firmware that is compatible with the current configuration
Based on the patch, the behavior doesn't seem to change at all there. Are you able to successfully start those guests when you use unmodified libvirt and edk2?
No, the same issue exists with SEV and SEV-ES guests. Sorry if that was not clear. Prior to separating SNP into its own descriptor, all three features shared the "stateless, pflash" descriptor, and all three suffered the problem you're fixing with this series. SNP works after providing a descriptor which properly identifies it as requiring a 'memory' device. AFAICT, the existing autoselection code already handles non-pflash devices.
Then again, the existing SEV tests look... Questionable. They all use the i440fx machine type and default (BIOS) firmware, whereas according to the documentation[1] you really want q35 and UEFI. So at best our test coverage is lacking.
Agreed.
Stressing again the fact that I know very little about SEV and its variants, my impression is that generally speaking stateless firmware is preferred for the use case; however in Fedora the descriptors for "regular" edk2 builds with no Secure Boot[2] advertise support for the "amd-sev" and "amd-sev-es" firmware features, and since they sort before the SEV-specific builds[3] libvirt will pick them up unless you specifically ask for the firmware to be stateless.
Not sure if the best way to get out of this situation is to shuffle the descriptors around, drop the SEV-specific features from other descriptors, or tweak the libvirt algorithm so that it will prefer stateless firmware for SEV unless told otherwise.
Very much interested in hearing everyone's thoughts on the topic.
AFAIK, only stateless firmware should be used with SEV and SEV-ES guests. Probably best to drop those features from the other descriptors. BTW, I often tend to ignore SEV and SEV-ES. IMO they are not used and can hopefully be removed from upstream projects in the future. This opinion was recently strengthened when I discovered that new BIOS updates to our Genoa and Turin systems will not allow the SEV-ES and SEV-SNP features to work together. Regards, Jim
On Thu, Aug 14, 2025 at 03:07:10PM -0600, Jim Fehlig wrote:
On 8/13/25 09:01, Andrea Bolognani wrote:
Can you be more specific about the issue you're experiencing for SEV(-ES) guests?
I'm seeing the same issue we were trying to solve for SNP guests with this series
ERROR operation failed: Unable to find 'efi' firmware that is compatible with the current configuration
Please share the debug output showing what happens during the firmware selection process. That will tell us why the amdsev.json descriptor is not considered suitable. I'm really surprised by this because things seem to work correctly in the context of the test suite, but clearly there's something going on. -- Andrea Bolognani / Red Hat / Virtualization
On 8/20/25 09:12, Andrea Bolognani wrote:
On Thu, Aug 14, 2025 at 03:07:10PM -0600, Jim Fehlig wrote:
On 8/13/25 09:01, Andrea Bolognani wrote:
Can you be more specific about the issue you're experiencing for SEV(-ES) guests?
I'm seeing the same issue we were trying to solve for SNP guests with this series
ERROR operation failed: Unable to find 'efi' firmware that is compatible with the current configuration
Please share the debug output showing what happens during the firmware selection process. That will tell us why the amdsev.json descriptor is not considered suitable. I'm really surprised by this because things seem to work correctly in the context of the test suite, but clearly there's something going on.
Debug output attached. I've also attached the amdsev.json equivalent I'm using for testing. And for completeness, here's the virt-install command virt-install --virt-type kvm --hvm --arch x86_64 --name sev-es-temp --vcpus 2,maxvcpus=4 --memory 2048,maxmemory=4096 --memtune hard_limit=4563402 --boot uefi --disk path=/vm_images/jim/images/sev-temp/disk0.qcow2,size=60,format=qcow2 --network bridge=br0,model=virtio --location http://blabla/install/sles15sp7/x86_64 --autoconsole text --extra-args "console=ttyS0,115200n8" --extra-args "textmode=1" --graphics vnc --serial pty --launchSecurity sev,policy=0x03 --machine q35 --events on_reboot=destroy Regards, Jim
On Mon, Aug 25, 2025 at 11:05:02AM -0600, Jim Fehlig wrote:
On 8/20/25 09:12, Andrea Bolognani wrote:
On Thu, Aug 14, 2025 at 03:07:10PM -0600, Jim Fehlig wrote:
On 8/13/25 09:01, Andrea Bolognani wrote:
Can you be more specific about the issue you're experiencing for SEV(-ES) guests?
I'm seeing the same issue we were trying to solve for SNP guests with this series
ERROR operation failed: Unable to find 'efi' firmware that is compatible with the current configuration
Please share the debug output showing what happens during the firmware selection process. That will tell us why the amdsev.json descriptor is not considered suitable. I'm really surprised by this because things seem to work correctly in the context of the test suite, but clearly there's something going on.
Debug output attached. I've also attached the amdsev.json equivalent I'm using for testing. And for completeness, here's the virt-install command
virt-install --virt-type kvm --hvm --arch x86_64 --name sev-es-temp --vcpus 2,maxvcpus=4 --memory 2048,maxmemory=4096 --memtune hard_limit=4563402 --boot uefi --disk path=/vm_images/jim/images/sev-temp/disk0.qcow2,size=60,format=qcow2 --network bridge=br0,model=virtio --location http://blabla/install/sles15sp7/x86_64 --autoconsole text --extra-args "console=ttyS0,115200n8" --extra-args "textmode=1" --graphics vnc --serial pty --launchSecurity sev,policy=0x03 --machine q35 --events on_reboot=destroy
Here are the relevant bits from the log: ... qemuInteropFetchConfigs:149 : firmware description path '/usr/share/qemu/firmware/50-ovmf-x86_64-sev-snp.json' len=464 qemuInteropFetchConfigs:149 : firmware description path '/usr/share/qemu/firmware/50-ovmf-x86_64-sev.json' len=570 qemuInteropFetchConfigs:149 : firmware description path '/usr/share/qemu/firmware/50-seabios-256k.json' len=664 ... qemuFirmwareMatchDomain:1361 : Domain requires SEV, firmware '/usr/share/qemu/firmware/50-ovmf-x86_64-sev-snp.json' doesn't support it qemuFirmwareMatchDomain:1311 : Discarding loader without split flash qemuFirmwareMatchDomain:1182 : No matching interface in '/usr/share/qemu/firmware/50-seabios-256k.json' ... So 50-ovmf-x86_64-sev.json is discarded because it advertises a stateless firmware, while libvirt assumes that you want a stateful one. Patch 05/10 from the v2 series should address this very problem by making a stateless firmware eligible for this scenario. Can you please try applying that series and checking whether that makes the issue go away? -- Andrea Bolognani / Red Hat / Virtualization
On 8/27/25 09:33, Andrea Bolognani wrote:
On Mon, Aug 25, 2025 at 11:05:02AM -0600, Jim Fehlig wrote:
On 8/20/25 09:12, Andrea Bolognani wrote:
On Thu, Aug 14, 2025 at 03:07:10PM -0600, Jim Fehlig wrote:
On 8/13/25 09:01, Andrea Bolognani wrote:
Can you be more specific about the issue you're experiencing for SEV(-ES) guests?
I'm seeing the same issue we were trying to solve for SNP guests with this series
ERROR operation failed: Unable to find 'efi' firmware that is compatible with the current configuration
Please share the debug output showing what happens during the firmware selection process. That will tell us why the amdsev.json descriptor is not considered suitable. I'm really surprised by this because things seem to work correctly in the context of the test suite, but clearly there's something going on.
Debug output attached. I've also attached the amdsev.json equivalent I'm using for testing. And for completeness, here's the virt-install command
virt-install --virt-type kvm --hvm --arch x86_64 --name sev-es-temp --vcpus 2,maxvcpus=4 --memory 2048,maxmemory=4096 --memtune hard_limit=4563402 --boot uefi --disk path=/vm_images/jim/images/sev-temp/disk0.qcow2,size=60,format=qcow2 --network bridge=br0,model=virtio --location http://blabla/install/sles15sp7/x86_64 --autoconsole text --extra-args "console=ttyS0,115200n8" --extra-args "textmode=1" --graphics vnc --serial pty --launchSecurity sev,policy=0x03 --machine q35 --events on_reboot=destroy
Here are the relevant bits from the log:
... qemuInteropFetchConfigs:149 : firmware description path '/usr/share/qemu/firmware/50-ovmf-x86_64-sev-snp.json' len=464 qemuInteropFetchConfigs:149 : firmware description path '/usr/share/qemu/firmware/50-ovmf-x86_64-sev.json' len=570 qemuInteropFetchConfigs:149 : firmware description path '/usr/share/qemu/firmware/50-seabios-256k.json' len=664 ... qemuFirmwareMatchDomain:1361 : Domain requires SEV, firmware '/usr/share/qemu/firmware/50-ovmf-x86_64-sev-snp.json' doesn't support it qemuFirmwareMatchDomain:1311 : Discarding loader without split flash qemuFirmwareMatchDomain:1182 : No matching interface in '/usr/share/qemu/firmware/50-seabios-256k.json' ...
So 50-ovmf-x86_64-sev.json is discarded because it advertises a stateless firmware, while libvirt assumes that you want a stateful one. Patch 05/10 from the v2 series should address this very problem by making a stateless firmware eligible for this scenario.
Nod. It's spread across threads and responses therein, but I've mentioned the patch works great for me :-).
Can you please try applying that series and checking whether that makes the issue go away?
I applied the full series on recent master and can verify autoselection works for SEV, SEV-ES and SEV-SNP guests. I wasn't able to verify TDX since the hardware is occupied ATM, but it should work fine. The TDX descriptor advertises the type as 'memory', and in my testing libvirt already correctly handled autoselection for that firmware device type. Regards, Jim
On 8/13/25 09:01, Andrea Bolognani wrote:
On Tue, Aug 12, 2025 at 05:26:19PM -0600, Jim Fehlig wrote:
On 7/31/25 09:45, Andrea Bolognani via Devel wrote:
This test case demonstrates how firmware autoselection doesn't currently work correctly for domains using SEV-SNP: the descriptor for a suitable firmware exists, and yet it doesn't get picked up.
On my test system, autoselection for SEV-SNP guests does work after making the firmware descriptor changes suggested by Gerd
https://src.fedoraproject.org/fork/kraxel/rpms/edk2/c/5146a0c3e9bf821d045e0c...
It fails for SEV and SEV-ES guests. As a first step, I tried "importing" the descriptor changes to tests/qemufirmwaredata/, but as always I'm fighting with fixing up the tests :-/.
Patch importing the changes attached.
Can you be more specific about the issue you're experiencing for SEV(-ES) guests? Based on the patch, the behavior doesn't seem to change at all there. Are you able to successfully start those guests when you use unmodified libvirt and edk2?
Then again, the existing SEV tests look... Questionable. They all use the i440fx machine type and default (BIOS) firmware, whereas according to the documentation[1] you really want q35 and UEFI. So at best our test coverage is lacking.
FYI, I've been working on a series that updates the existing SEV tests, includes your descriptor import, and slightly tweaked patches from this series https://gitlab.com/jfehlig/libvirt/-/tree/coco-firmware-autoselect-improveme...
Stressing again the fact that I know very little about SEV and its variants, my impression is that generally speaking stateless firmware is preferred for the use case; however in Fedora the descriptors for "regular" edk2 builds with no Secure Boot[2] advertise support for the "amd-sev" and "amd-sev-es" firmware features, and since they sort before the SEV-specific builds[3] libvirt will pick them up unless you specifically ask for the firmware to be stateless.
Not sure if the best way to get out of this situation is to shuffle the descriptors around, drop the SEV-specific features from other descriptors, or tweak the libvirt algorithm so that it will prefer stateless firmware for SEV unless told otherwise.
My WIP series drops the SEV features from the incompatible descriptors. I will be off the remainder of the week, but can tidy the series and post a V1 next week if there's interest. Regards, Jim
On Tue, Aug 19, 2025 at 04:09:28PM -0600, Jim Fehlig via Devel wrote:
On 8/13/25 09:01, Andrea Bolognani wrote:
Stressing again the fact that I know very little about SEV and its variants, my impression is that generally speaking stateless firmware is preferred for the use case; however in Fedora the descriptors for "regular" edk2 builds with no Secure Boot[2] advertise support for the "amd-sev" and "amd-sev-es" firmware features, and since they sort before the SEV-specific builds[3] libvirt will pick them up unless you specifically ask for the firmware to be stateless.
Not sure if the best way to get out of this situation is to shuffle the descriptors around, drop the SEV-specific features from other descriptors, or tweak the libvirt algorithm so that it will prefer stateless firmware for SEV unless told otherwise.
My WIP series drops the SEV features from the incompatible descriptors.
That feels premature. I'm okay with going in that direction, but it's not a change that we should make to the libvirt test suite before reaching an agreement and having the change applied to the edk2 package. The libvirt test suite is intended to match the real life behavior as closely as possible.
I will be off the remainder of the week, but can tidy the series and post a V1 next week if there's interest.
AFAICT you've made no code change other than squashing in the fixup that I had provided shortly after posting v1. Did I miss something? Your patch updating the SEV(-ES) tests to use q35 and UEFI looks reasonable from a quick look. I'll take a closer one and report back. Overall it doesn't IMO make sense for you to post a series off that branch. I can pick up your test suite changes, squash in my fix and post v2 next week. But before we can consider pushing any of this, we need to solve the SEV(-ES) issue you've mentioned elsewhere in the thread and reach an overall agreement on what the descriptors for firmware targeting all SEV variants should look like going forward. -- Andrea Bolognani / Red Hat / Virtualization
On Wed, Aug 20, 2025 at 08:24:51AM -0700, Andrea Bolognani wrote:
On Tue, Aug 19, 2025 at 04:09:28PM -0600, Jim Fehlig via Devel wrote:
I will be off the remainder of the week, but can tidy the series and post a V1 next week if there's interest.
AFAICT you've made no code change other than squashing in the fixup that I had provided shortly after posting v1. Did I miss something?
Your patch updating the SEV(-ES) tests to use q35 and UEFI looks reasonable from a quick look. I'll take a closer one and report back.
Overall it doesn't IMO make sense for you to post a series off that branch. I can pick up your test suite changes, squash in my fix and post v2 next week.
Done. https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/IBI4Z...
My WIP series drops the SEV features from the incompatible descriptors.
That feels premature. I'm okay with going in that direction, but it's not a change that we should make to the libvirt test suite before reaching an agreement and having the change applied to the edk2 package. The libvirt test suite is intended to match the real life behavior as closely as possible.
I just realized that one of the commits in my v2 pretty much matches this. Oops. Anyway I've marked it at DONOTMERGE because of the rationale above: we should never get ahead of the edk2 package, so that commit is just intended as a way to foster discussion. -- Andrea Bolognani / Red Hat / Virtualization
On 8/20/25 09:24, Andrea Bolognani wrote:
On Tue, Aug 19, 2025 at 04:09:28PM -0600, Jim Fehlig via Devel wrote:
On 8/13/25 09:01, Andrea Bolognani wrote:
Stressing again the fact that I know very little about SEV and its variants, my impression is that generally speaking stateless firmware is preferred for the use case; however in Fedora the descriptors for "regular" edk2 builds with no Secure Boot[2] advertise support for the "amd-sev" and "amd-sev-es" firmware features, and since they sort before the SEV-specific builds[3] libvirt will pick them up unless you specifically ask for the firmware to be stateless.
Not sure if the best way to get out of this situation is to shuffle the descriptors around, drop the SEV-specific features from other descriptors, or tweak the libvirt algorithm so that it will prefer stateless firmware for SEV unless told otherwise.
My WIP series drops the SEV features from the incompatible descriptors.
That feels premature. I'm okay with going in that direction, but it's not a change that we should make to the libvirt test suite before reaching an agreement and having the change applied to the edk2 package. The libvirt test suite is intended to match the real life behavior as closely as possible.
I will be off the remainder of the week, but can tidy the series and post a V1 next week if there's interest.
AFAICT you've made no code change other than squashing in the fixup that I had provided shortly after posting v1. Did I miss something?
No, you didn't miss anything. Poor choice of wording on my part. Instead of "I've been working on a series..." it would have been clearer to say "I've been assembling a series...". Afterall, 4 of the 6 patches are yours :-).
Your patch updating the SEV(-ES) tests to use q35 and UEFI looks reasonable from a quick look. I'll take a closer one and report back.
Overall it doesn't IMO make sense for you to post a series off that branch. I can pick up your test suite changes, squash in my fix and post v2 next week.
Agree it's better for you to continue with your series :-). I was just trying to help move this along while I had some free cycles. Regards, Jim
The current code assumes that a stateless firmware has to be explicitly requested by the user, and should never be picked otherwise. This means that, for example, domains configured to use SEV-SNP are forced to explicitly request for the firmware to be stateless. Additionally, we assume that only split firmware is suitable for the stateful use case, whereas a combined firmware image would also do the job. As a result of these changes, the failing SEV-SNP test case that was added recently passes, and so do the test cases requesting read/write firmware. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- src/qemu/qemu_firmware.c | 32 ++++++++++------ ...ware-auto-efi-rw-pflash.x86_64-latest.args | 36 ++++++++++++++++++ ...mware-auto-efi-rw-pflash.x86_64-latest.err | 1 - ...mware-auto-efi-rw-pflash.x86_64-latest.xml | 6 ++- .../firmware-auto-efi-rw.x86_64-latest.args | 36 ++++++++++++++++++ .../firmware-auto-efi-rw.x86_64-latest.err | 1 - .../firmware-auto-efi-rw.x86_64-latest.xml | 6 ++- ...auto-efi-sev-snp.x86_64-latest+amdsev.args | 37 +++++++++++++++++++ ...-auto-efi-sev-snp.x86_64-latest+amdsev.err | 1 - ...-auto-efi-sev-snp.x86_64-latest+amdsev.xml | 6 ++- tests/qemuxmlconftest.c | 5 +-- 11 files changed, 147 insertions(+), 20 deletions(-) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.err diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index f10137144e..22e0eb83f0 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -1300,16 +1300,21 @@ qemuFirmwareMatchDomain(const virDomainDef *def, return false; } - if (loader && loader->stateless == VIR_TRISTATE_BOOL_YES) { - if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) { - VIR_DEBUG("Discarding loader without stateless flash"); - return false; - } - } else { - if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) { - VIR_DEBUG("Discarding loader without split flash"); - return false; - } + /* Explicit requests for either a stateless or stateful + * firmware should be fulfilled, but if no preference is + * provided either one is fine as long as the other match + * criteria are satisfied */ + if (loader && + loader->stateless == VIR_TRISTATE_BOOL_YES && + flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) { + VIR_DEBUG("Discarding loader without stateless flash"); + return false; + } + if (loader && + loader->stateless == VIR_TRISTATE_BOOL_NO && + flash->mode == QEMU_FIRMWARE_FLASH_MODE_STATELESS) { + VIR_DEBUG("Discarding loader with stateless flash"); + return false; } if (loader && @@ -1424,9 +1429,14 @@ qemuFirmwareEnableFeaturesModern(virDomainDef *def, loader = def->os.loader; loader->type = VIR_DOMAIN_LOADER_TYPE_PFLASH; - loader->readonly = VIR_TRISTATE_BOOL_YES; loader->format = format; + /* Combined mode implies read/write, other modes imply read-only */ + if (flash->mode == QEMU_FIRMWARE_FLASH_MODE_COMBINED) + loader->readonly = VIR_TRISTATE_BOOL_NO; + else + loader->readonly = VIR_TRISTATE_BOOL_YES; + VIR_FREE(loader->path); loader->path = g_strdup(flash->executable.filename); diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args b/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args new file mode 100644 index 0000000000..d06de24db8 --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args @@ -0,0 +1,36 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/var/lib/libvirt/qemu/domain--1-guest \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-guest/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-guest/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=guest,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-guest/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF.combined.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":false,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-machine pc-q35-10.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,acpi=on \ +-accel kvm \ +-cpu qemu64 \ +-global driver=cfi.pflash01,property=secure,value=on \ +-m size=1048576k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err b/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err deleted file mode 100644 index 3edb2b3451..0000000000 --- a/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err +++ /dev/null @@ -1 +0,0 @@ -operation failed: Unable to find 'efi' firmware that is compatible with the current configuration diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.xml b/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.xml index 217c1f4b94..7b79738d98 100644 --- a/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.xml +++ b/tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.xml @@ -6,11 +6,15 @@ <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='x86_64' machine='pc-q35-10.0'>hvm</type> - <loader readonly='no' type='pflash' format='raw'/> + <firmware> + <feature enabled='yes' name='secure-boot'/> + </firmware> + <loader readonly='no' secure='yes' type='pflash' format='raw'>/usr/share/edk2/ovmf/OVMF.combined.fd</loader> <boot dev='hd'/> </os> <features> <acpi/> + <smm state='on'/> </features> <cpu mode='custom' match='exact' check='none'> <model fallback='forbid'>qemu64</model> diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args b/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args new file mode 100644 index 0000000000..d06de24db8 --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args @@ -0,0 +1,36 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/var/lib/libvirt/qemu/domain--1-guest \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-guest/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-guest/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=guest,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-guest/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF.combined.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":false,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-machine pc-q35-10.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,acpi=on \ +-accel kvm \ +-cpu qemu64 \ +-global driver=cfi.pflash01,property=secure,value=on \ +-m size=1048576k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err b/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err deleted file mode 100644 index 3edb2b3451..0000000000 --- a/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err +++ /dev/null @@ -1 +0,0 @@ -operation failed: Unable to find 'efi' firmware that is compatible with the current configuration diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.xml b/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.xml index 0f6b965067..7b79738d98 100644 --- a/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.xml +++ b/tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.xml @@ -6,11 +6,15 @@ <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='x86_64' machine='pc-q35-10.0'>hvm</type> - <loader readonly='no' format='raw'/> + <firmware> + <feature enabled='yes' name='secure-boot'/> + </firmware> + <loader readonly='no' secure='yes' type='pflash' format='raw'>/usr/share/edk2/ovmf/OVMF.combined.fd</loader> <boot dev='hd'/> </os> <features> <acpi/> + <smm state='on'/> </features> <cpu mode='custom' match='exact' check='none'> <model fallback='forbid'>qemu64</model> diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args new file mode 100644 index 0000000000..ab8fed6593 --- /dev/null +++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args @@ -0,0 +1,37 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/var/lib/libvirt/qemu/domain--1-guest \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-guest/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-guest/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=guest,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-guest/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF.amdsev.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/guest_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \ +-machine pc-q35-10.0,usb=off,dump-guest-core=off,memory-backend=pc.ram,confidential-guest-support=lsec0,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,acpi=on \ +-accel kvm \ +-cpu qemu64 \ +-m size=1048576k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-object '{"qom-type":"sev-snp-guest","id":"lsec0","cbitpos":51,"reduced-phys-bits":1,"policy":196608}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.err b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.err deleted file mode 100644 index 3edb2b3451..0000000000 --- a/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.err +++ /dev/null @@ -1 +0,0 @@ -operation failed: Unable to find 'efi' firmware that is compatible with the current configuration diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml index 81ac7888ea..1cc08ff4fd 100644 --- a/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml +++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml @@ -6,7 +6,11 @@ <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='x86_64' machine='pc-q35-10.0'>hvm</type> - <loader format='raw'/> + <firmware> + <feature enabled='no' name='secure-boot'/> + </firmware> + <loader readonly='yes' type='pflash' format='raw'>/usr/share/edk2/ovmf/OVMF.amdsev.fd</loader> + <nvram format='raw'>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram> <boot dev='hd'/> </os> <features> diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c index 272d314195..2d048746ea 100644 --- a/tests/qemuxmlconftest.c +++ b/tests/qemuxmlconftest.c @@ -1443,8 +1443,8 @@ mymain(void) DO_TEST_CAPS_LATEST("firmware-auto-efi"); DO_TEST_CAPS_LATEST_ABI_UPDATE("firmware-auto-efi"); DO_TEST_CAPS_LATEST("firmware-auto-efi-stateless"); - DO_TEST_CAPS_LATEST_FAILURE("firmware-auto-efi-rw"); - DO_TEST_CAPS_LATEST_FAILURE("firmware-auto-efi-rw-pflash"); + DO_TEST_CAPS_LATEST("firmware-auto-efi-rw"); + DO_TEST_CAPS_LATEST("firmware-auto-efi-rw-pflash"); DO_TEST_CAPS_LATEST("firmware-auto-efi-loader-secure"); DO_TEST_CAPS_LATEST_ABI_UPDATE("firmware-auto-efi-loader-secure"); DO_TEST_CAPS_LATEST("firmware-auto-efi-loader-insecure"); @@ -1478,7 +1478,6 @@ mymain(void) DO_TEST_CAPS_LATEST("firmware-auto-efi-format-mismatch"); DO_TEST_CAPS_ARCH_LATEST_FULL("firmware-auto-efi-sev-snp", "x86_64", - ARG_FLAGS, FLAG_EXPECT_FAILURE, ARG_CAPS_VARIANT, "+amdsev", ARG_END); -- 2.50.1
We currently always pick a read-only firmware unless we are explicitly asked for a read/write one, which is probably what most people expect anyway but doesn't really make sense otherwise: if no specific requirement has been provided by the user, both read-only and read/write firmwares should be allowed to match. This won't result in any change in practice, since distros are not shipping read/write builds of edk2 anyway. If they started doing that, it would be their responsibility to ensure that they are ordered after the read-only builds. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- src/qemu/qemu_firmware.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index 22e0eb83f0..0fb954993a 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -1317,6 +1317,13 @@ qemuFirmwareMatchDomain(const virDomainDef *def, return false; } + /* Same for read-only status */ + if (loader && + loader->readonly == VIR_TRISTATE_BOOL_YES && + flash->mode == QEMU_FIRMWARE_FLASH_MODE_COMBINED) { + VIR_DEBUG("Discarding read/write loader"); + return false; + } if (loader && loader->readonly == VIR_TRISTATE_BOOL_NO && flash->mode != QEMU_FIRMWARE_FLASH_MODE_COMBINED) { -- 2.50.1
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 5a320b7f33..b3c7dcb141 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -96,6 +96,12 @@ v11.6.0 (unreleased) ebtables, creating the base chains only if they did not already exist. + * qemu: Fix selection of stateless/combined firmware + + A stateless firmware will now be correctly chosen when appropriate, + e.g. for domains configured to use SEV-SNP. + + v11.5.0 (2025-07-01) ==================== -- 2.50.1
On 7/31/25 09:45, Andrea Bolognani via Devel wrote:
See [1] for the discussion motivating these changes.
[1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/U33UE...
Andrea Bolognani (5): tests: Tweak descriptor for combined firmware tests: Add firmware-auto-efi-sev-snp qemu: Fix matching for stateless/combined firmware qemu: Fix matching for read/write firmware news: Update for firmware selection fixes
Apologies for not having time to look at this in more detail today, but I quickly tried these patches and now see operation failed: unable to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin The descriptor file for this firmware contains { "description": "UEFI firmware for x86_64, with AMD SEV (Stateless)", "interface-types": [ "uefi" ], "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/qemu/ovmf-x86_64-sev.bin", "format": "raw" } }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "amd-sev", "amd-sev-es", "amd-sev-snp", "verbose-dynamic" ], "tags": [ ] } Regards, Jim
On Thu, Jul 31, 2025 at 11:33:08AM -0600, Jim Fehlig wrote:
Apologies for not having time to look at this in more detail today, but I quickly tried these patches and now see
operation failed: unable to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin
This happens at domain start time, right? Looking at the test case I added, the <nvram> element somehow is getting filled in even though it obviously shouldn't be. Additionally, I noticed that the stateless=yes attribute is not added either, so that's another detail that will to be sorted out. I'll look into it. -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Aug 01, 2025 at 02:06:44AM -0700, Andrea Bolognani wrote:
On Thu, Jul 31, 2025 at 11:33:08AM -0600, Jim Fehlig wrote:
Apologies for not having time to look at this in more detail today, but I quickly tried these patches and now see
operation failed: unable to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin
This happens at domain start time, right?
Looking at the test case I added, the <nvram> element somehow is getting filled in even though it obviously shouldn't be.
Additionally, I noticed that the stateless=yes attribute is not added either, so that's another detail that will to be sorted out.
I'll look into it.
Can you please try squashing in the diff below (and regenerating test data of course)? diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index 0fb954993a..502988d8ff 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -1444,6 +1444,9 @@ qemuFirmwareEnableFeaturesModern(virDomainDef *def, else loader->readonly = VIR_TRISTATE_BOOL_YES; + if (flash->mode == QEMU_FIRMWARE_FLASH_MODE_STATELESS) + loader->stateless = VIR_TRISTATE_BOOL_YES; + VIR_FREE(loader->path); loader->path = g_strdup(flash->executable.filename); -- Andrea Bolognani / Red Hat / Virtualization
On 8/1/25 03:14, Andrea Bolognani wrote:
On Fri, Aug 01, 2025 at 02:06:44AM -0700, Andrea Bolognani wrote:
On Thu, Jul 31, 2025 at 11:33:08AM -0600, Jim Fehlig wrote:
Apologies for not having time to look at this in more detail today, but I quickly tried these patches and now see
operation failed: unable to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin
This happens at domain start time, right?
Looking at the test case I added, the <nvram> element somehow is getting filled in even though it obviously shouldn't be.
Additionally, I noticed that the stateless=yes attribute is not added either, so that's another detail that will to be sorted out.
I'll look into it.
Can you please try squashing in the diff below (and regenerating test data of course)?
diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index 0fb954993a..502988d8ff 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -1444,6 +1444,9 @@ qemuFirmwareEnableFeaturesModern(virDomainDef *def, else loader->readonly = VIR_TRISTATE_BOOL_YES;
+ if (flash->mode == QEMU_FIRMWARE_FLASH_MODE_STATELESS) + loader->stateless = VIR_TRISTATE_BOOL_YES; + VIR_FREE(loader->path); loader->path = g_strdup(flash->executable.filename);
With this addition, the correct firmware is detected, but it's not properly provided to qemu internal error: QEMU unexpectedly closed the monitor (vm='sles15sp7-snp'): 2025-08-01T17:11:20.589614Z qemu-system-x86_64: pflash with kvm requires KVM readonly memory support The pertinent command line pieces being -blockdev '{"driver":"file","filename":"/usr/share/qemu/ovmf-x86_64-sev.bin","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard": "unmap"}' -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' But for SNP, it needs to be provided as bios, e.g. -bios /usr/share/qemu/ovmf-x86_64-sev.bin Are we correctly identifying this firmware in the descriptor file? It's advertised as a "flash" device, although I'm not sure if any of the other "FirmwareDevice" options [1] are appropriate. Perhaps the "FirmwareOSInterface" should be 'bios'? Regards, Jim [1] https://gitlab.com/qemu/qemu/-/blob/master/docs/interop/firmware.json?ref_ty...
On Fri, Aug 01, 2025 at 11:39:45AM -0600, Jim Fehlig via Devel wrote:
With this addition, the correct firmware is detected, but it's not properly provided to qemu
internal error: QEMU unexpectedly closed the monitor (vm='sles15sp7-snp'): 2025-08-01T17:11:20.589614Z qemu-system-x86_64: pflash with kvm requires KVM readonly memory support
The pertinent command line pieces being
-blockdev '{"driver":"file","filename":"/usr/share/qemu/ovmf-x86_64-sev.bin","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard": "unmap"}' -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
But for SNP, it needs to be provided as bios, e.g.
-bios /usr/share/qemu/ovmf-x86_64-sev.bin
Are we correctly identifying this firmware in the descriptor file? It's advertised as a "flash" device, although I'm not sure if any of the other "FirmwareDevice" options [1] are appropriate. Perhaps the "FirmwareOSInterface" should be 'bios'?
Adding Michal and Daniel to the conversation so that they can provide some insights. I have zero experience with SEV and no easy access to the relevant hardware. Assuming that * the need to use -bios for SEV-SNP is intended; * pflash still needs to be used for SEV (-ES?); * the edk2 build OVMF.amdsev.fd can be used for all variants; then I think that we need to have the edk2 package ship two separate descriptors pointing to the same file, one containing { "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd", "format": "raw" } }, "features": [ "amd-sev", "amd-sev-es" ] } for SEV(-ES) and one containing { "mapping": { "device": "memory", "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd" }, "features": [ "amd-sev-snp" ] } for SEV-SNP. With those in place, libvirt will be able to know how it should instruct QEMU to load the firmware. Hacking those changes into the test suite seems to confirm this. You can make similar changes to your local installation and test for yourself too. -- Andrea Bolognani / Red Hat / Virtualization
On 8/4/25 05:31, Andrea Bolognani wrote:
On Fri, Aug 01, 2025 at 11:39:45AM -0600, Jim Fehlig via Devel wrote:
With this addition, the correct firmware is detected, but it's not properly provided to qemu
internal error: QEMU unexpectedly closed the monitor (vm='sles15sp7-snp'): 2025-08-01T17:11:20.589614Z qemu-system-x86_64: pflash with kvm requires KVM readonly memory support
The pertinent command line pieces being
-blockdev '{"driver":"file","filename":"/usr/share/qemu/ovmf-x86_64-sev.bin","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard": "unmap"}' -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
But for SNP, it needs to be provided as bios, e.g.
-bios /usr/share/qemu/ovmf-x86_64-sev.bin
Are we correctly identifying this firmware in the descriptor file? It's advertised as a "flash" device, although I'm not sure if any of the other "FirmwareDevice" options [1] are appropriate. Perhaps the "FirmwareOSInterface" should be 'bios'?
Adding Michal and Daniel to the conversation so that they can provide some insights. I have zero experience with SEV and no easy access to the relevant hardware.
I don't follow qemu development close enough to know if pflash is now supported with SNP guests. AFAIK, only '-bios' was supported when the initial SNP enablement was merged.
Assuming that
* the need to use -bios for SEV-SNP is intended;
* pflash still needs to be used for SEV (-ES?);
* the edk2 build OVMF.amdsev.fd can be used for all variants;
then I think that we need to have the edk2 package ship two separate descriptors pointing to the same file, one containing
{ "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd", "format": "raw" } }, "features": [ "amd-sev", "amd-sev-es" ] }
for SEV(-ES) and one containing
{ "mapping": { "device": "memory", "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd" }, "features": [ "amd-sev-snp" ] }
for SEV-SNP.
With those in place, libvirt will be able to know how it should instruct QEMU to load the firmware. Hacking those changes into the test suite seems to confirm this. You can make similar changes to your local installation and test for yourself too.
I created a new descriptor file for SNP following your example and was able to create/install an SNP-aware guest with virt-install --boot uefi --launchSecurity sev-snp,policy=0x00030000 ... Regards, Jim
On Mon, Aug 04, 2025 at 02:15:01PM -0600, Jim Fehlig wrote:
On 8/4/25 05:31, Andrea Bolognani wrote:
On Fri, Aug 01, 2025 at 11:39:45AM -0600, Jim Fehlig via Devel wrote:
With this addition, the correct firmware is detected, but it's not properly provided to qemu
internal error: QEMU unexpectedly closed the monitor (vm='sles15sp7-snp'): 2025-08-01T17:11:20.589614Z qemu-system-x86_64: pflash with kvm requires KVM readonly memory support
The pertinent command line pieces being
-blockdev '{"driver":"file","filename":"/usr/share/qemu/ovmf-x86_64-sev.bin","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard": "unmap"}' -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
But for SNP, it needs to be provided as bios, e.g.
-bios /usr/share/qemu/ovmf-x86_64-sev.bin
Are we correctly identifying this firmware in the descriptor file? It's advertised as a "flash" device, although I'm not sure if any of the other "FirmwareDevice" options [1] are appropriate. Perhaps the "FirmwareOSInterface" should be 'bios'?
Adding Michal and Daniel to the conversation so that they can provide some insights. I have zero experience with SEV and no easy access to the relevant hardware.
I don't follow qemu development close enough to know if pflash is now supported with SNP guests. AFAIK, only '-bios' was supported when the initial SNP enablement was merged.
TDX/SNP are strictly -bios only and will remain that way. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Aug 05, 2025 at 08:08:14AM +0100, Daniel P. Berrangé wrote:
On Mon, Aug 04, 2025 at 02:15:01PM -0600, Jim Fehlig wrote:
On 8/4/25 05:31, Andrea Bolognani wrote:
On Fri, Aug 01, 2025 at 11:39:45AM -0600, Jim Fehlig via Devel wrote:
With this addition, the correct firmware is detected, but it's not properly provided to qemu
internal error: QEMU unexpectedly closed the monitor (vm='sles15sp7-snp'): 2025-08-01T17:11:20.589614Z qemu-system-x86_64: pflash with kvm requires KVM readonly memory support
The pertinent command line pieces being
-blockdev '{"driver":"file","filename":"/usr/share/qemu/ovmf-x86_64-sev.bin","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard": "unmap"}' -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
But for SNP, it needs to be provided as bios, e.g.
-bios /usr/share/qemu/ovmf-x86_64-sev.bin
Are we correctly identifying this firmware in the descriptor file? It's advertised as a "flash" device, although I'm not sure if any of the other "FirmwareDevice" options [1] are appropriate. Perhaps the "FirmwareOSInterface" should be 'bios'?
Adding Michal and Daniel to the conversation so that they can provide some insights. I have zero experience with SEV and no easy access to the relevant hardware.
I don't follow qemu development close enough to know if pflash is now supported with SNP guests. AFAIK, only '-bios' was supported when the initial SNP enablement was merged.
TDX/SNP are strictly -bios only and will remain that way.
Got it. The TDX descriptor is using device=memory already so it should work correctly today. Do you have any objections to the idea of separate descriptors for SEV(-ES) (device=flash) and SEV-SNP (device=memory) pointing to the same file? If not, I'll get the edk2 maintainer involved and make it happen. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Aug 05, 2025 at 01:18:12AM -0700, Andrea Bolognani wrote:
On Tue, Aug 05, 2025 at 08:08:14AM +0100, Daniel P. Berrangé wrote:
On Mon, Aug 04, 2025 at 02:15:01PM -0600, Jim Fehlig wrote:
On 8/4/25 05:31, Andrea Bolognani wrote:
On Fri, Aug 01, 2025 at 11:39:45AM -0600, Jim Fehlig via Devel wrote:
With this addition, the correct firmware is detected, but it's not properly provided to qemu
internal error: QEMU unexpectedly closed the monitor (vm='sles15sp7-snp'): 2025-08-01T17:11:20.589614Z qemu-system-x86_64: pflash with kvm requires KVM readonly memory support
The pertinent command line pieces being
-blockdev '{"driver":"file","filename":"/usr/share/qemu/ovmf-x86_64-sev.bin","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard": "unmap"}' -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
But for SNP, it needs to be provided as bios, e.g.
-bios /usr/share/qemu/ovmf-x86_64-sev.bin
Are we correctly identifying this firmware in the descriptor file? It's advertised as a "flash" device, although I'm not sure if any of the other "FirmwareDevice" options [1] are appropriate. Perhaps the "FirmwareOSInterface" should be 'bios'?
Adding Michal and Daniel to the conversation so that they can provide some insights. I have zero experience with SEV and no easy access to the relevant hardware.
I don't follow qemu development close enough to know if pflash is now supported with SNP guests. AFAIK, only '-bios' was supported when the initial SNP enablement was merged.
TDX/SNP are strictly -bios only and will remain that way.
Got it.
The TDX descriptor is using device=memory already so it should work correctly today.
Do you have any objections to the idea of separate descriptors for SEV(-ES) (device=flash) and SEV-SNP (device=memory) pointing to the same file? If not, I'll get the edk2 maintainer involved and make it happen.
Possibly we could just switch the existing descriptor, as with newer QEMU IIUC SEV/ES can use either device With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Hi,
Assuming that
* the need to use -bios for SEV-SNP is intended;
Yes. SEV-SNP (and TDX too) are by design incompatible with pflash emulation. Both do not allow the host change guest memory layout after launch, and pflash needs to do that to switch between reading mode and programming mode.
* pflash still needs to be used for SEV (-ES?);
You can use pflash with SEV + SEV-ES. It makes sense to do that if you want use a persistent variable store in pflash. Otherwise it doesn't make much of a difference whenever you use -bios or read-only pflash for the firmware.
then I think that we need to have the edk2 package ship two separate descriptors pointing to the same file, one containing
{ "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd", "format": "raw" } }, "features": [ "amd-sev", "amd-sev-es" ] }
for SEV(-ES) and one containing
{ "mapping": { "device": "memory", "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd" }, "features": [ "amd-sev-snp" ] }
for SEV-SNP.
That should work. Using device=memory for all three amd-sev* variants should work too I think. take care, Gerd
On Tue, Aug 05, 2025 at 12:56:56PM +0200, Gerd Hoffmann wrote:
Assuming that
* the need to use -bios for SEV-SNP is intended;
Yes. SEV-SNP (and TDX too) are by design incompatible with pflash emulation. Both do not allow the host change guest memory layout after launch, and pflash needs to do that to switch between reading mode and programming mode.
Thanks for providing the additional insight.
* pflash still needs to be used for SEV (-ES?);
You can use pflash with SEV + SEV-ES. It makes sense to do that if you want use a persistent variable store in pflash. Otherwise it doesn't make much of a difference whenever you use -bios or read-only pflash for the firmware.
The current descriptor uses mode=stateless so there is not going to be a persistent variable store.
then I think that we need to have the edk2 package ship two separate descriptors pointing to the same file, one containing
{ "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd", "format": "raw" } }, "features": [ "amd-sev", "amd-sev-es" ] }
for SEV(-ES) and one containing
{ "mapping": { "device": "memory", "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd" }, "features": [ "amd-sev-snp" ] }
for SEV-SNP.
That should work. Using device=memory for all three amd-sev* variants should work too I think.
Daniel suggested that elsewhere in the thread and of course it's an appealing proposition, as it would keep complexity down and unify handling across CVM use cases. However I wonder if changing things would break migration for existing SEV(-ES) guests. I think it would be fine since the current pflash-based configuration would be transmitted as part of the migration XML, so they will simply keep using that. If I'm right about the above, then I agree that we should just switch the existing SEV descriptor to device=memory. -- Andrea Bolognani / Red Hat / Virtualization
[adding Daniel to CC] On Tue, Aug 05, 2025 at 05:17:14AM -0700, Andrea Bolognani wrote:
On Tue, Aug 05, 2025 at 12:56:56PM +0200, Gerd Hoffmann wrote:
Assuming that
* the need to use -bios for SEV-SNP is intended;
Yes. SEV-SNP (and TDX too) are by design incompatible with pflash emulation. Both do not allow the host change guest memory layout after launch, and pflash needs to do that to switch between reading mode and programming mode.
Thanks for providing the additional insight.
* pflash still needs to be used for SEV (-ES?);
You can use pflash with SEV + SEV-ES. It makes sense to do that if you want use a persistent variable store in pflash. Otherwise it doesn't make much of a difference whenever you use -bios or read-only pflash for the firmware.
The current descriptor uses mode=stateless so there is not going to be a persistent variable store.
then I think that we need to have the edk2 package ship two separate descriptors pointing to the same file, one containing
{ "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd", "format": "raw" } }, "features": [ "amd-sev", "amd-sev-es" ] }
for SEV(-ES) and one containing
{ "mapping": { "device": "memory", "filename": "/usr/share/edk2/ovmf/OVMF.amdsev.fd" }, "features": [ "amd-sev-snp" ] }
for SEV-SNP.
That should work. Using device=memory for all three amd-sev* variants should work too I think.
Daniel suggested that elsewhere in the thread and of course it's an appealing proposition, as it would keep complexity down and unify handling across CVM use cases.
However I wonder if changing things would break migration for existing SEV(-ES) guests. I think it would be fine since the current pflash-based configuration would be transmitted as part of the migration XML, so they will simply keep using that.
If I'm right about the above, then I agree that we should just switch the existing SEV descriptor to device=memory.
-- Andrea Bolognani / Red Hat / Virtualization
[adding Daniel to CC]
Daniel suggested that elsewhere in the thread and of course it's an appealing proposition, as it would keep complexity down and unify handling across CVM use cases.
However I wonder if changing things would break migration for existing SEV(-ES) guests.
Yea. I've went the conservative way and created a test build keeping things as-is for SEV(-ES). Just in case, I don't know for sure if there are any failure modes if we switch guests from pflash to bios. https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/build/9376581... take care, Gerd
On 8/5/25 07:02, Gerd Hoffmann wrote:
[adding Daniel to CC]
Daniel suggested that elsewhere in the thread and of course it's an appealing proposition, as it would keep complexity down and unify handling across CVM use cases.
However I wonder if changing things would break migration for existing SEV(-ES) guests.
Yea. I've went the conservative way and created a test build keeping things as-is for SEV(-ES). Just in case, I don't know for sure if there are any failure modes if we switch guests from pflash to bios.
https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/build/9376581...
Thanks Gerd. I tend to agree with the conservative approach, which means the improvements in this series are still needed for firmware auto-selection to work with SEV and SEV-ES guests. Unfortunately, I've hit a regression somewhere in our stack and can no longer start existing SEV and SEV-ES guests. SNP is fine. I'll need to resolve that before continuing to test this series. Regards, Jim
participants (4)
-
Andrea Bolognani -
Daniel P. Berrangé -
Gerd Hoffmann -
Jim Fehlig