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. Thanks, drew
