Re: [PATCH v5 1/3] xen/riscv: always preset A/D bits in G-stage PTEs

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 10/7/26 1:59 PM, Teddy Astie wrote:
> Le 07/10/2026 à 13:35, Oleksii Kurochko a écrit :
> > Also I am looking at henvcfg register which we could access in HS-mode 
> > and it also has ADUE bit and the description for it is the following:
> > ```
> > If the Svadu extension is implemented, the ADUE bit controls whether 
> > hardware updating of PTE A/D bits is enabled for VS-stage address 
> > translation. When ADUE=1, hardware updating of PTE A/D bits is enabled 
> > during VS-stage address translation, and the implementation behaves as 
> > though the Svade extension were not implemented for VS-mode address 
> > translation. When ADUE=0, the implementation behaves as though Svade 
> > were implemented for VS-stage address translation. If Svadu is not 
> > implemented, ADUE is read-only zero
> > ```
> >
> > So, at some point, we could verify how OpenSBI configured the hardware 
> > and compare it with what is specified in the DTS file.
> > The only problem is how to interpret this part: “If Svadu is not 
> > implemented, ADUE is read-only zero.” The spec does not explicitly 
> > state that Svade will be used in this case, but logically, it seems 
> > that if Svadu is not implemented, the implementation has no other 
> > choice but to provide Svade and so basically we could detect if Svade 
> > is used based only on ADUE bit.
> To my understanding, when !Svade && !Svadu ADUE bit doesn't exist and is 
> MBZ. That doesn't imply Svade semantics must be unconditionally applied, 
> but the contrary (otherwise, it would contradict the main spec).
> AIUI, Svadu && !Svade behaves the same as Svadu && Svade, as in this 
> case, ADUE mandate the PTE A/D scheme that is effective.
> If by default ADUE is 0, then we have Svade semantics by default in 
> practice, but that can (*maybe*) be opted-out.
At least, in my version of RISC-V privilige spec (Version 20240411) ADUE 
bit always exists. It could be read-only zero, yes (in the case when 
Svadu isn't implemented) and in this case according to the spec Svade 
will be default behavior:
```
The Svade extension requires page-fault exceptions be raised when PTE 
A/D bits need be set, hence Svade is implemented when ADUE=0.
```

Hence based on the spec version I mentioned at least something from 
Svade and/or Svadu should be implemented.
> It could be interesting to check if the P550 has Svadu && !Svade, as it 
> may explain why Svade semantics are effective while not having Svade 
> extension.
p550 basically follows Svade behavior. The open question could also be 
if (in that *old non-ratified* H extension which p550 decides to 
implement) it supports henvcfg and hencfg.ADUE bit.
But I am not sure that we should care about it now as it is mentioned 
somewhere in cover letter that p550 support won't be upstreamed at least 
for now because of some other difficulties.
I think we should back to this question when we really will decide to 
return back to full p550 support in upstream. For now, for other boards 
it will be enough what was mentioned above.
~ Oleksii

> > If we accept this assumption, we could fully verify, in HS-mode, both 
> > what is specified in the DTS and how OpenSBI configured the hardware. 
> > This would allow us to require users to provide a proper DTS with the 
> > A/ D bits update scheme correctly specified.
> > ~ Oleksii
> Teddy