[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-b
From: |
Andrea Bolognani |
Subject: |
Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none" |
Date: |
Thu, 18 May 2023 08:34:47 -0700 |
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
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", (continued)
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", Sunil V L, 2023/05/17
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", Philippe Mathieu-Daudé, 2023/05/17
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", Alistair Francis, 2023/05/18
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", Sunil V L, 2023/05/18
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", Philippe Mathieu-Daudé, 2023/05/19
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", Philippe Mathieu-Daudé, 2023/05/19
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", Andrea Bolognani, 2023/05/23
- Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none",
Andrea Bolognani <=
Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none", Andrea Bolognani, 2023/05/19