This test case demonstrates how to manually configure an x86_64
guest to use the uefi-vars device.

It currently fails because the QEMU driver does not yet allow
the use of JSON for NVRAM. That will change in a future commit.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
 ...-manual-efi-qemuvars-q35.x86_64-latest.err |  1 +
 ...-manual-efi-qemuvars-q35.x86_64-latest.xml | 36 +++++++++++++++++++
 .../firmware-manual-efi-qemuvars-q35.xml      | 19 ++++++++++
 tests/qemuxmlconftest.c                       |  2 ++
 4 files changed, 58 insertions(+)
 create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
 create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
 create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml

diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
new file mode 100644
index 0000000000..e5f67f8d09
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
@@ -0,0 +1 @@
+unsupported configuration: Unsupported nvram format 'json'
diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
new file mode 100644
index 0000000000..a16c404eaf
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
@@ -0,0 +1,36 @@
+<domain type='qemu'>
+  <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>
+    <type arch='x86_64' machine='pc-q35-10.0'>hvm</type>
+    <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader>
+    <nvram format='json'>/path/to/guest.json</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>
+</domain>
diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml
new file mode 100644
index 0000000000..07b744d490
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml
@@ -0,0 +1,19 @@
+<domain type='qemu'>
+  <name>guest</name>
+  <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid>
+  <memory unit='KiB'>1048576</memory>
+  <vcpu placement='static'>1</vcpu>
+  <os>
+    <type arch='x86_64' machine='pc-q35-10.0'>hvm</type>
+    <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader>
+    <nvram format='json'>/path/to/guest.json</nvram>
+  </os>
+  <features>
+    <acpi/>
+  </features>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <controller type='usb' model='none'/>
+    <memballoon model='none'/>
+  </devices>
+</domain>
diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c
index 89b8ad1a35..1e20957656 100644
--- a/tests/qemuxmlconftest.c
+++ b/tests/qemuxmlconftest.c
@@ -1560,6 +1560,8 @@ mymain(void)
                                   ARG_CAPS_VARIANT, "+inteltdx",
                                   ARG_END);
 
+    DO_TEST_CAPS_LATEST_FAILURE("firmware-manual-efi-qemuvars-q35");
+
     /* Make sure all combinations of ACPI and UEFI behave as expected */
     DO_TEST_CAPS_ARCH_LATEST("firmware-manual-efi-acpi-aarch64", "aarch64");
     DO_TEST_CAPS_LATEST("firmware-manual-efi-acpi-q35");
-- 
2.52.0

On Mon, Dec 29, 2025 at 12:40:34AM +0100, Andrea Bolognani via Devel wrote:
> This test case demonstrates how to manually configure an x86_64
> guest to use the uefi-vars device.
> 
> It currently fails because the QEMU driver does not yet allow
> the use of JSON for NVRAM. That will change in a future commit.
> 
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
>  ...-manual-efi-qemuvars-q35.x86_64-latest.err |  1 +
>  ...-manual-efi-qemuvars-q35.x86_64-latest.xml | 36 +++++++++++++++++++
>  .../firmware-manual-efi-qemuvars-q35.xml      | 19 ++++++++++
>  tests/qemuxmlconftest.c                       |  2 ++
>  4 files changed, 58 insertions(+)
>  create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
>  create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
>  create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml
> 
> diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
> new file mode 100644
> index 0000000000..e5f67f8d09
> --- /dev/null
> +++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
> @@ -0,0 +1 @@
> +unsupported configuration: Unsupported nvram format 'json'
> diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
> new file mode 100644
> index 0000000000..a16c404eaf
> --- /dev/null
> +++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
> @@ -0,0 +1,36 @@
> +<domain type='qemu'>
> +  <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>
> +    <type arch='x86_64' machine='pc-q35-10.0'>hvm</type>
> +    <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader>
> +    <nvram format='json'>/path/to/guest.json</nvram>

IMHO it is wrong to be trying to squash the JSON vars storage
concept into the <nvram> element. It isn't providing NVRAM
to the guest and "json" is not a valid -blockdev format type,
so this is overloading concepts. IMHO there needs to be a
new config element to represent the new UEFI vars service
persistence concept.


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 :|

[adding Gerd]

On Wed, Jan 07, 2026 at 10:14:51AM +0000, Daniel P. Berrangé wrote:
> On Mon, Dec 29, 2025 at 12:40:34AM +0100, Andrea Bolognani via Devel wrote:
> > +  <os>
> > +    <type arch='x86_64' machine='pc-q35-10.0'>hvm</type>
> > +    <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader>
> > +    <nvram format='json'>/path/to/guest.json</nvram>
>
> IMHO it is wrong to be trying to squash the JSON vars storage
> concept into the <nvram> element. It isn't providing NVRAM
> to the guest and "json" is not a valid -blockdev format type,
> so this is overloading concepts. IMHO there needs to be a
> new config element to represent the new UEFI vars service
> persistence concept.

I went with the existing element because, from a user's perspective,
regardless of the underlying implementation details the experience is
effectively the same. But I see your point.

If we want to introduce a new element, perhaps it could look like
this:

  <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader>
  <varstore type='uefi-vars'>
    <template path='/usr/share/edk2/ovmf/OVMF_VARS.qemuvars.json'/>
    <source path='/path/to/guest.json'/>
  </varstore>

This leaves room to implement fine-grained certificate management as
an extension:

  <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader>
  <varstore type='uefi-vars'>
    <source path='/path/to/guest.json'/>
    <pk path='/path/to/microsoft-pk.pem'/>
    <kek path='/path/to/microsoft-kek.pem'/>
    <db path='/path/to/redhat.pem'/>
    <db path='/path/to/fedora.pem'/>
  </varstore>

Thoughts? Suggestion on better names for the elements/attributes? :)

-- 
Andrea Bolognani / Red Hat / Virtualization