diff mbox series

[-next,v19,23/24] riscv: Enable Vector code to be built

Message ID 20230509103033.11285-24-andy.chiu@sifive.com (mailing list archive)
State Superseded
Delegated to: Palmer Dabbelt
Headers show
Series riscv: Add vector ISA support | expand

Checks

Context Check Description
conchuod/cover_letter success Series has a cover letter
conchuod/tree_selection success Guessed tree name to be for-next at HEAD ac9a78681b92
conchuod/fixes_present success Fixes tag not required for -next series
conchuod/maintainers_pattern success MAINTAINERS pattern errors before the patch: 6 and now 6
conchuod/verify_signedoff success Signed-off-by tag matches author and committer
conchuod/kdoc success Errors and warnings before: 0 this patch: 0
conchuod/build_rv64_clang_allmodconfig success Errors and warnings before: 8 this patch: 8
conchuod/module_param success Was 0 now: 0
conchuod/build_rv64_gcc_allmodconfig fail Failed to build the tree with this patch.
conchuod/build_rv32_defconfig success Build OK
conchuod/dtb_warn_rv64 success Errors and warnings before: 3 this patch: 3
conchuod/header_inline success No static functions without inline keyword in header files
conchuod/checkpatch success total: 0 errors, 0 warnings, 0 checks, 55 lines checked
conchuod/source_inline success Was 0 now: 0
conchuod/build_rv64_nommu_k210_defconfig success Build OK
conchuod/verify_fixes success No Fixes tag
conchuod/build_rv64_nommu_virt_defconfig success Build OK

Commit Message

Andy Chiu May 9, 2023, 10:30 a.m. UTC 
From: Guo Ren <guoren@linux.alibaba.com>

This patch adds a config which enables vector feature from the kernel
space.

Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Co-developed-by: Greentime Hu <greentime.hu@sifive.com>
Signed-off-by: Greentime Hu <greentime.hu@sifive.com>
Suggested-by: Vineet Gupta <vineetg@rivosinc.com>
Suggested-by: Atish Patra <atishp@atishpatra.org>
Co-developed-by: Andy Chiu <andy.chiu@sifive.com>
Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
---
Changelog V19:
 - Add RISCV_V_DISABLE to set compile-time default.

 arch/riscv/Kconfig  | 31 +++++++++++++++++++++++++++++++
 arch/riscv/Makefile |  6 +++++-
 2 files changed, 36 insertions(+), 1 deletion(-)

Comments

Conor Dooley May 9, 2023, 12:34 p.m. UTC | #1 
Hey Andy,

On Tue, May 09, 2023 at 10:30:32AM +0000, Andy Chiu wrote:
> From: Guo Ren <guoren@linux.alibaba.com>
> 
> This patch adds a config which enables vector feature from the kernel
> space.

This commit message probably needs to change, it's not exactly doing
that anymore!

> Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
> Co-developed-by: Greentime Hu <greentime.hu@sifive.com>
> Signed-off-by: Greentime Hu <greentime.hu@sifive.com>

> Suggested-by: Vineet Gupta <vineetg@rivosinc.com>
> Suggested-by: Atish Patra <atishp@atishpatra.org>

And I suspect that these two are also likely inaccurate at this point,
but IDC.

> Co-developed-by: Andy Chiu <andy.chiu@sifive.com>
> Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
> ---
> Changelog V19:
>  - Add RISCV_V_DISABLE to set compile-time default.
> 
>  arch/riscv/Kconfig  | 31 +++++++++++++++++++++++++++++++
>  arch/riscv/Makefile |  6 +++++-
>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 1019b519d590..fa256f2e23c1 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -466,6 +466,37 @@ config RISCV_ISA_SVPBMT
>  
>  	   If you don't know what to do here, say Y.
>  
> +config TOOLCHAIN_HAS_V
> +	bool
> +	default y
> +	depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64iv)
> +	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32iv)
> +	depends on LLD_VERSION >= 140000 || LD_VERSION >= 23800
> +	depends on AS_HAS_OPTION_ARCH
> +
> +config RISCV_ISA_V
> +	bool "VECTOR extension support"
> +	depends on TOOLCHAIN_HAS_V
> +	depends on FPU
> +	select DYNAMIC_SIGFRAME
> +	default y
> +	help
> +	  Say N here if you want to disable all vector related procedure
> +	  in the kernel.
> +
> +	  If you don't know what to do here, say Y.
> +
> +config RISCV_V_DISABLE
> +	bool "Disable userspace Vector by default"
> +	depends on RISCV_ISA_V
> +	default n
> +	help
> +	  Say Y here if you want to disable default enablement state of Vector
> +	  in u-mode. This way userspace has to make explicit prctl() call to
> +	  enable Vector, or enable it via sysctl interface.

If we are worried about breaking userspace, why is the default for this
option not y? Or further,

config RISCV_ISA_V_DEFAULT_ENABLE
	bool "Enable userspace Vector by default"
	depends on RISCV_ISA_V
	help
	  Say Y here to allow use of Vector in userspace by default.
	  Otherwise, userspace has to make an explicit prctl() call to
	  enable Vector, or enable it via the sysctl interface.

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

Thanks,
Conor.
Andy Chiu May 9, 2023, 4:04 p.m. UTC | #2 
On Tue, May 9, 2023 at 8:35 PM Conor Dooley <conor.dooley@microchip.com> wrote:
>
> Hey Andy,
>
> On Tue, May 09, 2023 at 10:30:32AM +0000, Andy Chiu wrote:
> > From: Guo Ren <guoren@linux.alibaba.com>
> >
> > This patch adds a config which enables vector feature from the kernel
> > space.
>
> This commit message probably needs to change, it's not exactly doing
> that anymore!

Yes, I totally missed that part. I will get commit messages updated
when it's time for the next revision.

>
> > Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
> > Co-developed-by: Greentime Hu <greentime.hu@sifive.com>
> > Signed-off-by: Greentime Hu <greentime.hu@sifive.com>
>
> > Suggested-by: Vineet Gupta <vineetg@rivosinc.com>
> > Suggested-by: Atish Patra <atishp@atishpatra.org>
>
> And I suspect that these two are also likely inaccurate at this point,
> but IDC.

Agree. I am going to drop these.

>
> > Co-developed-by: Andy Chiu <andy.chiu@sifive.com>
> > Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
> > ---
> > Changelog V19:
> >  - Add RISCV_V_DISABLE to set compile-time default.
> >
> >  arch/riscv/Kconfig  | 31 +++++++++++++++++++++++++++++++
> >  arch/riscv/Makefile |  6 +++++-
> >  2 files changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 1019b519d590..fa256f2e23c1 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -466,6 +466,37 @@ config RISCV_ISA_SVPBMT
> >
> >          If you don't know what to do here, say Y.
> >
> > +config TOOLCHAIN_HAS_V
> > +     bool
> > +     default y
> > +     depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64iv)
> > +     depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32iv)
> > +     depends on LLD_VERSION >= 140000 || LD_VERSION >= 23800
> > +     depends on AS_HAS_OPTION_ARCH
> > +
> > +config RISCV_ISA_V
> > +     bool "VECTOR extension support"
> > +     depends on TOOLCHAIN_HAS_V
> > +     depends on FPU
> > +     select DYNAMIC_SIGFRAME
> > +     default y
> > +     help
> > +       Say N here if you want to disable all vector related procedure
> > +       in the kernel.
> > +
> > +       If you don't know what to do here, say Y.
> > +
> > +config RISCV_V_DISABLE
> > +     bool "Disable userspace Vector by default"
> > +     depends on RISCV_ISA_V
> > +     default n
> > +     help
> > +       Say Y here if you want to disable default enablement state of Vector
> > +       in u-mode. This way userspace has to make explicit prctl() call to
> > +       enable Vector, or enable it via sysctl interface.
>
> If we are worried about breaking userspace, why is the default for this
> option not y? Or further,
>
> config RISCV_ISA_V_DEFAULT_ENABLE
>         bool "Enable userspace Vector by default"
>         depends on RISCV_ISA_V
>         help
>           Say Y here to allow use of Vector in userspace by default.
>           Otherwise, userspace has to make an explicit prctl() call to
>           enable Vector, or enable it via the sysctl interface.
>
>           If you don't know what to do here, say N.
>

