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