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

[Andrew Jones]

On Mon, Nov 07, 2022 at 04:19:10PM +0000, Daniel P. Berrangé wrote:
> On Mon, Nov 07, 2022 at 03:50:44PM +0000, Alex Bennée wrote:
> > 
> > Sunil V L <sunilvl@ventanamicro.com> writes:
> > 
> > > On Mon, Nov 07, 2022 at 01:06:38PM +0000, Peter Maydell wrote:
> > >> On Mon, 7 Nov 2022 at 13:03, Sunil V L <sunilvl@ventanamicro.com> wrote:
> > >> >
> > >> > The pflash implementation currently assumes fixed size of the
> > >> > backend storage. Due to this, the backend storage file needs to be
> > >> > exactly of size 32M. Otherwise, there will be an error like below.
> > >> >
> > >> > "device requires 33554432 bytes, block backend provides 4194304 bytes"
> > >> >
> > >> > Fix this issue by using the actual size of the backing store.
> > >> >
> > >> > Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
> > >> > ---
> > >> 
> > >> Do you really want the flash device size presented to the guest
> > >> to be variable depending on what the user passed as a block backend?
> > >> I don't think this is how we handle flash devices on other boards...
> > >> 
> > >
> > > Hi Peter,
> > >
> > > x86 appears to support variable flash but arm doesn't. What is
> > > the reason for not supporting variable size flash in arm?
> > 
> > If I recall from the last time we went around this is was the question
> > of what you should pad it with.
> 
> Padding is a very good thing from the POV of upgrades. Firmware has shown
> a tendancy to change (grow) over time, and the size has an impact of the
> guest ABI/live migration state.
> 
> To be able to live migrate, or save/restore to/from files, then the machine
> firmware size needs to be sufficient to cope with future size changes of
> the firmware. The best way to deal with this is to not use the firmware
> binaries' minimum compiled size, but instead to pad it upto a higher
> boundary.
> 
> Enforcing such padding is a decent way to prevent users from inadvertantly
> painting themselves into a corner with a very specific firmware binary
> size at initial boot.

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.

[*] My web searching skills are failing me at the moment, but I recall
seeing a BZ or gitlab/github issue specifically pointing out the AArch64
64MB firmware size as a pain point.

Thanks,
drew