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

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

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.