qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH] pflash: Only read non-zero parts o


From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH] pflash: Only read non-zero parts of backend image
Date: Tue, 07 May 2019 20:01:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

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 <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]