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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 10/15/26 10:41 AM, Jan Beulich wrote:
> > > Xen's internal behavior, but I'm unconvinced that it should also lead to
> > > marking extensions as available.
Could we use the probe mechanism solely to verify that the A/D bits 
behavior configured by the firmware matches what is advertised in the DTS?
In other words, rather than automatically setting the corresponding bit 
in riscv_isa here ...

> > Therefore, as far as I understood, you're not convinced of this:
> >
> >      /* Neither advertised: trust the probe. */
> >      __set_bit(has_hw_update ? RISCV_ISA_EXT_svadu : RISCV_ISA_EXT_svade,
> >                riscv_isa);
... based on the probe result when neither extension is advertised, we 
could require riscv,isa to explicitly advertise the appropriate 
extension. If the probe result contradicts what is advertised in the 
DTS, we would fail to boot and print a message asking the user to update 
riscv,isa accordingly.
Then it seems we could cover all the cases we have and potentially will 
have.
Am I missing something?

> > If so, then, the only solution I have in mind in what I proposed in 2)
> > with the global variable that store the result of the real probe.
> > Am I correct?
> Possibly. What I'm missing is some clarification towards the underlying
> principle which we want to follow not just here.
~ Oleksii