qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P . Berrangé
Subject: Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash
Date: Mon, 7 Nov 2022 16:19:10 +0000
User-agent: Mutt/2.2.7 (2022-08-07)

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]