Yes, expressing the option, where Y means "on", is more direct. But I
have a little concern if we make the default as "off". Yes, we create
this option in the worries of breaking userspace. But given that the
break case might be rare, is it worth making userspace Vector harder
to use by doing this? I assume in an ideal world that nothing would
break and programs could just use V without bothering with prctl(), or
sysctl. But on the other hand, to make a program robust enough, we
must check the status with the prctl() anyway. So I have no answer
here.

> Thanks,
> Conor.
Conor Dooley May 9, 2023, 4:53 p.m. UTC | #3 
On Wed, May 10, 2023 at 12:04:12AM +0800, Andy Chiu wrote:
> > > +config RISCV_V_DISABLE
> > > +     bool "Disable userspace Vector by default"
> > > +     depends on RISCV_ISA_V
> > > +     default n
> > > +     help
> > > +       Say Y here if you want to disable default enablement state of Vector
> > > +       in u-mode. This way userspace has to make explicit prctl() call to
> > > +       enable Vector, or enable it via sysctl interface.
> >
> > If we are worried about breaking userspace, why is the default for this
> > option not y? Or further,
> >
> > config RISCV_ISA_V_DEFAULT_ENABLE
> >         bool "Enable userspace Vector by default"
> >         depends on RISCV_ISA_V
> >         help
> >           Say Y here to allow use of Vector in userspace by default.
> >           Otherwise, userspace has to make an explicit prctl() call to
> >           enable Vector, or enable it via the sysctl interface.
> >
> >           If you don't know what to do here, say N.
> >
> 
> Yes, expressing the option, where Y means "on", is more direct. But I
> have a little concern if we make the default as "off". Yes, we create
> this option in the worries of breaking userspace. But given that the
> break case might be rare, is it worth making userspace Vector harder
> to use by doing this? I assume in an ideal world that nothing would
> break and programs could just use V without bothering with prctl(), or
> sysctl. But on the other hand, to make a program robust enough, we
> must check the status with the prctl() anyway. So I have no answer
> here.

FWIW my logic was that those who know what they are doing can turn it on
& keep the pieces. I would expect distros and all that lark to be able to
make an educated decision here. But those that do not know what they are
doing should be given the "safe" option by default.
CONFIG_RISCV_ISA_V is default y, so will be enabled for those upgrading
their kernel. With your patch they would also get vector enabled by
default. The chance of a breakage might be small, but it seems easy to
avoid. I dunno...
Palmer Dabbelt May 9, 2023, 8:59 p.m. UTC | #4 
On Tue, 09 May 2023 09:53:17 PDT (-0700), Conor Dooley wrote:
> On Wed, May 10, 2023 at 12:04:12AM +0800, Andy Chiu wrote:
>> > > +config RISCV_V_DISABLE
>> > > +     bool "Disable userspace Vector by default"
>> > > +     depends on RISCV_ISA_V
>> > > +     default n
>> > > +     help
>> > > +       Say Y here if you want to disable default enablement state of Vector
>> > > +       in u-mode. This way userspace has to make explicit prctl() call to
>> > > +       enable Vector, or enable it via sysctl interface.
>> >
>> > If we are worried about breaking userspace, why is the default for this
>> > option not y? Or further,
>> >
>> > config RISCV_ISA_V_DEFAULT_ENABLE
>> >         bool "Enable userspace Vector by default"
>> >         depends on RISCV_ISA_V
>> >         help
>> >           Say Y here to allow use of Vector in userspace by default.
>> >           Otherwise, userspace has to make an explicit prctl() call to
>> >           enable Vector, or enable it via the sysctl interface.
>> >
>> >           If you don't know what to do here, say N.
>> >
>> 
>> Yes, expressing the option, where Y means "on", is more direct. But I
>> have a little concern if we make the default as "off". Yes, we create
>> this option in the worries of breaking userspace. But given that the
>> break case might be rare, is it worth making userspace Vector harder
>> to use by doing this? I assume in an ideal world that nothing would
>> break and programs could just use V without bothering with prctl(), or
>> sysctl. But on the other hand, to make a program robust enough, we
>> must check the status with the prctl() anyway. So I have no answer
>> here.
>
> FWIW my logic was that those who know what they are doing can turn it on
> & keep the pieces. I would expect distros and all that lark to be able to
> make an educated decision here. But those that do not know what they are
> doing should be given the "safe" option by default.
> CONFIG_RISCV_ISA_V is default y, so will be enabled for those upgrading
> their kernel. With your patch they would also get vector enabled by
> default. The chance of a breakage might be small, but it seems easy to
> avoid. I dunno...

It's really more of a distro/user question than anything else, I'm not 
really sure there's a right answer.  I'd lean towards turning V on by 
default, though: the defconfigs are meant for kernel hackers, so 
defaulting to the option that's more likely to break something seems 
like the way to go -- that way we see any possible breakages early and 
can go figure them out.

Depending on the risk tolerance of their users, distributions might want 
to turn this off by default.  I posted on sw-dev, which is generally the 
best way to find the distro folks.
Conor Dooley May 9, 2023, 9:06 p.m. UTC | #5 
On Tue, May 09, 2023 at 01:59:33PM -0700, Palmer Dabbelt wrote:
> On Tue, 09 May 2023 09:53:17 PDT (-0700), Conor Dooley wrote:
> > On Wed, May 10, 2023 at 12:04:12AM +0800, Andy Chiu wrote:
> > > > > +config RISCV_V_DISABLE
> > > > > +     bool "Disable userspace Vector by default"
> > > > > +     depends on RISCV_ISA_V
> > > > > +     default n
> > > > > +     help
> > > > > +       Say Y here if you want to disable default enablement state of Vector
> > > > > +       in u-mode. This way userspace has to make explicit prctl() call to
> > > > > +       enable Vector, or enable it via sysctl interface.
> > > >
> > > > If we are worried about breaking userspace, why is the default for this
> > > > option not y? Or further,
> > > >
> > > > config RISCV_ISA_V_DEFAULT_ENABLE
> > > >         bool "Enable userspace Vector by default"
> > > >         depends on RISCV_ISA_V
> > > >         help
> > > >           Say Y here to allow use of Vector in userspace by default.
> > > >           Otherwise, userspace has to make an explicit prctl() call to
> > > >           enable Vector, or enable it via the sysctl interface.
> > > >
> > > >           If you don't know what to do here, say N.
> > > >
> > > 
> > > Yes, expressing the option, where Y means "on", is more direct. But I
> > > have a little concern if we make the default as "off". Yes, we create
> > > this option in the worries of breaking userspace. But given that the
> > > break case might be rare, is it worth making userspace Vector harder
> > > to use by doing this? I assume in an ideal world that nothing would
> > > break and programs could just use V without bothering with prctl(), or
> > > sysctl. But on the other hand, to make a program robust enough, we
> > > must check the status with the prctl() anyway. So I have no answer
> > > here.
> > 
> > FWIW my logic was that those who know what they are doing can turn it on
> > & keep the pieces. I would expect distros and all that lark to be able to
> > make an educated decision here. But those that do not know what they are
> > doing should be given the "safe" option by default.
> > CONFIG_RISCV_ISA_V is default y, so will be enabled for those upgrading
> > their kernel. With your patch they would also get vector enabled by
> > default. The chance of a breakage might be small, but it seems easy to
> > avoid. I dunno...
> 
> It's really more of a distro/user question than anything else, I'm not
> really sure there's a right answer.  I'd lean towards turning V on by
> default, though: the defconfigs are meant for kernel hackers, so defaulting
> to the option that's more likely to break something seems like the way to go
> -- that way we see any possible breakages early and can go figure them out.

