On Wed, Mar 19, 2025 at 12:30:34PM +0100, Gerd Hoffmann wrote:
> On Wed, Mar 19, 2025 at 11:07:05AM +0000, Daniel P. Berrangé wrote:
> > On Wed, Mar 19, 2025 at 12:01:51PM +0100, Gerd Hoffmann wrote:
> > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
> > > ---
> > >  docs/interop/firmware.json | 5 ++++-
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json
> > > index 57f55f6c5455..76df1043dae9 100644
> > > --- a/docs/interop/firmware.json
> > > +++ b/docs/interop/firmware.json
> > > @@ -214,13 +214,16 @@
> > >  #                  PL011 UART. @verbose-static is mutually exclusive
> > >  #                  with @verbose-dynamic.
> > >  #
> > > +# @qemu-vars: The firmware expects qemu to provide an efi variable
> > > +#             store, via "uefi-vars-sysbus" or "uefi-vars-x64" device.

I wonder if 'qemu-vars' is the right name here ? It feels like the specification
for such device is effectively defined by UEFI, with any hypervisor providing a
impl. Perhaps just call it 'uefi-vars-dev' or some name that's relevant for
what EDK2 calls it ?

> > 
> > It seems like this would imply mapping.device == memory,
> 
> edk2 doesn't care if you load it into flash or memory, both cases will
> work fine.  Using flash if we don't actually need it makes things more
> complicated for no good reason, so yes, I'd go write config files with
> mapping.device == memory.
> 
> > as if we had
> > mapping.device == flash, then we would need to extend FirmwareFlashMode
> > with an extra option ?
> 
> There is 'stateless' already for 'firmware image in r/o flash'.

What's the behaviour of UEFI if build with JSON vars support, but without
QEMU providing any JSON vars backend ?  If that happily runs stateless
in that case, then we could reuse the existing 'stateless' mode, without
having compat trouble with older libvirt that don't know about the
'qemu-vars' feature.

We would want to expand the 'stateless' docs to mention that this feature
flag indicates optional support for persistence in that case.

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


Reply via email to