[PATCH v1 0/4] riscv: mm: add Svnapot support

[Palmer Dabbelt]

On Mon, 11 Apr 2022 07:15:32 PDT (-0700), panqinglin2020 at iscas.ac.cn wrote:
> From: Qinglin Pan <panqinglin2020 at iscas.ac.cn>
>
> Svnapot is a RISC-V extension for marking contiguous 4K pages as a non-4K
> page. This patch set is for using Svnapot in Linux Kernel's boot process
> and hugetlb fs.
>
> Since Svnapot is just stable recently, and there seems no official way to
> determine if the CPU supports Svnapot at runtime. This patchset adds a Kconfig
> item for using Svnapot in "Platform type"->"Svnapot support". Its default value
> is off, and people can set it on when their CPU supports Svnapot.
>
> Qemu support for Svnapot has been accepted but still not merged into master.
> So the qemu which we use to test this patchset is current in this repo (it
> contains qemu Svnapot patchset):
> https://github.com/plctlab/plct-qemu/tree/plct-virtmem-dev
>
> Tested on:
>   - qemu rv64 with "Svnapot support" off.
>   - plct-qemu rv64 with "Svnapot support" on.
>
>
> Qinglin Pan (4):
>   mm: modify pte format for Svnapot
>   mm: support Svnapot in physical page linear-mapping
>   mm: support Svnapot in hugetlb page
>   mm: support Svnapot in huge vmap
>
>  arch/riscv/Kconfig                    |  10 +-
>  arch/riscv/include/asm/hugetlb.h      |  31 +++-
>  arch/riscv/include/asm/page.h         |   2 +-
>  arch/riscv/include/asm/pgtable-bits.h |  31 ++++
>  arch/riscv/include/asm/pgtable.h      |  68 ++++++++
>  arch/riscv/include/asm/vmalloc.h      |  20 +++
>  arch/riscv/mm/hugetlbpage.c           | 236 +++++++++++++++++++++++++-
>  arch/riscv/mm/init.c                  |  29 +++-
>  8 files changed, 416 insertions(+), 11 deletions(-)

Sorry for being slow here, I got pretty buried this round.

This generally looks OK, but we definately need dynamic detection.  It 
should be super easy to do that with the new framework, as we essentialy 
just need to check for Svnapot on allocation.

Aside from that, just a minor comment: it feels like Svnapot is simple 
enough that we should be able to fit it into the generic mapping code.  
No big deal if it doesn't work and I haven't tried to do so, but I think 
it's worth a shot.