To get my "ackchyually" out of the way, I meant the person doing `make
olddefconfig` based on their distro's .config etc or using menuconfig
rather than someone using the in-kernel defconfig.
We can always set it to the potentially breaking mode explicitly in our
defconfigs while leaving the defaults for the aforementioned situations
as the "safe" option, no?

> Depending on the risk tolerance of their users, distributions might want to
> turn this off by default.  I posted on sw-dev, which is generally the best
> way to find the distro folks.
kernel test robot May 9, 2023, 10:14 p.m. UTC | #6 
Hi Andy,

kernel test robot noticed the following build errors:

[auto build test ERROR on next-20230509]

url:    https://github.com/intel-lab-lkp/linux/commits/Andy-Chiu/riscv-Rename-__switch_to_aux-fpu/20230509-183621
base:   next-20230509
patch link:    https://lore.kernel.org/r/20230509103033.11285-24-andy.chiu%40sifive.com
patch subject: [PATCH -next v19 23/24] riscv: Enable Vector code to be built
config: riscv-defconfig (https://download.01.org/0day-ci/archive/20230510/202305100615.JXidADRN-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/cacd7c504c93b48a44b87516cfdbe417dca4d007
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Andy-Chiu/riscv-Rename-__switch_to_aux-fpu/20230509-183621
        git checkout cacd7c504c93b48a44b87516cfdbe417dca4d007
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=riscv olddefconfig
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202305100615.JXidADRN-lkp@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "riscv_v_user_allowed" [arch/riscv/kvm/kvm.ko] undefined!
Conor Dooley May 15, 2023, 12:04 p.m. UTC | #7 
On Tue, May 09, 2023 at 10:06:14PM +0100, Conor Dooley wrote:
> On Tue, May 09, 2023 at 01:59:33PM -0700, Palmer Dabbelt wrote:
> > On Tue, 09 May 2023 09:53:17 PDT (-0700), Conor Dooley wrote:
> > > On Wed, May 10, 2023 at 12:04:12AM +0800, Andy Chiu wrote:
> > > > > > +config RISCV_V_DISABLE
> > > > > > +     bool "Disable userspace Vector by default"
> > > > > > +     depends on RISCV_ISA_V
> > > > > > +     default n
> > > > > > +     help
> > > > > > +       Say Y here if you want to disable default enablement state of Vector
> > > > > > +       in u-mode. This way userspace has to make explicit prctl() call to
> > > > > > +       enable Vector, or enable it via sysctl interface.
> > > > >
> > > > > If we are worried about breaking userspace, why is the default for this
> > > > > option not y? Or further,
> > > > >
> > > > > config RISCV_ISA_V_DEFAULT_ENABLE
> > > > >         bool "Enable userspace Vector by default"
> > > > >         depends on RISCV_ISA_V
> > > > >         help
> > > > >           Say Y here to allow use of Vector in userspace by default.
> > > > >           Otherwise, userspace has to make an explicit prctl() call to
> > > > >           enable Vector, or enable it via the sysctl interface.
> > > > >
> > > > >           If you don't know what to do here, say N.
> > > > >

There's been nothing here from the posting on the distro list. Whichever
way we go here, I would like the word "DEFAULT" added to the config
option to avoid confusion between it & RISC_ISA_V.

Thanks,
Conor.

> > > > 
> > > > Yes, expressing the option, where Y means "on", is more direct. But I
> > > > have a little concern if we make the default as "off". Yes, we create
> > > > this option in the worries of breaking userspace. But given that the
> > > > break case might be rare, is it worth making userspace Vector harder
> > > > to use by doing this? I assume in an ideal world that nothing would
> > > > break and programs could just use V without bothering with prctl(), or
> > > > sysctl. But on the other hand, to make a program robust enough, we
> > > > must check the status with the prctl() anyway. So I have no answer
> > > > here.
> > > 
> > > FWIW my logic was that those who know what they are doing can turn it on
> > > & keep the pieces. I would expect distros and all that lark to be able to
> > > make an educated decision here. But those that do not know what they are
> > > doing should be given the "safe" option by default.
> > > CONFIG_RISCV_ISA_V is default y, so will be enabled for those upgrading
> > > their kernel. With your patch they would also get vector enabled by
> > > default. The chance of a breakage might be small, but it seems easy to
> > > avoid. I dunno...
> > 
> > It's really more of a distro/user question than anything else, I'm not
> > really sure there's a right answer.  I'd lean towards turning V on by
> > default, though: the defconfigs are meant for kernel hackers, so defaulting
> > to the option that's more likely to break something seems like the way to go
> > -- that way we see any possible breakages early and can go figure them out.
> 
> To get my "ackchyually" out of the way, I meant the person doing `make
> olddefconfig` based on their distro's .config etc or using menuconfig
> rather than someone using the in-kernel defconfig.
> We can always set it to the potentially breaking mode explicitly in our
> defconfigs while leaving the defaults for the aforementioned situations
> as the "safe" option, no?
> 
> > Depending on the risk tolerance of their users, distributions might want to
> > turn this off by default.  I posted on sw-dev, which is generally the best
> > way to find the distro folks.
diff mbox series

Patch

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 1019b519d590..fa256f2e23c1 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -466,6 +466,37 @@  config RISCV_ISA_SVPBMT
 
 	   If you don't know what to do here, say Y.
 
+config TOOLCHAIN_HAS_V
+	bool
+	default y
+	depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64iv)
+	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32iv)
+	depends on LLD_VERSION >= 140000 || LD_VERSION >= 23800
+	depends on AS_HAS_OPTION_ARCH
+
+config RISCV_ISA_V
+	bool "VECTOR extension support"
+	depends on TOOLCHAIN_HAS_V
+	depends on FPU
+	select DYNAMIC_SIGFRAME
+	default y
+	help
+	  Say N here if you want to disable all vector related procedure
+	  in the kernel.
+
+	  If you don't know what to do here, say Y.
+
+config RISCV_V_DISABLE
+	bool "Disable userspace Vector by default"
+	depends on RISCV_ISA_V
+	default n
+	help
+	  Say Y here if you want to disable default enablement state of Vector
+	  in u-mode. This way userspace has to make explicit prctl() call to
+	  enable Vector, or enable it via sysctl interface.
+
+	  If you don't know what to do here, say N.
+
 config TOOLCHAIN_HAS_ZBB
 	bool
 	default y
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 0fb256bf8270..6ec6d52a4180 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -60,6 +60,7 @@  riscv-march-$(CONFIG_ARCH_RV32I)	:= rv32ima
 riscv-march-$(CONFIG_ARCH_RV64I)	:= rv64ima
 riscv-march-$(CONFIG_FPU)		:= $(riscv-march-y)fd
 riscv-march-$(CONFIG_RISCV_ISA_C)	:= $(riscv-march-y)c
+riscv-march-$(CONFIG_RISCV_ISA_V)	:= $(riscv-march-y)v
 
 ifdef CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC
 KBUILD_CFLAGS += -Wa,-misa-spec=2.2
@@ -71,7 +72,10 @@  endif
 # Check if the toolchain supports Zihintpause extension
 riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE) := $(riscv-march-y)_zihintpause
 
-KBUILD_CFLAGS += -march=$(subst fd,,$(riscv-march-y))
+# Remove F,D,V from isa string for all. Keep extensions between "fd" and "v" by
+# matching non-v and non-multi-letter extensions out with the filter ([^v_]*)
+KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)fd([^v_]*)v?/\1\2/')
+
 KBUILD_AFLAGS += -march=$(riscv-march-y)
 
 KBUILD_CFLAGS += -mno-save-restore