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

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

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.
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.
> 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

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature