Re: [PATCH v6 1/4] xen/riscv: probe the PTE A/D bits update scheme at boot

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.10.2026 14:54, Baptiste Le Duc wrote:
> 
> 
> On 10/16/26 2:51 PM, Jan Beulich wrote:
>> On 16.10.2026 13:35, Baptiste Le Duc wrote:
>>> On 2026-10-15 18:04 +0200, Jan Beulich wrote:
>>> Based on Andrew's answer to your question on GitHub [1], I see two options
>>> for handling a DT that doesn't advertise the scheme in effect. Please
>>> feel free to choose one.
>>>
>>> 1) Trust the probe and fix up riscv_isa on a mismatch. This avoids having
>>> people edit their DTs, and is safe as, per Andrew, the spec has only ever
>>> allowed these two schemes:
>>>
>>> /*
>>>   * The privileged spec allows exactly two schemes for the PTE A and D bits:
>>>   *  1) hardware sets them on access and on write.
>>>   *  2) accessing a page whose A and/or D bit is clear raises a page fault,
>>>   *     so that software can set them (ratified as Svade).
>>>   *
>>>   * Hence an implementation without Svade uses the hardware scheme (1), and 
>>> one
>>>   * that faults on clear A/D bits implements Svade, whether or not it says 
>>> so.
>>>   *
>>>   * Rather than trusting the DTS alone, probe the scheme in effect with a 
>>> write
>>>   * through a PTE whose A and D bits are clear. If the DTS does not 
>>> advertise
>>>   * it, replace it by the probed scheme. As the spec has only ever allowed
>>>   * these two schemes, this is safe even on implementations that predate 
>>> Svade
>>>   * and Svadu.
>>>   */
>>> static void __init check_ad_scheme(void)
>>> {
>>>      bool has_hw_scheme = probe_hw_ad_update();
>>>      const char *scheme_name = has_hw_scheme ? "Svadu" : "Svade";
>>>      enum riscv_isa_ext_id ext = has_hw_scheme ? RISCV_ISA_EXT_svadu
>>>                                                : RISCV_ISA_EXT_svade;
>>>
>>>      /* Fix DTS in case of mismatch */
>>>      if ( !riscv_isa_extension_available(NULL, ext) )
>>>      {
>>>          printk(XENLOG_WARNING
>>>                 "CPU implements %s but the DTS does not advertise it\n",
>>>                 scheme_name);
>>>          __clear_bit(RISCV_ISA_EXT_svade, riscv_isa);
>>>          __clear_bit(RISCV_ISA_EXT_svadu, riscv_isa);
>>>          __set_bit(ext, riscv_isa);
>>>      }
>>>
>>>      printk(XENLOG_DEBUG "CPU is using %s A/D bits scheme\n", scheme_name);
>>> }
>>
>> Yes, if the assumption is that this would be used only when neither extension
>> is advertised, then I agree (taking Andrew's response into account). I'm 
>> sorry,
>> this has been quite a bit of back and forth, but hopefully we're now all on 
>> the
>> same page.
> Ok thanks, great to hear. Just to not mistaken, when you said "would be 
> used only when neither extension is advertised" it would means that in 
> other cases where there would be a mismatch between what the DTS 
> advertised and what the CPU actually support we should panic?

No, what I meant was that likely we shouldn't even probe there. We don't probe
other extensions; I don't see why we shouldn't trust DT here. The outlier is
when DT lacks any information.

Jan