Re: [PATCH 2/2] docs/interop/firmware: Introduce extended syntax for FirmwareMappingMemory

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Jan 06, 2026 at 11:13:33AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > IMHO we could add merely a new "uefi-vars-service" such that it looks
> > like this:
> > 
> >      {
> >          "mapping: {
> >              "device": "memory",
> >              "filename": "/path/to/firmware.bin",
> > 	     "uefi-vars-service": {
> > 	       "template": "/path/to/firmware.json",
> > 	     }
> >          }
> >      }
> 
> I'm wondering whenever it makes sense to put this into the firmware
> description at all?  The reason this is done for flash images is that
> code and vars can not be matched freely.  This is simply not the case
> with host-managed variable stores.

True, though our schema of course allows us to list the exact same
json file against multiple firmware binaries. The more significant
problem is probably in the opposite direction - there are can
arbitrarily many json vars files that are valid for use with any
single firmware binary. This would require us to have multiple
firmware descriptors pointing to the same binary, each with a
differnt json file. Essentially the descriptors need to define
the combinatorial expansion of firmware + json files, and this
feels like it is getting a bit silly.

> Maybe have separate json files describing the variable store template
> only, and expect libvirt searching for one in case the firmware
> descriptor has the 'host-uefi-vars' feature flag set?

Or just have the host-uefi-vars feature flag alone, and then libvirt
can just invoke virt-firmware in whatever way it needs to create the
json templates and not worry about providing any pre-defined json
files.  All the default microsoft CAs are ultimately embedded in
virt-firmware and spat out when given the right args.

If libvirt doesn't want to run  virt-firmware every time, libvirt
could cache some common templates itself.

> Many fields of the firmware descriptor format continue to make sense
> in that case.  Description obviously.  Architecture too (the dbx
> revocation list is arch specific, so x86 / arm need different
> templates).  Also some features, specifically 'enrolled-keys'.
> 
> For the template filename we could use mapping->device = 'hostvars' with
> mapping->filenname (somewhat quirky), or simply replace mapping with
> something else.
> 
> I think this also fits better with the long-term plan that libvirt can
> generate distro-specific variable stores based on libosinfo information
> instead of using some template file.

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