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

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

On Wed, Nov 09, 2022 at 04:45:18PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > 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.
> 
> I expressed myself poorly.  All three are related, but there's still a
> distinction between each of them in my thinking.
> 
> Say we use an image format that compresses data.  Represents the padding
> efficiently.  Storage on disk is efficient (A), and so is reading it
> (B).  Trouble is decompressing it to memory dirties the memory unless we
> take care not to write all-zero pages (C).
> 
> Clearer now?

Ok yeah, so reading can be efficient, but if the reader doesn't pay
attention to where the holes are, it'll dirty memory anyway.

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 :|