One of the new test cases 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.

Another test cases shows that, while firmware autoselection
succeeds for non-SNP SEV domains, the results are not the
expected ones: the generic (stateful) edk2 build is used
instead of the SEV-specific (stateless) one.

Finally, one test case provides coverage for the uncommon
scenario of stateful firmware being explicitly requested by
the user.

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 +++++++++
 ...efi-sev-stateful.x86_64-latest+amdsev.args | 37 ++++++++++++++++
 ...-efi-sev-stateful.x86_64-latest+amdsev.xml | 43 +++++++++++++++++++
 .../firmware-auto-efi-sev-stateful.xml        | 21 +++++++++
 ...are-auto-efi-sev.x86_64-latest+amdsev.args | 37 ++++++++++++++++
 ...ware-auto-efi-sev.x86_64-latest+amdsev.xml | 43 +++++++++++++++++++
 .../qemuxmlconfdata/firmware-auto-efi-sev.xml | 20 +++++++++
 tests/qemuxmlconftest.c                       | 15 +++++++
 10 files changed, 275 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
 create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.x86_64-latest+amdsev.args
 create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.x86_64-latest+amdsev.xml
 create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.xml
 create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev.x86_64-latest+amdsev.args
 create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev.x86_64-latest+amdsev.xml
 create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev.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..4bb363d07a
--- /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/qemuxmlconfdata/firmware-auto-efi-sev-stateful.x86_64-latest+amdsev.args b/tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.x86_64-latest+amdsev.args
new file mode 100644
index 0000000000..550ac52b8a
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.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_CODE.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-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-stateful.x86_64-latest+amdsev.xml b/tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.x86_64-latest+amdsev.xml
new file mode 100644
index 0000000000..b9a9ba8aa8
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.x86_64-latest+amdsev.xml
@@ -0,0 +1,43 @@
+<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>
+    <firmware>
+      <feature enabled='no' name='enrolled-keys'/>
+      <feature enabled='no' name='secure-boot'/>
+    </firmware>
+    <loader readonly='yes' type='pflash' stateless='no' format='raw'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
+    <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram>
+    <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'>
+    <policy>0x30000</policy>
+  </launchSecurity>
+</domain>
diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.xml b/tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.xml
new file mode 100644
index 0000000000..d6195f60e2
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev-stateful.xml
@@ -0,0 +1,21 @@
+<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>
+    <loader stateless='no'/>
+  </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'>
+    <policy>0x30000</policy>
+  </launchSecurity>
+</domain>
diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev.x86_64-latest+amdsev.args b/tests/qemuxmlconfdata/firmware-auto-efi-sev.x86_64-latest+amdsev.args
new file mode 100644
index 0000000000..550ac52b8a
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev.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_CODE.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-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.x86_64-latest+amdsev.xml b/tests/qemuxmlconfdata/firmware-auto-efi-sev.x86_64-latest+amdsev.xml
new file mode 100644
index 0000000000..cbfdcdeee3
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev.x86_64-latest+amdsev.xml
@@ -0,0 +1,43 @@
+<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>
+    <firmware>
+      <feature enabled='no' name='enrolled-keys'/>
+      <feature enabled='no' name='secure-boot'/>
+    </firmware>
+    <loader readonly='yes' type='pflash' format='raw'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
+    <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram>
+    <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'>
+    <policy>0x30000</policy>
+  </launchSecurity>
+</domain>
diff --git a/tests/qemuxmlconfdata/firmware-auto-efi-sev.xml b/tests/qemuxmlconfdata/firmware-auto-efi-sev.xml
new file mode 100644
index 0000000000..69e0c2bd51
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-auto-efi-sev.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'>
+    <policy>0x30000</policy>
+  </launchSecurity>
+</domain>
diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c
index 171a6f1c78..4d1d3e5f60 100644
--- a/tests/qemuxmlconftest.c
+++ b/tests/qemuxmlconftest.c
@@ -1477,6 +1477,21 @@ 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", "x86_64",
+                                  ARG_CAPS_VARIANT, "+amdsev",
+                                  ARG_END);
+    DO_TEST_CAPS_ARCH_LATEST_FULL("firmware-auto-efi-sev-snp", "x86_64",
+                                  ARG_FLAGS, FLAG_EXPECT_FAILURE,
+                                  ARG_CAPS_VARIANT, "+amdsev",
+                                  ARG_END);
+
+    /* Use of stateful firmware for SEV is uncommon, since it
+     * conflicts with boot measurements, but it's still possible for
+     * the user to explicitly request it */
+    DO_TEST_CAPS_ARCH_LATEST_FULL("firmware-auto-efi-sev-stateful", "x86_64",
+                                  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.51.0

On 9/10/25 07:57, Andrea Bolognani via Devel wrote:
> One of the new test cases 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.
> 
> Another test cases shows that, while firmware autoselection
> succeeds for non-SNP SEV domains, the results are not the
> expected ones: the generic (stateful) edk2 build is used
> instead of the SEV-specific (stateless) one.

Sorry for not understanding how this test is useful in practice. I understand it 
shows autoselection results are not what's expected, but since the test passes, 
how would one know that?

Regards,
Jim

On Wed, Sep 10, 2025 at 04:39:20PM -0600, Jim Fehlig wrote:
> On 9/10/25 07:57, Andrea Bolognani via Devel wrote:
> > One of the new test cases 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.
> >
> > Another test cases shows that, while firmware autoselection
> > succeeds for non-SNP SEV domains, the results are not the
> > expected ones: the generic (stateful) edk2 build is used
> > instead of the SEV-specific (stateless) one.
>
> Sorry for not understanding how this test is useful in practice. I
> understand it shows autoselection results are not what's expected, but since
> the test passes, how would one know that?

By reading the commit message ;)

