Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Nov 09, 2022 at 04:26:53PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@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?

Is (C) actually a separate issue ?  I thought it was simply the
result of (B) ?  ie if we skip reading the zero padding, we won't
be dirtying the memory with lots of zeros. we'll have mmap'd the
full 64 MB, but most won't be paged in since we wouldn't write
the zeros to it. Only if the guest writes to those areas do we
need to then flush it back out.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|