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 <suni...@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 <suni...@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 <suni...@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
