Re: [PATCH v10 1/1] xen/riscv: probe the A/D update scheme if the DT advertises neither

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 10/28/26 2:05 PM, Baptiste Le Duc wrote:
> p2m_set_pte_flags() presets the A/D bits of G-stage PTEs only when
> RISCV_ISA_EXT_svade is set, which is correct only if the device tree is.
>
> The privileged spec allows exactly two schemes for updating the PTE A and D
> bits: hardware sets them on access and on write, or accessing a page whose
> A and/or D bit is clear raises a page fault so that software can set them
> (ratified as Svade). Every implementation uses one of them, but platforms
> designed before Svade and Svadu were ratified, such as the HiFive Premier
> P550, may advertise neither.
>
> Trust the device tree when it advertises Svade and/or Svadu, as for any
> other extension. When it advertises neither, probe the scheme in effect
> and record the matching extension in riscv_isa, so that such device trees
> can be used as-is, and warn naming the extension to add to "riscv,isa".
>
> Introduce probe_hw_ad_update(): alias the first page of the Xen image
> read-only through the FIX_MISC fixmap slot with its A and D bits clear,
> then load from it under an exception table fixup. Hardware updating is in
> effect if the load completes and the A bit is then set. The probe fails
> otherwise, whether the load faults or completes leaving the A bit clear.
> The A bit being set by a speculative access still implies Svadu, as Svade
> only allows A to be set by software.
>
> Add Svadu to the known ISA extensions so it can be told apart from Svade.
> The comment above the enum asks for new extensions to go at the bottom to
> avoid shuffling, a leftover from Linux where the IDs were macros with
> explicit values. Nothing depends on the enum values, so have the comment
> say that multi-letter extensions follow the order of riscv_isa_ext[].
>
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>
> ---
> Changes since v9:
Nit: something wrong with version numbering. (in the case of v11 would 
be nice to fix).
Changes itself LGTM:

Reviewed-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

Thanks!

~ Oleksii