Daniel P. Berrangé <berra...@redhat.com> writes:
> On Mon, Nov 07, 2022 at 06:32:01PM +0100, Andrew Jones wrote:
[...]
>> Padding is a good idea, but too much causes other problems. When building
>> lightweight VMs which may pull the firmware image from a network,
>> AArch64 VMs require 64MB of mostly zeros to be transferred first, which
>> can become a substantial amount of the overall boot time[*]. Being able to
>> create images smaller than the total flash device size, but still add some
>> pad for later growth, seems like the happy-medium to shoot for.
>
> QEMU configures the firmware using -blockdev,
Yes, even though the devices in question are not block devices.
> so can use any file
> format that QEMU supports at the block layer. IOW, you can store
> the firmware in a qcow2 file and thus you will never fetch any
> of the padding zeros to be transferred. That said I'm not sure
> that libvirt supports anything other than a raw file today.
Here's another idea. The "raw" format supports exposing a slice of the
underlying block node (options @offset and @size). It could support
padding. Writing to the padding should then grow the underlying node.
Taking a step back to look at the bigger picture... there are three
issues, I think:
(A) Storing padding on disk is wasteful.
Use a file system that supports sparse files, or an image format
that can represent the padding efficiently.
(B) Reading padding into memory is wasteful.
Matters mostly when a network is involved. Use an image format that
can represent the padding efficiently.
(C) Dirtying memory for padding is wasteful.
I figure KSM could turn zero-padding into holes.
We could play with mmap() & friends.
Other ideas?
Any solution needs to work both for read-only and read/write padding.
Throwing away data written to the padding on cold restart is not what
I'd regard as "works".
