[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f6d2353d-d2ac-e4ca-7428-92bbf4116616@huawei.com>
Date: Fri, 27 Aug 2021 11:58:30 +0800
From: Liu Shixin <liushixin2@...wei.com>
To: Palmer Dabbelt <palmer@...belt.com>
CC: <corbet@....net>, Paul Walmsley <paul.walmsley@...ive.com>,
<aou@...s.berkeley.edu>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH -next] riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT
On 2021/8/26 12:48, Palmer Dabbelt wrote:
> On Thu, 05 Aug 2021 04:38:37 PDT (-0700), liushixin2@...wei.com wrote:
>> This sets the HAVE_ARCH_HUGE_VMAP option. Enable pmd vmap support and
>> define the required page table functions(Currently, riscv has only
>> three-level page tables support for 64BIT).
>>
>> Signed-off-by: Liu Shixin <liushixin2@...wei.com>
>> ---
>> .../features/vm/huge-vmap/arch-support.txt | 2 +-
>> arch/riscv/Kconfig | 1 +
>> arch/riscv/include/asm/vmalloc.h | 12 +++++
>> arch/riscv/mm/Makefile | 1 +
>> arch/riscv/mm/pgtable.c | 53 +++++++++++++++++++
>> 5 files changed, 68 insertions(+), 1 deletion(-)
>> create mode 100644 arch/riscv/mm/pgtable.c
>>
>> diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt
>> index 439fd9069b8b..0ff394acc9cf 100644
>> --- a/Documentation/features/vm/huge-vmap/arch-support.txt
>> +++ b/Documentation/features/vm/huge-vmap/arch-support.txt
>> @@ -22,7 +22,7 @@
>> | openrisc: | TODO |
>> | parisc: | TODO |
>> | powerpc: | ok |
>> - | riscv: | TODO |
>> + | riscv: | ok |
>> | s390: | TODO |
>> | sh: | TODO |
>> | sparc: | TODO |
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index 8fcceb8eda07..94cc2a254773 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -61,6 +61,7 @@ config RISCV
>> select GENERIC_TIME_VSYSCALL if MMU && 64BIT
>> select HANDLE_DOMAIN_IRQ
>> select HAVE_ARCH_AUDITSYSCALL
>> + select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT
>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
>> select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
>> select HAVE_ARCH_KASAN if MMU && 64BIT
>> diff --git a/arch/riscv/include/asm/vmalloc.h b/arch/riscv/include/asm/vmalloc.h
>> index ff9abc00d139..8f17f421f80c 100644
>> --- a/arch/riscv/include/asm/vmalloc.h
>> +++ b/arch/riscv/include/asm/vmalloc.h
>> @@ -1,4 +1,16 @@
>> #ifndef _ASM_RISCV_VMALLOC_H
>> #define _ASM_RISCV_VMALLOC_H
>>
>> +#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>> +
>> +#define IOREMAP_MAX_ORDER (PMD_SHIFT)
>> +
>> +#define arch_vmap_pmd_supported arch_vmap_pmd_supported
>> +static inline bool __init arch_vmap_pmd_supported(pgprot_t prot)
>> +{
>> + return true;
>> +}
>> +
>> +#endif
>> +
>> #endif /* _ASM_RISCV_VMALLOC_H */
>> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
>> index 7ebaef10ea1b..f932b4d69946 100644
>> --- a/arch/riscv/mm/Makefile
>> +++ b/arch/riscv/mm/Makefile
>> @@ -13,6 +13,7 @@ obj-y += extable.o
>> obj-$(CONFIG_MMU) += fault.o pageattr.o
>> obj-y += cacheflush.o
>> obj-y += context.o
>> +obj-y += pgtable.o
>>
>> ifeq ($(CONFIG_MMU),y)
>> obj-$(CONFIG_SMP) += tlbflush.o
>> diff --git a/arch/riscv/mm/pgtable.c b/arch/riscv/mm/pgtable.c
>> new file mode 100644
>> index 000000000000..f68dd2b71dce
>> --- /dev/null
>> +++ b/arch/riscv/mm/pgtable.c
>> @@ -0,0 +1,53 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <asm/pgalloc.h>
>> +#include <linux/gfp.h>
>> +#include <linux/kernel.h>
>> +#include <linux/pgtable.h>
>> +
>> +#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>> +
>> +int pud_set_huge(pud_t *pud, phys_addr_t phys, pgprot_t prot)
>> +{
>> + return 0;
>> +}
>> +
>> +int pud_clear_huge(pud_t *pud)
>> +{
>> + return 0;
>> +}
>> +
>> +int pud_free_pmd_page(pud_t *pud, unsigned long addr)
>> +{
>> + return 0;
>> +}
>
> Do we actually need the PUD helpers? I'd prefer to avoid adding these unimplemented stubs, IIUC the other architectures are relying on the generic implementations (which are themselves stubs) for configurations that don't have PUDs.
>
pud_set_huge() and pud_free_pmd_page() are completely useless for now and can be deleted directly. But deleting pud_clear_huge() will causes a compile error because there is no arch_vmap_pud_supported() check before pud_clear_huge(). Maybe we can keep pud_clear_huge() or add arch_vmap_pud_supported() in vunmap_pud_range(). Which way do you think is more appropriate?
thanks,
>> +int pmd_set_huge(pmd_t *pmd, phys_addr_t phys, pgprot_t prot)
>> +{
>> + pmd_t new_pmd = pfn_pmd(__phys_to_pfn(phys), prot);
>> +
>> + set_pmd(pmd, new_pmd);
>> + return 1;
>> +}
>> +
>> +int pmd_clear_huge(pmd_t *pmd)
>> +{
>> + if (!pmd_leaf(READ_ONCE(*pmd)))
>> + return 0;
>> + pmd_clear(pmd);
>> + return 1;
>> +}
>> +
>> +int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
>> +{
>> + pte_t *pte;
>> +
>> + pte = (pte_t *)pmd_page_vaddr(*pmd);
>> + pmd_clear(pmd);
>> +
>> + flush_tlb_kernel_range(addr, addr + PMD_SIZE);
>> + pte_free_kernel(NULL, pte);
>> + return 1;
>> +}
>> +
>> +#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
> .
>
Powered by blists - more mailing lists