On Fri, May 08, 2026 at 01:54:30PM +1000, Nicholas Piggin wrote:
> On Thu, May 07, 2026 at 01:57:02PM -0500, Andrew Jones wrote:
> > On Thu, May 07, 2026 at 02:38:34PM +1000, Nicholas Piggin wrote:
> > > Ascalon supports Svadu (hardware A/D bit updates).
> > >
> > > QEMU makes Svadu and Svade mutually exclusive, remove Svade so
> > > Ascalon comes up with Svadu working.
> >
> > Hi Nicholas,
> >
> > Svadu and Svade aren't mutually exclusive, you can see the expected
> > behaviors for the pair in the commit message of commit 70d22fd92c3b
> > ("target/riscv: Gate hardware A/D PTE bit updating").
>
> Okay misunderstood what QEMU is doing. What does it mean for an
> implementation to support Svadu && !Svade? AFAIKS the spec says ADUE=0
> means the access is performed as though Svade is implemented. I'm either
> wrong about that or miss the point why Svadu && Svade is handled
> differently in the patch you reference (or both).
Your question inspired me to go look at the Svadu chapter again and I
see "If the Svadu extension is implemented, the menvcfg.ADUE field is
writable. If the hypervisor extension is additionally implemented, the
henvcfg.ADUE field is also writable". I think at the time I wrote the
patch I either assumed ADUE could be hardwired 1 (which it clearly cannot)
or I decided to preserve the out-of-spec default behavior that QEMU had
been implementing in order to avoid potential for breaking anything
depending on it.
So the four cases in the commit message of 70d22fd92c3b can be summarized
as follows:
(1) Not spec compliant, because commits 0af3f115e68e and 62108f05e74c
effectively hardwired ADUE to 1, but this is the default QEMU
behavior for a long time. Actually, thinking about it more, I doubt
there is much (any) risk in not supporting this case and instead
defaulting to (2) below.
(2) !svade && svadu - this is fine because ADUE is not hardwired to 1.
This just configures svadu at reset. I think this is allowed by the
spec since the *envcfg registers are unspecified on reset, but this
is not what we expect platforms to do.
(3) svade && !svadu - clearly fine, just the svade-only config
(4) svade && svadu - fine, and what we expect platforms to choose for
their reset.
>
> > Does the
> > Ascalon support Svade? If so, then it's probably best to enable both
> > and leave it to Linux to enable Svadu with SBI FWFT
> > SBI_FWFT_PTE_AD_HW_UPDATING in order to maximize the amount of
> > software supported. But, unfortunately Linux doesn't yet support the
> > checking for and enabling of SBI_FWFT_PTE_AD_HW_UPDATING. We still
> > need kernel patches for that.
>
> Our docs say it supports both. If enabling both bits is the correct
> thing to do we should go with that for upstream.
I'll be happy to review the kernel and qemu patches needed to get all
this wired up properly.
Thanks,
drew
