On Thu, Aug 13, 2026 at 04:09:00PM +0200, Peter Krempa wrote: > 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.
I can correct the explanation so that it mentions offset instead for files, as that still seems useful even for file backend? > > 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. Yes, I'm aware of that, it's not a good fit for the way we manage this storage for a few reasons. FWIW it was Nutanix who introduced this restriction in the first place, so this is just correcting a previous patch of ours. > 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. Thanks, good spot, before I prepare one, would you accept a patch that does this? Allows the slice for file+block but only if qcow2 is not configured? regards john
