Messages in this thread | | | Date | Wed, 1 Dec 2021 21:29:48 +0800 | From | Jisheng Zhang <> | Subject | Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports |
| |
On Wed, 1 Dec 2021 11:48:44 +0530 Anup Patel <anup@brainfault.org> wrote:
> > > > */ > > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > > > index d959d207a40d..fa7480cb8b87 100644 > > > > --- a/arch/riscv/kernel/cpufeature.c > > > > +++ b/arch/riscv/kernel/cpufeature.c > > > > @@ -8,6 +8,7 @@ > > > > > > > > #include <linux/bitmap.h> > > > > #include <linux/of.h> > > > > +#include <linux/pgtable.h> > > > > #include <asm/processor.h> > > > > #include <asm/hwcap.h> > > > > #include <asm/smp.h> > > > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > > > > } > > > > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > > > > > > > +static void __init mmu_supports_svpbmt(void) > > > > +{ > > > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > > > > > > IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What > > > about that idea? > > > > Yes, sorry for missing it, yes, I think we can have something like this > > > > config ARCH_HAS_RISCV_SVPBMT > > bool > > default n > > > > any platform which needs this support, can just > > > > select ARCH_HAS_RISCV_SVPBMT > > > > and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ? > > > > > > > > > + struct device_node *node; > > > > + const char *str; > > > > + > > > > + for_each_of_cpu_node(node) { > > > > + if (of_property_read_string(node, "mmu-type", &str)) > > > > + continue; > > > > + > > > > + if (!strncmp(str + 6, "none", 4)) > > > > + continue; > > > > + > > > > + if (of_property_read_string(node, "mmu", &str)) > > > > + continue; > > > > + > > > > + if (strncmp(str + 6, "svpmbt", 6)) > > > > + continue; > > > > + } > > > > + > > > > + __svpbmt.pma = _SVPBMT_PMA; > > > > + __svpbmt.nocache = _SVPBMT_NC; > > > > + __svpbmt.io = _SVPBMT_IO; > > > > + __svpbmt.mask = _SVPBMT_MASK; > > > > +#endif > > > > +} > > > > + > > > > +static void __init mmu_supports(void) > > > > > > can we remove this function currently? Instead, directly call > > > mmu_supports_svpbmt()? > > > > > > > +{ > > > > + mmu_supports_svpbmt(); > > > > +} > > > > + > > > > void __init riscv_fill_hwcap(void) > > > > { > > > > struct device_node *node; > > > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > > > > size_t i, j, isa_len; > > > > static unsigned long isa2hwcap[256] = {0}; > > > > > > > > + mmu_supports(); > > > > + > > > > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > > > > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > > > > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > > > index 24b2b8044602..e4e658165ee1 100644 > > > > --- a/arch/riscv/mm/init.c > > > > +++ b/arch/riscv/mm/init.c > > > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > > > return vmemmap_populate_basepages(start, end, node, NULL); > > > > } > > > > #endif > > > > + > > > > +#if defined(CONFIG_64BIT) > > > > +struct __svpbmt_struct __svpbmt __ro_after_init; > > > > > > Added the structure for all RV64 including NOMMU case and those platforms > > > which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT > > > suggestion can solve this problem. > > > > see ARCH_HAS_RISCV_SVPBMT above . :-) > > This config option will not align with the goal of having a unified > kernel image which works on HW with/without Svpmbt.
Just my thoughts:
If disable this option, HW without Svpbmt can work as before; Hw with Svpbmt will only have a basic working, those DMA etc can't work.
If enable this option, HW without Svpbmt can work as well, but with a bit overhead and waste. HW with Svpbmt can work. So this option gives those platforms which doesn't need Svpbmt a chance to totally disable it.
But linux distributions which want a uniified Image usually enable features as much as possible, so IMHO, this config option can still meet unified kernel image requirement.
> > Better to explore code patching approaches which have zero > overhead.
It would be nice if the Svpbmt can be supported via. coding patching tech.
Thanks
| |