Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none"

[Andrea Bolognani]

On Wed, May 17, 2023 at 02:47:42PM +0200, Philippe Mathieu-Daudé wrote:
> > > On Mon, May 08, 2023 at 07:37:23AM +0200, Heinrich Schuchardt wrote:
> > > > On amd64 and arm64 unit=0 is used for code and unit=1 is used for 
> > > > variables.
> > > > Shouldn't riscv64 do the same?
> >
> > Good catch, I had missed that!
>
> This is a design mistake spreading.
>
> What EDK2 maintainers want is one Read-Only + Exec region for CODE and
> one Read-Write + NoExec region for VARS.
>
> QEMU never implemented correctly pflash bank (multiple sectors) write
> protected.

Does setting -drive if=pflash,unit=0,readonly=on not do the trick?

> When EDK2 (x86, OVMF) was tried on QEMU, QEMU was using a single pflash.
> To separate CODE/VARS, a second pflash was added, the first one being
> "locked" into Read-Only mode. Using a pflash allowed the firmware to
> identify device size using pflash CFI commands.
>
> Then this design was copied to the ARM virt board for EDK2 needs.
>
> In retrospective, this design was declared a mistake, since a simple
> ROM region for the CODE is sufficient, and much simpler [*].
>
> Thankfully the Loongarch64 virt machine started cleanly avoiding the
> previous design flaw. It provides a ROM for CODE and pflash for VARS.

Based on the documentation both in QEMU and edk2, it looks like a
single file is used? I haven't seen an example where the pflash is
used to provide a R/W area for VARS.

Note that the current version of the firmware.json standard doesn't
include a way to describe builds that have to be consumed by loading
the CODE via -bios and the VARS via pflash.

This is likely an artifact of codifying existing usage (x86/arm) and
could probably be fixed, but the point remains that there is
currently no way to represent such a build in a way that makes it
possible for consumers such as libvirt to automatically pick it up.

> [*] Having 2 distinct pflash is useful for non-virt machines where the
>     firmware might want to (re)program the CODE region, in the "capsule
>     update" scenario. This scenario is irrelevant for virt machines,
>     since a guest will never update its CODE. CODE is updated by the
>     host.

Yeah, this makes sense.

But I don't understand what's wrong with using a R/O pflash for CODE
as opposed to -bios? What makes that approach so problematic? You're
still going to need to use pflash for VARS anyway...

-- 
Andrea Bolognani / Red Hat / Virtualization