On Mon, Nov 07, 2022 at 06:32:01PM +0100, Andrew Jones wrote: > 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 <[email protected]> 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 <[email protected]> > > > >> 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 <[email protected]> > > > >> > --- > > > >> > > > >> 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.
QEMU configures the firmware using -blockdev, 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. 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 :|
