On Thu, Aug 13, 2026 at 15:22:15 +0100, John Levon wrote: > 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?
IMO it does not. And I don't really want to have another piece of unused code to maintain. If you want to do that anyways for any reason, separate it to another patch that will include also all the other required modifications and checks that will need to be done to integrate it with the code that populates the nvram so that we can separately judge if it makes sense to carry that code. > > > 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. Can you elaborate? The advantage of qcow2 is that it works with the _RESET_NVRAM VM startup flag, since we have code to auto-populate QCOW2 based storage, that will not work with 'raw' _BLOCK storage. > FWIW it was Nutanix who introduced this restriction in the first place, > so this is just correcting a previous patch of ours. That doesn't matter. I've added the code that handles qcow2 based block devices so now if you want to add nvram it needs to work with that too. > > 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? As said I see absolutely no reason to support _FILE. You'll have to come up with a good justification to persuade me. If you want to support 'raw' _BLOCK+slice then that's fine if you don't want to use the IMO much more reasonable qcow2 formatted backend. I don't think we want to support _BLOCK+storageslice+qcow2. You'd have to justify that one separately too. I'd also refuse non-0 offset. I don't think that any sane config would ever need that.
