This was not necessary until now since ROMs couldn't have an
associate NVRAM template, and technically speaking they still
can't; however, the varstore template serves essentialy the
same purpose.

The qemuFirmwareGetSupported() helper is used in two places:
one is the code that is responsible for filling in domaincaps,
where templates are ignored so this change has no impact on it;
the other is the qemufirmware test program, where this value
being reported is useful as it will allow us to confirm that
the JSON firmware descriptors for uefi-vars enabled builds are
parsed correctly.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
 src/qemu/qemu_firmware.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c
index f64ea287b4..56f03bc907 100644
--- a/src/qemu/qemu_firmware.c
+++ b/src/qemu/qemu_firmware.c
@@ -2162,6 +2162,7 @@ qemuFirmwareGetSupported(const char *machine,
 
         case QEMU_FIRMWARE_DEVICE_MEMORY:
             fwpath = memory->filename;
+            nvrampath = memory->template;
             break;
 
         case QEMU_FIRMWARE_DEVICE_NONE:
-- 
2.53.0

On Wed, Feb 18, 2026 at 01:05:43PM +0100, Andrea Bolognani via Devel wrote:
> This was not necessary until now since ROMs couldn't have an
> associate NVRAM template, and technically speaking they still
> can't; however, the varstore template serves essentialy the
> same purpose.
> 
> The qemuFirmwareGetSupported() helper is used in two places:
> one is the code that is responsible for filling in domaincaps,
> where templates are ignored so this change has no impact on it;
> the other is the qemufirmware test program, where this value
> being reported is useful as it will allow us to confirm that
> the JSON firmware descriptors for uefi-vars enabled builds are
> parsed correctly.
> 
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
>  src/qemu/qemu_firmware.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

On Mon, Feb 23, 2026 at 12:55:14PM +0000, Daniel P. Berrangé via Devel wrote:
> On Wed, Feb 18, 2026 at 01:05:43PM +0100, Andrea Bolognani via Devel wrote:
> > This was not necessary until now since ROMs couldn't have an
> > associate NVRAM template, and technically speaking they still
> > can't; however, the varstore template serves essentialy the
> > same purpose.
> > 
> > The qemuFirmwareGetSupported() helper is used in two places:
> > one is the code that is responsible for filling in domaincaps,
> > where templates are ignored so this change has no impact on it;
> > the other is the qemufirmware test program, where this value
> > being reported is useful as it will allow us to confirm that
> > the JSON firmware descriptors for uefi-vars enabled builds are
> > parsed correctly.
> > 
> > Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> > ---
> >  src/qemu/qemu_firmware.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Having said that, I'm a bit uncomfortable about the virFirmware
returned object reporting template for JSON vars without any
indication that it is is different from the template reported
for NVRAM vars.

If it is only used in the qemufirmware test that's at least
safe, but the virFirmware data model is now a trapdoor for the
unwary....

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

On Mon, Feb 23, 2026 at 12:58:50PM +0000, Daniel P. Berrangé wrote:
> On Mon, Feb 23, 2026 at 12:55:14PM +0000, Daniel P. Berrangé via Devel wrote:
> > On Wed, Feb 18, 2026 at 01:05:43PM +0100, Andrea Bolognani via Devel wrote:
> > > This was not necessary until now since ROMs couldn't have an
> > > associate NVRAM template, and technically speaking they still
> > > can't; however, the varstore template serves essentialy the
> > > same purpose.
> > >
> > > The qemuFirmwareGetSupported() helper is used in two places:
> > > one is the code that is responsible for filling in domaincaps,
> > > where templates are ignored so this change has no impact on it;
> > > the other is the qemufirmware test program, where this value
> > > being reported is useful as it will allow us to confirm that
> > > the JSON firmware descriptors for uefi-vars enabled builds are
> > > parsed correctly.
> > >
> > > Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> > > ---
> > >  src/qemu/qemu_firmware.c | 1 +
> > >  1 file changed, 1 insertion(+)
> >
> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>
> Having said that, I'm a bit uncomfortable about the virFirmware
> returned object reporting template for JSON vars without any
> indication that it is is different from the template reported
> for NVRAM vars.
>
> If it is only used in the qemufirmware test that's at least
> safe, but the virFirmware data model is now a trapdoor for the
> unwary....

Yeah, it would probably be good to extend the virFirmware struct so
that it exposes the information in a more semantically meaningful
manner.

Given that I'm trying to get this into the next release and we're
really close to freeze, I'll take the R-b and keep things as they are
for now, but I'll work on that improvement right afterwards.

-- 
Andrea Bolognani / Red Hat / Virtualization