On Mon, Jan 12, 2026 at 06:27:23AM -0700, Andrea Bolognani wrote: > On Wed, Jan 07, 2026 at 12:34:34PM -0600, Andrea Bolognani wrote: > > [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? :) > > Still looking for input on this. I'd like to get started on a respin > sooner rather than later, but I'm not going to dig in until we have > at least some rough consensus on what the XML should look like. > > Here's an alternative take that moves more stuff to the top-level > element, leaving the type='uefi-vars' attribute out on the assumption > that we can always add it later if it ends up being needed due to a > second implementation showing up. > > With template: > > <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader> > <varstore template='/usr/share/edk2/ovmf/OVMF_VARS.qemuvars.json' > path='/path/to/guest.json'/> > > With fine-grained certificate management: > > <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader> > <varstore 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>
I'd suggest we still want the "type" attribute on the <varstore> element, as mandatory, otherwise it looks OK to me as it will avoid the sub-elements in the simple common-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 :|
