The subject is slightly misleading. Holes read as zero. So do
non-holes full of zeroes. The patch avoids reading the former, but
still reads the latter.
Xiang Zheng <zhengxia...@huawei.com> writes:
> Currently we fill the memory space with two 64MB NOR images when
> using persistent UEFI variables on virt board. Actually we only use
> a very small(non-zero) part of the memory while the rest significant
> large(zero) part of memory is wasted.
Neglects to mention that the "virt board" is ARM.
> So this patch checks the block status and only writes the non-zero part
> into memory. This requires pflash devices to use sparse files for
> backends.
I started to draft an improved commit message, but then I realized this
patch can't work.
The pflash_cfi01 device allocates its device memory like this:
memory_region_init_rom_device(
&pfl->mem, OBJECT(dev),
&pflash_cfi01_ops,
pfl,
pfl->name, total_len, &local_err);
pflash_cfi02 is similar.
memory_region_init_rom_device() calls
memory_region_init_rom_device_nomigrate() calls qemu_ram_alloc() calls
qemu_ram_alloc_internal() calls g_malloc0(). Thus, all the device
memory gets written to even with this patch.
I'm afraid you neglected to test.
I still believe this approach can be made to work. Need a replacement
for memory_region_init_rom_device() that uses mmap() with MAP_ANONYMOUS.
