On Mon, Feb 23, 2026 at 07:30:50PM +0100, Andrea Bolognani via Devel wrote: > This will be used to configure the backing storage used by the > uefi-vars QEMU device. > > Dealing with the element itself is trivial, however we have to > refactor the existing code which deals with the loader and nvram > elements slightly: in particular, we can no longer perform an > early exit if those elements are absent. > > Signed-off-by: Andrea Bolognani <[email protected]> > --- > docs/formatdomain.rst | 23 +++++++-- > docs/kbase/secureboot.rst | 46 +++++++++++------- > src/conf/domain_conf.c | 79 ++++++++++++++++++++++++++++--- > src/conf/domain_conf.h | 9 ++++ > src/conf/schemas/domaincommon.rng | 22 ++++++++- > src/conf/virconftypes.h | 2 + > src/libvirt_private.syms | 2 + > 7 files changed, 156 insertions(+), 27 deletions(-) > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst > index db664857af..7871613017 100644 > --- a/docs/formatdomain.rst > +++ b/docs/formatdomain.rst
> @@ -311,6 +311,23 @@ harddisk, cdrom, network) determining where to > obtain/find the boot image. > It is not valid to provide this element if the loader is marked as > stateless. > > +``varstore`` > + This works much the same way as the ``<nvram/>`` element described above, > + except that variable storage is handled by the ``uefi-vars`` QEMU device > + instead of being backed by a pflash device. :since:`Since 12.1.0 (QEMU > only)` > + > + The ``path`` attribute contains the path of the domain-specific file where > + variables are stored, while the ``template`` attribute points to a > template > + that the domain-specific file can be (re)generated from. Assuming that the > + necessary JSON firmware descriptor files are present, both attributes will > + be filled in automatically by libvirt. > + > + Using ``<varstore/>`` instead of ``<nvram/>`` is particularly useful on > + non-x86 architectures such as aarch64, where it represent the only way to s/represent/represents/ > + get Secure Boot working. It can be used on x86 too, and doing so will make > + it possible to keep UEFI authenticated variables safe from tampering > without > + requiring the use of SMM emulation. > + > ``boot`` > The ``dev`` attribute takes one of the values "fd", "hd", "cdrom" or > "network" and is used to specify the next boot device to consider. The Reviewed-by: Daniel P. Berrangé <[email protected]> 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 :|
