On 28 Jun 2024, at 17:19, Conor Dooley <conor@xxxxxxxxxx> wrote: > > On Fri, Jun 28, 2024 at 05:37:06PM +0800, Yong-Xuan Wang wrote: >> Add entries for the Svade and Svadu extensions to the riscv,isa-extensions >> property. >> >> Signed-off-by: Yong-Xuan Wang <yongxuan.wang@xxxxxxxxxx> >> --- >> .../devicetree/bindings/riscv/extensions.yaml | 28 +++++++++++++++++++ >> 1 file changed, 28 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml >> index 468c646247aa..c3d053ce7783 100644 >> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml >> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml >> @@ -153,6 +153,34 @@ properties: >> ratified at commit 3f9ed34 ("Add ability to manually trigger >> workflow. (#2)") of riscv-time-compare. >> >> + - const: svade >> + description: | >> + The standard Svade supervisor-level extension for SW-managed PTE A/D >> + bit updates as ratified in the 20240213 version of the privileged >> + ISA specification. >> + >> + Both Svade and Svadu extensions control the hardware behavior when >> + the PTE A/D bits need to be set. The default behavior for the four >> + possible combinations of these extensions in the device tree are: >> + 1) Neither Svade nor Svadu present in DT => > >> It is technically >> + unknown whether the platform uses Svade or Svadu. Supervisor may >> + assume Svade to be present and enabled or it can discover based >> + on mvendorid, marchid, and mimpid. > > I would just write "for backwards compatibility, if neither Svade nor > Svadu appear in the devicetree the supervisor may assume Svade to be > present and enabled". If there are systems that this behaviour causes > problems for, we can deal with them iff they appear. I don't think > looking at m*id would be sufficient here anyway, since the firmware can > have an impact. I'd just drop that part entirely. Older QEMU falls into that category, as do Bluespec’s soft-cores (which ours are derived from at Cambridge). I feel that, in reality, one should be prepared to handle both trapping and atomic updates if writing an OS that aims to support case 1. Jess