Again, this just establishes the baseline. By the end of the series,
with firmware descriptors having been adjusted, firmware
autoselection will yield the expected results. You can see that in
patch 8.

If you want, I can add a comment along the lines of

  /* This succeeds, but the selected firmware is not the one
   * we want */

to qemuxmlconftest.c and drop it once descriptors are updated, for
additional clarity.

-- 
Andrea Bolognani / Red Hat / Virtualization

On 9/11/25 01:38, Andrea Bolognani wrote:
> On Wed, Sep 10, 2025 at 04:39:20PM -0600, Jim Fehlig wrote:
>> On 9/10/25 07:57, Andrea Bolognani via Devel wrote:
>>> One of the new test cases 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.
>>>
>>> Another test cases shows that, while firmware autoselection
>>> succeeds for non-SNP SEV domains, the results are not the
>>> expected ones: the generic (stateful) edk2 build is used
>>> instead of the SEV-specific (stateless) one.
>>
>> Sorry for not understanding how this test is useful in practice. I
>> understand it shows autoselection results are not what's expected, but since
>> the test passes, how would one know that?
> 
> By reading the commit message ;)
> 
> Again, this just establishes the baseline. By the end of the series,
> with firmware descriptors having been adjusted, firmware
> autoselection will yield the expected results. You can see that in
> patch 8.

Yes, had I looked. I stopped working for the day after patch 7 :-).

> If you want, I can add a comment along the lines of
> 
>    /* This succeeds, but the selected firmware is not the one
>     * we want */
> 
> to qemuxmlconftest.c and drop it once descriptors are updated, for
> additional clarity.

I think that would be good, especially if the descriptor updates take time to 
land in Fedora, and 1-7 are pushed in the meantime. With that

Reviewed-by: Jim Fehlig <jfehlig@suse.com>

Regards,
Jim

On Thu, Sep 11, 2025 at 12:54:25PM -0600, Jim Fehlig wrote:
> On 9/11/25 01:38, Andrea Bolognani wrote:
> > If you want, I can add a comment along the lines of
> >
> >    /* This succeeds, but the selected firmware is not the one
> >     * we want */
> >
> > to qemuxmlconftest.c and drop it once descriptors are updated, for
> > additional clarity.
>
> I think that would be good

Consider it done...

> especially if the descriptor updates take time
> to land in Fedora, and 1-7 are pushed in the meantime.

... but I wasn't planning on pushing this series until we have
reached an agreement on the edk2 side for the contents of the
descriptors.

Hopefully that won't take too long, and there's still some time
before the next release. We can reconsider in a week or so if
necessary.

-- 
Andrea Bolognani / Red Hat / Virtualization

On 9/12/25 00:58, Andrea Bolognani wrote:
> On Thu, Sep 11, 2025 at 12:54:25PM -0600, Jim Fehlig wrote:
>> On 9/11/25 01:38, Andrea Bolognani wrote:
>>> If you want, I can add a comment along the lines of
>>>
>>>     /* This succeeds, but the selected firmware is not the one
>>>      * we want */
>>>
>>> to qemuxmlconftest.c and drop it once descriptors are updated, for
>>> additional clarity.
>>
>> I think that would be good
> 
> Consider it done...
> 
>> especially if the descriptor updates take time
>> to land in Fedora, and 1-7 are pushed in the meantime.
> 
> ... but I wasn't planning on pushing this series until we have
> reached an agreement on the edk2 side for the contents of the
> descriptors.

After reading this again today, I came to the opinion that the edk2 related 
changes are a downstream issue that shouldn't block upstream fixes/improvements. 
That said, I'm happy to wait for an agreement, but would very much like the 
patches pushed in time for 11.8.0 :-).

Regards,
Jim

On Wed, Sep 17, 2025 at 12:57:36PM -0600, Jim Fehlig wrote:
> On 9/12/25 00:58, Andrea Bolognani wrote:
> > I wasn't planning on pushing this series until we have
> > reached an agreement on the edk2 side for the contents of the
> > descriptors.
>
> After reading this again today, I came to the opinion that the edk2 related
> changes are a downstream issue that shouldn't block upstream
> fixes/improvements. That said, I'm happy to wait for an agreement, but would
> very much like the patches pushed in time for 11.8.0 :-).

The unfortunate reality is that the upstream edk2 project doesn't
include any firmware descriptor at all AFAIK, leaving the task of
providing them to distros. So we are forced to pull from a "blessed"
downstream in order to test real world scenarios instead of made up
ones.

I'm actively working to get things sorted out in Fedora, but
unfortunately I'm having trouble getting access to SEV-capable
hardware and that's slowing things down.

We should still have a week or so before freeze. If the edk2 changes
are not made in time, I'm okay with pushing the rest of the series on
its own. Sounds good?

-- 
Andrea Bolognani / Red Hat / Virtualization

On 9/18/25 02:12, Andrea Bolognani wrote:
> On Wed, Sep 17, 2025 at 12:57:36PM -0600, Jim Fehlig wrote:
>> On 9/12/25 00:58, Andrea Bolognani wrote:
>>> I wasn't planning on pushing this series until we have
>>> reached an agreement on the edk2 side for the contents of the
>>> descriptors.
>>
>> After reading this again today, I came to the opinion that the edk2 related
>> changes are a downstream issue that shouldn't block upstream
>> fixes/improvements. That said, I'm happy to wait for an agreement, but would
>> very much like the patches pushed in time for 11.8.0 :-).
> 
> The unfortunate reality is that the upstream edk2 project doesn't
> include any firmware descriptor at all AFAIK, leaving the task of
> providing them to distros. So we are forced to pull from a "blessed"
> downstream in order to test real world scenarios instead of made up
> ones.
> 
> I'm actively working to get things sorted out in Fedora, but
> unfortunately I'm having trouble getting access to SEV-capable
> hardware and that's slowing things down.
> 
> We should still have a week or so before freeze. If the edk2 changes
> are not made in time, I'm okay with pushing the rest of the series on
> its own. Sounds good?

Sure, that's fine. Thanks a lot for your work on this series!

Regards,
Jim

On Thu, Sep 18, 2025 at 06:11:09AM -0600, Jim Fehlig wrote:
> On 9/18/25 02:12, Andrea Bolognani wrote:
> > I'm actively working to get things sorted out in Fedora, but
> > unfortunately I'm having trouble getting access to SEV-capable
> > hardware and that's slowing things down.
> >
> > We should still have a week or so before freeze. If the edk2 changes
> > are not made in time, I'm okay with pushing the rest of the series on
> > its own. Sounds good?
>
> Sure, that's fine. Thanks a lot for your work on this series!

Pushed now, ahead of tomorrow's freeze.

-- 
Andrea Bolognani / Red Hat / Virtualization

On 9/24/25 06:19, Andrea Bolognani wrote:
> On Thu, Sep 18, 2025 at 06:11:09AM -0600, Jim Fehlig wrote:
>> On 9/18/25 02:12, Andrea Bolognani wrote:
>>> I'm actively working to get things sorted out in Fedora, but
>>> unfortunately I'm having trouble getting access to SEV-capable
>>> hardware and that's slowing things down.
>>>
>>> We should still have a week or so before freeze. If the edk2 changes
>>> are not made in time, I'm okay with pushing the rest of the series on
>>> its own. Sounds good?
>>
>> Sure, that's fine. Thanks a lot for your work on this series!
> 
> Pushed now, ahead of tomorrow's freeze.

Thanks! Any progress on the firmware descriptor changes in the meantime?

Regards,
Jim

On Wed, Sep 24, 2025 at 04:34:25PM -0600, Jim Fehlig wrote:
> On 9/24/25 06:19, Andrea Bolognani wrote:
> > On Thu, Sep 18, 2025 at 06:11:09AM -0600, Jim Fehlig wrote:
> > > On 9/18/25 02:12, Andrea Bolognani wrote:
> > > > I'm actively working to get things sorted out in Fedora, but
> > > > unfortunately I'm having trouble getting access to SEV-capable
> > > > hardware and that's slowing things down.
> > > >
> > > > We should still have a week or so before freeze. If the edk2 changes
> > > > are not made in time, I'm okay with pushing the rest of the series on
> > > > its own. Sounds good?
> > >
> > > Sure, that's fine. Thanks a lot for your work on this series!
> >
> > Pushed now, ahead of tomorrow's freeze.
>
> Thanks! Any progress on the firmware descriptor changes in the meantime?

Nope, still having trouble getting access to suitable hardware :(
Hopefully that will be sorted out over the next week or two.

-- 
Andrea Bolognani / Red Hat / Virtualization