On Tue, Aug 11, 2026 at 13:58:07 +0100, John Levon wrote: > For NVRAM storage specifically, the guest-visible size is critical to > correct handling of the OVMF address space. Allow specifying storage > slices for NVRAM storage when the underlying file/block may be larger
This explanation doesn't make sense for the 'file' backed NVRAM because file size can be arbitrary. > due to alignment/allocation restrictions. For block devices we support 'qcow2' formatted nvram block device for this reason so that the size can be embedded. Have you considered using that configuration? The advantage is that libvirt supports auto-population of the block device from the template. With 'raw'+slice you'll have to populate the nvram yourself. > Signed-off-by: John Levon <[email protected]> > Reviewed-by: Mark Cave-Ayland <[email protected]> > --- > src/qemu/qemu_validate.c | 13 +++--- > ...ual-efi-nvram-dev-slice.x86_64-latest.args | 35 ++++++++++++++++ > ...nual-efi-nvram-dev-slice.x86_64-latest.xml | 42 +++++++++++++++++++ > .../firmware-manual-efi-nvram-dev-slice.xml | 25 +++++++++++ > tests/qemuxmlconftest.c | 1 + > 5 files changed, 110 insertions(+), 6 deletions(-) > create mode 100644 > tests/qemuxmlconfdata/firmware-manual-efi-nvram-dev-slice.x86_64-latest.args > create mode 100644 > tests/qemuxmlconfdata/firmware-manual-efi-nvram-dev-slice.x86_64-latest.xml > create mode 100644 > tests/qemuxmlconfdata/firmware-manual-efi-nvram-dev-slice.xml > > diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c > index 61f3bd3278..113a711390 100644 > --- a/src/qemu/qemu_validate.c > +++ b/src/qemu/qemu_validate.c > @@ -708,7 +708,14 @@ qemuValidateDomainDefNvram(const virDomainDef *def, > switch (src->type) { > case VIR_STORAGE_TYPE_FILE: > case VIR_STORAGE_TYPE_BLOCK: > + break; As said above I don't see a reason to do this for _FILE as file can be of arbitrary size. It'd also complicate things because `qemuPrepareNVRAMFileCommon` would not comply with the sected size when the image is autopopulated. For _BLOCK this patch is incomplete. Theoretically use of a storage slice still allows the qcow2 image format to be present. The code in `qemuPrepareNVRAMBlock` tries to probe the qcow2 format in the block device to see if it needs to be populated. That will not work with a storage slice (if e.g. offset is populated). So either `qemuPrepareNVRAMBlock` needs to have an exception if a slice is present or the slice needs to be refused for qcow2 ... or rather allowed only for 'raw' nvram block device. I still suggest using qcow2 in the block device instead. > + > case VIR_STORAGE_TYPE_NETWORK: > + if (src->sliceStorage) { > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", > + _("slices are not supported with network-backed > NVRAM")); > + return -1; > + } > break; > > case VIR_STORAGE_TYPE_DIR:
