[PATCH v10 1/3] riscv: mm: modify pte format for Svnapot

[Andrew Jones]

On Mon, Dec 12, 2022 at 03:34:46PM +0800, Qinglin Pan wrote:
> Hi Andrew,
> 
> On 2022/12/12 15:18, Andrew Jones wrote:
> > On Mon, Dec 12, 2022 at 02:55:24PM +0800, panqinglin2020 at iscas.ac.cn wrote:
> > > From: Qinglin Pan <panqinglin2020 at iscas.ac.cn>
> > > 
> > > Add one alternative to enable/disable svnapot support, enable this static
> > > key when "svnapot" is in the "riscv,isa" field of fdt and SVNAPOT compile
> > > option is set. It will influence the behavior of has_svnapot. All code
> > > dependent on svnapot should make sure that has_svnapot return true firstly.
> > > 
> > > Modify PTE definition for Svnapot, and creates some functions in pgtable.h
> > > to mark a PTE as napot and check if it is a Svnapot PTE. Until now, only
> > > 64KB napot size is supported in spec, so some macros has only 64KB version.
> > > 
> > > Signed-off-by: Qinglin Pan <panqinglin2020 at iscas.ac.cn>
> > > Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
> > > 
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index 67ef08d33d3a..4b5bb719bc6f 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -397,6 +397,24 @@ config RISCV_ISA_C
> > >   	  If you don't know what to do here, say Y.
> > > +config RISCV_ISA_SVNAPOT
> > > +	bool "SVNAPOT extension support"
> > > +	depends on 64BIT && MMU
> > > +	select RISCV_ALTERNATIVE
> > 
> > Hmm, shouldn't we also be selecting HUGETLBFS?
> 
> RISCV_ISA_SVNAPOT is not dependent on HUGETLBFS, so
> it may not be necessary to select HUGETLBFS here? :)

Ah, indeed. I got too wrapped up in the HUGE_MAX_HSTATE analysis and
forgot we actually don't need it. So, either the Kconfig text should
point out that memory is only consumed when HUGETLBFS is selected, as
I've edited in below, or we should add the warning to HUGETLBFS, or
maybe just drop the warning altogether.

> 
> > 
> > > +	default y
> > > +	help
> > > +	  Allow kernel to detect SVNAPOT ISA-extension dynamically in boot time
> >                                  ^ the                              ^ s/in/at/
> > 
> > > +	  and enable its usage.
> > > +
> > > +	  SVNAPOT extension helps to mark contiguous PTEs as a range
> > > +	  of contiguous virtual-to-physical translations, with a naturally
> > > +	  aligned power-of-2 (NAPOT) granularity larger than the base 4KB page
> > > +	  size. Without CPU's hardware extension, turnning on this feature
> > > +	  may cause some little momory leak now.
> > > +
> > > +	  If you are sure your CPU has not SVNAPOT extension, say N.
> > > +	  If you don't know what to do here, say Y.
> > > +
> > 
> > 	The SVNAPOT extension is used to mark contiguous PTEs as a range
> > 	of contiguous virtual-to-physical translations for a naturally
> > 	aligned power-of-2 (NAPOT) granularity larger than the base 4KB page
> > 	size. This option unconditionally allocates some memory for each
> > 	NAPOT page size supported by the kernel. When optimizing for low
> > 	memory consumption and for platforms without the SVNAPOT extension,
> > 	it may be better to say N here.
> > 
> > 	If you don't know what to do here, say Y.

 	The SVNAPOT extension is used to mark contiguous PTEs as a range
 	of contiguous virtual-to-physical translations for a naturally
 	aligned power-of-2 (NAPOT) granularity larger than the base 4KB page
 	size. When HUGETLBFS is also selected this option unconditionally
	allocates some memory for each NAPOT page size supported by the kernel.
	When optimizing for low memory consumption and for platforms without
	the SVNAPOT extension, it may be better to say N here.

	If you don't know what to do here, say Y.

Thanks,
drew

> 
> Your expression is more accurate. I will resend the v10 patchset with
> thisparagraph in it. Thanks!
> 
> Regards,
> Qinglin.
> 
> > 
> > 
> > Thanks,
> > drew
>