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.
