在 2026-06-05五的 23:33 -0300，Daniel Henrique Barboza写道： > > > 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 think we can just make RVSP a profile, and rvsp-ref CPU a BARE CPU based on that profile; then set the profile's min SATP to Sv48, and the BARE CPU's max SATP to Sv57. In this case if any other CPU complying to RVSP is added, it can just reuse the profile. Thanks, Icenowy > > > I'll make changes and see how it goes. Cheers, > > Daniel > > > > > Thanks, > > drew
