Re: [PATCH] hw/riscv: virt: Enable booting M-mode or S-mode FW from pflash0

[Philippe Mathieu-Daudé]

On 21/4/23 18:48, Andrea Bolognani wrote:
> On Fri, Apr 21, 2023 at 04:36:15PM +0200, Heinrich Schuchardt wrote:
> > On 4/21/23 06:33, Sunil V L wrote:
> > > Currently, virt machine supports two pflash instances each with
> > > 32MB size. However, the first pflash is always assumed to
> > > contain M-mode firmware and reset vector is set to this if
> > > enabled. Hence, for S-mode payloads like EDK2, only one pflash
> > > instance is available for use. This means both code and NV variables
> > > of EDK2 will need to use the same pflash.
> > >
> > > The OS distros keep the EDK2 FW code as readonly. When non-volatile
> > > variables also need to share the same pflash, it is not possible
> > > to keep it as readonly since variables need write access.
> > >
> > > To resolve this issue, the code and NV variables need to be separated.
> > > But in that case we need an extra flash. Hence, modify the convention
> > > such that pflash0 will contain the M-mode FW only when "-bios none"
> > > option is used. Otherwise, pflash0 will contain the S-mode payload FW.
> > > This enables both pflash instances available for EDK2 use.
> > >
> > > Example usage:
> > > 1) pflash0 containing M-mode FW
> > > qemu-system-riscv64 -bios none -pflash <mmode_fw> -machine virt
> > > or
> > > qemu-system-riscv64 -bios none \
> > > -drive file=<mmode_fw>,if=pflash,format=raw,unit=0 -machine virt
> > >
> > > 2) pflash0 containing S-mode payload like EDK2
> > > qemu-system-riscv64 -pflash <smode_fw_code> -pflash <smode_vars> -machine  virt
> > > or
> > > qemu-system-riscv64 -bios <opensbi_fw> \
> > > -pflash <smode_fw_code> \
> > > -pflash <smode_vars> \
> > > -machine  virt
> > > or
> > > qemu-system-riscv64 -bios <opensbi_fw> \
> > > -drive file=<smode_fw_code>,if=pflash,format=raw,unit=0,readonly=on \
> > > -drive file=<smode_fw_vars>,if=pflash,format=raw,unit=1 \
> > > -machine virt
> > >
> > > Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
> > > Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >
> > QEMU 7.2 (and possibly 8.0 to be released) contains the old behavior.
> >
> > Changed use of command line parameters should depend on the version of
> > the virt machine, i.e. virt-7.2 should use the old behavior and virt as
> > alias for virt-8.0 should use the new behavior. Please, have a look at
> > the option handling in hw/arm/virt.c and macro DEFINE_VIRT_MACHINE().
>
> I would normally agree with you, but note that RISC-V doesn't have
> versioned machine types yet, so this kind of breakage is not
> necessarily unexpected.
>
>  From libvirt's point of view, being able to detect whether the new
> behavior is implemented by looking for some machine type property
> would be enough to handle the transition smoothly. That would of
> course not help people running QEMU directly.
>
> For what it's worth, this change seems to go in the right direction
> by making things similar to other architectures (x86, Arm) so I'd
> love to see it happen.

Unfortunately another arch that followed the bad example of using
a R/W device for the CODE region and not a simple ROM.