On 6/5/2026 7:24 PM, Andrew Jones wrote:
On Fri, Jun 05, 2026 at 05:48:18PM -0300, Daniel Henrique Barboza wrote:
...
You're correct. We're not initializing satp_mode to max_satp_mode, so the
default value is being set to sv39. This seems to be the case for all
CPUs, not just this one. For some reason I thought we were defaulting
to the max_satp_mode. I need to understand why sv39 is being set as
default (i.e. why not BARE?).
Got an update. It turns out that what we're seeing is something that is
only happening to this CPU we're trying to add.
The way satp mode is set on QEMU assuming no command line input:
- "Bare" CPUs, aka CPUs that has just I or E enabled: default to BARE;
- Profile CPUs: default to the minimum required by the spec. E.g. for
RVA23 the default is set to sv39;
- all other CPUs: default to satp_mode_max from the CPU definition.
The riscv-server-ref CPU is a BARE CPU that is using the profile framework
to enable extensions. So for all intents and purposes the code is treating
it as a profile CPU with extra stuff. Which is good, but then the
satp setting from RVA23 (sv39) is overwriting satp_mode_max from the
CPU definition.
I believe the way we're creating riscv-server-ref here is correct, so what
I'm going to do is send a couple of fixes to allow riscv-server-ref to use
RVA23 as a base and honor its satp_mode_max value too.
But setting satp_mode_max to sv48 is not correct if that really means
_max_ since we want the reference platform to default to the minimum
(sv48) but also support the supported optional extensions and sv57 is
a supported optional extension.
QEMU only works this way for profile CPUs.
For non-profile CPUs: cpu.max_satp_mode is set internally as part of
the CPU definition. This is the maximum satp value that the CPU allows
users to set via cmd line. If the user does not provide a satp mode
then we'll do curr_satp_mode = max_satp_mode.
E.g. the thead vendor CPU defines .cfg.max_satp_mode = VM_1_10_SV39.
In the command line we can't set anything higher than that:
$ ./build/qemu-system-riscv64 -M virt -cpu thead-c906,sv57=on
qemu-system-riscv64: satp_mode sv57 is higher than hw max capability sv39
For profile CPUs things are different: they are bare_cpu types, which are
initialized with max_satp_mode sv57, and then during profile init we
set the current satp_mode (current, not max_satp_mode) to the minimum
the profile requires. Thus the rva23s64 CPU, by default, starts with
sv39 but it can go up to sv57.
From what I'm understanding we want the riscv-server-ref CPU to work
like profile CPUs. In fact I believe we can make it official by
adding a 'default_satp_mode' setting in the CPU definition and allowing
all CPUs to define a default satp and a max satp. CPUs defs that don't
set a default mode will keep working as today (default_satp_mode ==
max_satp_mode
if no user input).
I'll make changes and see how it goes. Cheers,
Daniel
Thanks,
drew
