From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Sunil V L <sunilvl@ventanamicro.com>,
Peter Maydell <peter.maydell@linaro.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@wdc.com>,
Bin Meng <bin.meng@windriver.com>,
Gerd Hoffmann <kraxel@redhat.com>,
qemu-riscv@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash
Date: Mon, 7 Nov 2022 16:19:10 +0000 [thread overview]
Message-ID: <Y2kv/k5oKGOd+90w@redhat.com> (raw)
In-Reply-To: <871qqehib4.fsf@linaro.org>
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 :|
next prev parent reply other threads:[~2022-11-07 16:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 13:02 [PATCH V2] hw/riscv: virt: Remove size restriction for pflash Sunil V L
2022-11-07 13:06 ` Peter Maydell
2022-11-07 14:08 ` Philippe Mathieu-Daudé
2022-11-07 16:07 ` Markus Armbruster
2022-11-07 14:08 ` Sunil V L
2022-11-07 15:50 ` Alex Bennée
2022-11-07 16:19 ` Daniel P. Berrangé [this message]
2022-11-07 17:32 ` Andrew Jones
2022-11-07 17:34 ` Daniel P. Berrangé
2022-11-08 14:12 ` Philippe Mathieu-Daudé
2022-11-08 14:49 ` Andrew Jones
2022-11-08 15:03 ` Daniel P. Berrangé
2022-11-09 15:26 ` Markus Armbruster
2022-11-09 15:30 ` Daniel P. Berrangé
2022-11-09 15:45 ` Markus Armbruster
2022-11-09 15:51 ` Daniel P. Berrangé
2022-11-07 16:08 ` Peter Maydell
2022-11-08 16:01 ` Markus Armbruster
2022-11-09 10:07 ` Sunil V L
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2kv/k5oKGOd+90w@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=kraxel@redhat.com \
--cc=palmer@dabbelt.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=sunilvl@ventanamicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).