* [RFC PATCH 0/1] About adding new Z extensions in ISA realization @ 2022-12-20 12:02 Ruinland Tsai 2022-12-20 12:02 ` [RFC PATCH 1/1] arch/riscv : Add support for Zba/Zbb/Zbc/Zbs ext " Ruinland Tsai 2022-12-20 12:36 ` [RFC PATCH 0/1] About adding new Z extensions " Conor Dooley 0 siblings, 2 replies; 5+ messages in thread From: Ruinland Tsai @ 2022-12-20 12:02 UTC (permalink / raw) To: linux-riscv; +Cc: ruinland.tsai, greentime.hu, kito.cheng Dear all, I am wondering about what is the policy on adding new multilettered extensions into the ISA realization mechanism ? Currently we have plenty ratified exntensions left un-added, and some of them are already being used frequently, such as the B extension family - - namely, the zba, zbb, zbc, and zbs. Being unsure about whether I have done it in the right way, hence I wrote this RFC for adding those extensions. Also, just as I have inquired on the list before, what about the vendor extensions ? If a vendor wants to submit a vendor extensions without reavealing the detailed sepcs, what will be examined ? Cordially yours, Ruinland Ruinland Tsai (1): arch/riscv : Add support for Zba/Zbb/Zbc/Zbs ext in ISA realization arch/riscv/Kconfig | 24 ++++++++++++++++++++++++ arch/riscv/Makefile | 6 ++++++ arch/riscv/include/asm/hwcap.h | 4 ++++ arch/riscv/kernel/cpu.c | 4 ++++ arch/riscv/kernel/cpufeature.c | 4 ++++ 5 files changed, 42 insertions(+) -- 2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 5+ messages in thread
* [RFC PATCH 1/1] arch/riscv : Add support for Zba/Zbb/Zbc/Zbs ext in ISA realization 2022-12-20 12:02 [RFC PATCH 0/1] About adding new Z extensions in ISA realization Ruinland Tsai @ 2022-12-20 12:02 ` Ruinland Tsai 2022-12-20 12:52 ` Conor Dooley 2022-12-20 12:36 ` [RFC PATCH 0/1] About adding new Z extensions " Conor Dooley 1 sibling, 1 reply; 5+ messages in thread From: Ruinland Tsai @ 2022-12-20 12:02 UTC (permalink / raw) To: linux-riscv; +Cc: ruinland.tsai, greentime.hu, kito.cheng This commit adds the ratified RISC-V Bitmanip 1.0.0 extensions into the hadrware capability realization procedure. Thus, the print out of Zba/Zbb/Zbc/Zbs of /proc/cpuinfo could be matching the information provided in DT. Signed-off-by: Ruinland Tsai <ruinland.tsai@sifive.com> --- arch/riscv/Kconfig | 24 ++++++++++++++++++++++++ arch/riscv/Makefile | 6 ++++++ arch/riscv/include/asm/hwcap.h | 4 ++++ arch/riscv/kernel/cpu.c | 4 ++++ arch/riscv/kernel/cpufeature.c | 4 ++++ 5 files changed, 42 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index e2b656043abf..4f64d02d5208 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -447,6 +447,30 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zihintpause) depends on LLD_VERSION >= 150000 || LD_VERSION >= 23600 +config TOOLCHAIN_HAS_ZBA + bool "Zba extension support for B extension on Address generation" + default y + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zba) + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zba) + +config TOOLCHAIN_HAS_ZBB + bool "Zbb extension support for B extension on Basic bit-manipulation" + default y + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbb) + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbb) + +config TOOLCHAIN_HAS_ZBC + bool "Zbc extension support for B extension on Carry-less multiplication" + default y + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbc) + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbc) + +config TOOLCHAIN_HAS_ZBS + bool "Zbs extension support for B extension on single-bit instruction" + default y + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbs) + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbs) + config FPU bool "FPU support" default y diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index faf2c2177094..635fc2642a5e 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -61,6 +61,12 @@ riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei # Check if the toolchain supports Zicbom extension riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZICBOM) := $(riscv-march-y)_zicbom +# Check if the toolchain supports ratified B extensions +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZBA) := $(riscv-march-y)_zba +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZBB) := $(riscv-march-y)_zbb +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZBC) := $(riscv-march-y)_zbc +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZBS) := $(riscv-march-y)_zbs + # Check if the toolchain supports Zihintpause extension riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE) := $(riscv-march-y)_zihintpause diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index 86328e3acb02..baa51a282a69 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -55,6 +55,10 @@ extern unsigned long elf_hwcap; enum riscv_isa_ext_id { RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE, RISCV_ISA_EXT_SVPBMT, + RISCV_ISA_EXT_ZBA, + RISCV_ISA_EXT_ZBB, + RISCV_ISA_EXT_ZBC, + RISCV_ISA_EXT_ZBS, RISCV_ISA_EXT_ZICBOM, RISCV_ISA_EXT_ZIHINTPAUSE, RISCV_ISA_EXT_SSTC, diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index 1b9a5a66e55a..70361105a612 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -166,6 +166,10 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), + __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), + __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), + __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index 93e45560af30..ee536e08d197 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -224,6 +224,10 @@ void __init riscv_fill_hwcap(void) } else { SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF); SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); + SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); + SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); + SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); SET_ISA_EXT_MAP("sstc", RISCV_ISA_EXT_SSTC); -- 2.34.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 1/1] arch/riscv : Add support for Zba/Zbb/Zbc/Zbs ext in ISA realization 2022-12-20 12:02 ` [RFC PATCH 1/1] arch/riscv : Add support for Zba/Zbb/Zbc/Zbs ext " Ruinland Tsai @ 2022-12-20 12:52 ` Conor Dooley 0 siblings, 0 replies; 5+ messages in thread From: Conor Dooley @ 2022-12-20 12:52 UTC (permalink / raw) To: Ruinland Tsai; +Cc: linux-riscv, greentime.hu, kito.cheng [-- Attachment #1.1: Type: text/plain, Size: 6132 bytes --] On Tue, Dec 20, 2022 at 12:02:36PM +0000, Ruinland Tsai wrote: > arch/riscv : Add support for Zba/Zbb/Zbc/Zbs ext in ISA realization s|arch/riscv :|riscv: > This commit adds the ratified RISC-V Bitmanip 1.0.0 extensions "add the ..." > into the hadrware capability realization procedure. hardware > > Thus, the print out of Zba/Zbb/Zbc/Zbs of /proc/cpuinfo could be > matching the information provided in DT. "Thus, the printout of ... from /proc/cpuinfo could match the information..." > > Signed-off-by: Ruinland Tsai <ruinland.tsai@sifive.com> > --- > arch/riscv/Kconfig | 24 ++++++++++++++++++++++++ > arch/riscv/Makefile | 6 ++++++ > arch/riscv/include/asm/hwcap.h | 4 ++++ > arch/riscv/kernel/cpu.c | 4 ++++ > arch/riscv/kernel/cpufeature.c | 4 ++++ > 5 files changed, 42 insertions(+) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index e2b656043abf..4f64d02d5208 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -447,6 +447,30 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE > depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zihintpause) > depends on LLD_VERSION >= 150000 || LD_VERSION >= 23600 > > +config TOOLCHAIN_HAS_ZBA > + bool "Zba extension support for B extension on Address generation" > + default y > + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zba) > + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zba) Surely all of these things need to check for linker support too, not just cc? Consider a setup where CC is rather new, but the linker is quite old. Does this not cause problems for Zb* as it did for ZIHINTPAUSE? > +config TOOLCHAIN_HAS_ZBB > + bool "Zbb extension support for B extension on Basic bit-manipulation" > + default y > + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbb) > + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbb) > + > +config TOOLCHAIN_HAS_ZBC > + bool "Zbc extension support for B extension on Carry-less multiplication" > + default y > + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbc) > + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbc) > + > +config TOOLCHAIN_HAS_ZBS > + bool "Zbs extension support for B extension on single-bit instruction" > + default y > + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbs) > + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbs) > + > config FPU > bool "FPU support" > default y > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > index faf2c2177094..635fc2642a5e 100644 > --- a/arch/riscv/Makefile > +++ b/arch/riscv/Makefile > @@ -61,6 +61,12 @@ riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei > # Check if the toolchain supports Zicbom extension > riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZICBOM) := $(riscv-march-y)_zicbom > > +# Check if the toolchain supports ratified B extensions > +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZBA) := $(riscv-march-y)_zba > +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZBB) := $(riscv-march-y)_zbb > +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZBC) := $(riscv-march-y)_zbc > +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZBS) := $(riscv-march-y)_zbs > + > # Check if the toolchain supports Zihintpause extension > riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE) := $(riscv-march-y)_zihintpause > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > index 86328e3acb02..baa51a282a69 100644 > --- a/arch/riscv/include/asm/hwcap.h > +++ b/arch/riscv/include/asm/hwcap.h > @@ -55,6 +55,10 @@ extern unsigned long elf_hwcap; > enum riscv_isa_ext_id { > RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE, > RISCV_ISA_EXT_SVPBMT, > + RISCV_ISA_EXT_ZBA, > + RISCV_ISA_EXT_ZBB, > + RISCV_ISA_EXT_ZBC, > + RISCV_ISA_EXT_ZBS, > RISCV_ISA_EXT_ZICBOM, > RISCV_ISA_EXT_ZIHINTPAUSE, > RISCV_ISA_EXT_SSTC, > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > index 1b9a5a66e55a..70361105a612 100644 > --- a/arch/riscv/kernel/cpu.c > +++ b/arch/riscv/kernel/cpu.c > @@ -166,6 +166,10 @@ static struct riscv_isa_ext_data isa_ext_arr[] = { > __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), > __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), > __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), > + __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), > + __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), > + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), > + __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), > __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), > __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), > __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), Exactly how uABI-y this array is may be up for debate so I'd rather not add a whole load of items in in what may be an "incorrect" order. https://lore.kernel.org/all/20221205144525.2148448-1-conor.dooley@microchip.com/ I'll make sure to go ping that one once the merge window closes so that we have a definitive order in which things must be added. Thanks, Conor. > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index 93e45560af30..ee536e08d197 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -224,6 +224,10 @@ void __init riscv_fill_hwcap(void) > } else { > SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF); > SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); > + SET_ISA_EXT_MAP("zba", RISCV_ISA_EXT_ZBA); > + SET_ISA_EXT_MAP("zbb", RISCV_ISA_EXT_ZBB); > + SET_ISA_EXT_MAP("zbc", RISCV_ISA_EXT_ZBC); > + SET_ISA_EXT_MAP("zbs", RISCV_ISA_EXT_ZBS); > SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); > SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); > SET_ISA_EXT_MAP("sstc", RISCV_ISA_EXT_SSTC); > -- > 2.34.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 0/1] About adding new Z extensions in ISA realization 2022-12-20 12:02 [RFC PATCH 0/1] About adding new Z extensions in ISA realization Ruinland Tsai 2022-12-20 12:02 ` [RFC PATCH 1/1] arch/riscv : Add support for Zba/Zbb/Zbc/Zbs ext " Ruinland Tsai @ 2022-12-20 12:36 ` Conor Dooley 2022-12-21 18:34 ` Conor Dooley 1 sibling, 1 reply; 5+ messages in thread From: Conor Dooley @ 2022-12-20 12:36 UTC (permalink / raw) To: Ruinland Tsai; +Cc: linux-riscv, greentime.hu, kito.cheng [-- Attachment #1.1: Type: text/plain, Size: 3822 bytes --] Hey Ruinland! On Tue, Dec 20, 2022 at 12:02:35PM +0000, Ruinland Tsai wrote: > Dear all, > I am wondering about what is the policy on adding new multilettered > extensions into the ISA realization mechanism ? There's already been a few added, so it's largely a case of rinse-and-repeat? > Currently we have plenty ratified exntensions left un-added, and some > of them are already being used frequently Which in-the-wild SoCs actually have support for the unsupported extensions, out of curiosity? It'd be nice to have one with zbb support at the very least. > such as the B extension > family - - namely, the zba, zbb, zbc, and zbs. Heiko has been working on incorporating zbb support here: https://lore.kernel.org/linux-riscv/20221130225614.1594256-1-heiko@sntech.de/#t The first half of this patchset is likely to be applied immediately after -rc1. That half has been split out and is here: https://lore.kernel.org/all/20221207180821.2479987-1-heiko@sntech.de/ Clearly though that's trying to use zbb in the kernel so is not quite the same as what you are doing here with just adding them to the various structs. There was another patchset in June (ignore my & Samuel's confusion about ordering, that's been resolved since) that added some HWCAP stuff for a superset of the extensions you've mentioned here: https://lore.kernel.org/linux-riscv/YqY0i22SdbHjB%2FMX@Sun/ That'd need a rebase to apply on current code anyway (and I'd prefer if my patches cleaning up the ordering in those structs got applied before we add more extensions "out of order" to them!) There's also been discussion about whether it is sustainable to keep adding stuff to hwcap like this, but I have not been able to find the particular ML posts for that. Palmer spun up a PoC for a syscall & Heiko has said he would look into following up on that work after the inital zbb stuff was ready. The Higher Powers^TM will have to comment on what the policy is with adding more extensions in the interim. I'll admit it is a bit odd to not at least inform userspace as to what the actual ISA is. Heiko or Palmer, perhaps you've got a better idea of what the craic is there? > Being unsure about whether I have done it in the right way, hence I > wrote this RFC for adding those extensions. > > Also, just as I have inquired on the list before, what about the vendor > extensions? Since you didn't link the previous questions, I dunno what they were, but... After the discussion at the Plumbers BoF, the policy about vendor behaviour has been changed. The new wording is: <quote> Additionally, the RISC-V specification allows implementers to create their own custom extensions. These custom extensions aren't required to go through any review or ratification process by the RISC-V Foundation. To avoid the maintenance complexity and potential performance impact of adding kernel code for implementor-specific RISC-V extensions, we'll only consider patches for extensions that either: - Have been officially frozen or ratified by the RISC-V Foundation, or - Have been implemented in hardware that is widely available, per standard Linux practice. <\quote> > If a vendor wants to submit a vendor extensions without > reavealing the detailed sepcs, what will be examined ? I can only imagine that this would vary completely depending on what that extension is doing? I'm not sure how you would expect anyone to be able to review something though if you do not provide any information? Unless the answer is "no vendor extensions without specs", this sounds like something that could only be answered once code is available. Not the answers you were looking for perhaps Ruinland, but hopefully I was at least somewhat helpful. Thanks, Conor. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 0/1] About adding new Z extensions in ISA realization 2022-12-20 12:36 ` [RFC PATCH 0/1] About adding new Z extensions " Conor Dooley @ 2022-12-21 18:34 ` Conor Dooley 0 siblings, 0 replies; 5+ messages in thread From: Conor Dooley @ 2022-12-21 18:34 UTC (permalink / raw) To: Conor Dooley Cc: Ruinland Tsai, linux-riscv, greentime.hu, kito.cheng, dabbelt.com, heiko [-- Attachment #1.1: Type: text/plain, Size: 4675 bytes --] Hey again... +CC Palmer & Heiko like I meant to last time around... On Tue, Dec 20, 2022 at 12:36:29PM +0000, Conor Dooley wrote: > On Tue, Dec 20, 2022 at 12:02:35PM +0000, Ruinland Tsai wrote: > > Dear all, > > I am wondering about what is the policy on adding new multilettered > > extensions into the ISA realization mechanism ? > > There's already been a few added, so it's largely a case of > rinse-and-repeat? > > > Currently we have plenty ratified exntensions left un-added, and some > > of them are already being used frequently > > Which in-the-wild SoCs actually have support for the unsupported > extensions, out of curiosity? It'd be nice to have one with zbb support > at the very least. > > > such as the B extension > > family - - namely, the zba, zbb, zbc, and zbs. > > Heiko has been working on incorporating zbb support here: > https://lore.kernel.org/linux-riscv/20221130225614.1594256-1-heiko@sntech.de/#t > > The first half of this patchset is likely to be applied immediately > after -rc1. That half has been split out and is here: > https://lore.kernel.org/all/20221207180821.2479987-1-heiko@sntech.de/ > > Clearly though that's trying to use zbb in the kernel so is not quite > the same as what you are doing here with just adding them to the various > structs. > > There was another patchset in June (ignore my & Samuel's confusion about > ordering, that's been resolved since) that added some HWCAP stuff for a > superset of the extensions you've mentioned here: > https://lore.kernel.org/linux-riscv/YqY0i22SdbHjB%2FMX@Sun/ > That'd need a rebase to apply on current code anyway (and I'd prefer if > my patches cleaning up the ordering in those structs got applied before > we add more extensions "out of order" to them!) > > There's also been discussion about whether it is sustainable to keep > adding stuff to hwcap like this, but I have not been able to find the > particular ML posts for that. Palmer spun up a PoC for a syscall & Heiko > has said he would look into following up on that work after the inital > zbb stuff was ready. I didn't find the patches but I also didn't look very intently. It's here though if you'd like to check it out: https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-hwprobe-v1 IIRC it doesn't actually compile in that state though. > The Higher Powers^TM will have to comment on what the policy is with > adding more extensions in the interim. I'll admit it is a bit odd to > not at least inform userspace as to what the actual ISA is. > Heiko or Palmer, perhaps you've got a better idea of what the craic is > there? I asked Palmer today and cleared it up a little. He's planning on doing some more work on the new interface. Until that is ready, we have the remainder of HWCAP worth of space for adding new extensions. So not unlimited ability to add new extensions, but certainly not a hard blocker on adding more. > > Being unsure about whether I have done it in the right way, hence I > > wrote this RFC for adding those extensions. > > > > Also, just as I have inquired on the list before, what about the vendor > > extensions? > > Since you didn't link the previous questions, I dunno what they were, > but... > > After the discussion at the Plumbers BoF, the policy about vendor > behaviour has been changed. The new wording is: > <quote> > Additionally, the RISC-V specification allows implementers to create > their own custom extensions. These custom extensions aren't required > to go through any review or ratification process by the RISC-V > Foundation. To avoid the maintenance complexity and potential > performance impact of adding kernel code for implementor-specific > RISC-V extensions, we'll only consider patches for extensions that either: > > - Have been officially frozen or ratified by the RISC-V Foundation, or > - Have been implemented in hardware that is widely available, per standard > Linux practice. > <\quote> > > > If a vendor wants to submit a vendor extensions without > > reavealing the detailed sepcs, what will be examined ? > > I can only imagine that this would vary completely depending on what > that extension is doing? I'm not sure how you would expect anyone to be > able to review something though if you do not provide any information? > > Unless the answer is "no vendor extensions without specs", this sounds > like something that could only be answered once code is available. > > Not the answers you were looking for perhaps Ruinland, but hopefully I > was at least somewhat helpful. Thanks, Conor. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-12-21 18:42 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-12-20 12:02 [RFC PATCH 0/1] About adding new Z extensions in ISA realization Ruinland Tsai 2022-12-20 12:02 ` [RFC PATCH 1/1] arch/riscv : Add support for Zba/Zbb/Zbc/Zbs ext " Ruinland Tsai 2022-12-20 12:52 ` Conor Dooley 2022-12-20 12:36 ` [RFC PATCH 0/1] About adding new Z extensions " Conor Dooley 2022-12-21 18:34 ` Conor Dooley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox