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 <[email protected]> > > > --- > > > src/qemu/qemu_firmware.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > Reviewed-by: Daniel P. Berrangé <[email protected]> > > 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
