On 5/19/25 9:07 AM, Björn Töpel wrote:
Alexandre Ghiti <alexgh...@rivosinc.com> writes:

The satp mode is set using the svXX properties, but that actually
restricts the satp mode to the minimum required by the profile and
prevents the use of higher satp modes.

Fix this by not setting any svXX property and allow all satp mode to be
supported.

I figured I'll add some more findings.

The RISC-V profile initialization seems a bit brittle; Without Alex' fix
we're getting different supported satp on the first hart (0) than the
other harts; Hart 0 has sv57, whereas the other harts has enforced sv39.
This caused the smp bringup on Linux to fail.

Some observations on, e.g., a
"rv64,b=on,zbc=off,v=true,vlen=256,elen=64,sscofpmf=on,svade=on,svinval=on,svnapot=on,svpbmt=on,zcb=on,zcmop=on,zfhmin=on,zicond=on,zimop=on,zkt=on,zvbb=on,zvfhmin=on,zvkt=on,zkr=on"
8 hart machine:

When realizing the cpus, the first cpu calls riscv_cpu_add_profiles()
all profiles are disabled, whereas for the other cpu calls to
riscv_cpu_add_profiles() have some profiles enabled. Having some
profiles enabled, will issue a call to cpu_set_profile() that will
enforce the satp code that Alex removes in this patch.

The riscv_cpu_validate_profile() function is called after
riscv_cpu_add_profiles(), which explains why the harts subsequent the
first one will get the cpu_set_profile() call. The first hart will not
have cpu_set_profile() called.

IOW, there are more issues hiding here, in addition to Alex' fix.

There is. I'll send a fix shortly. Thanks for letting us know!


Daniel



Björn


Reply via email to