Re: [External] Re: [PATCH v1 0/7] riscv: add Svnapot-based contiguous PTE support

Hi David,

On Tue, Apr 21, 2026 at 7:28=E2=80=AFPM David Hildenbrand (Arm)
<[email protected]> wrote:
>
> On 4/21/26 11:24, Yunhui Cui wrote:
> > Hi,
> >
> > First of all, thanks to Ryan Roberts for the work on mTHP and
> > Contiguous PTE support on arm64. That work provides a very useful
> > reference for reducing page fault overhead and TLB pressure for
> > large but still PTE-mapped memory ranges.
> >
> > This series adds Svnapot-based contiguous PTE support for RISC-V.
> >
> > To achieve similar benefits on RISC-V, this series introduces a
> > Contiguous-PTE-like mechanism built on top of the Svnapot extension.
> > The intent is to preserve the core-MM PTE semantics while allowing
> > RISC-V to transparently fold eligible base-page mappings into
> > Svnapot-encoded contiguous mappings when possible.
> >
> > The series splits the low-level raw PTE helpers from the public
> > core-MM-facing PTE helpers, so that:
> >
> > -the __xxx helpers expose the raw hardware PTE encoding,
> > -the xxx helpers provide the semantic view expected by core MM,
> > -and Svnapot-aware handling is centralized in the public wrapper layer.
>
>
> Just curious, is there opportunity to share some of the code with arm64,
> factoring out helpers that handle something like
> CONFIG_ARCH_HAS_CONTIG_PTES ?

arm64 contpte and RISC-V Svnapot look similar at a high level, but they
do not model contiguous mappings in the same way. arm64 keeps ordinary
base PTEs and adds PTE_CONT, while Svnapot encodes a naturally aligned
range directly in the PTEs. Because of that, this series exposes a
logical per-page sub-PTE view to generic MM, while keeping the raw
Svnapot encoding underneath.

So the differences are not only in the low-level encoding, but also in
the public PTE semantics and in some of the fold/unfold and TLB rules.

>
>
> --
> Cheers,
>
> David

Thanks,
Yunhui