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.