public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rémi Denis-Courmont" <remi@remlab.net>
To: linux-riscv@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] RISC-V: Framework for vendor extensions
Date: Thu, 06 Jul 2023 23:04:24 +0300	[thread overview]
Message-ID: <2887841.e9J7NaK4W3@basile.remlab.net> (raw)
In-Reply-To: <ZKcZhz7rPd41Z2DK@ghost>

Le torstaina 6. heinäkuuta 2023, 22.44.07 EEST Charlie Jenkins a écrit :
> On Thu, Jul 06, 2023 at 07:29:37PM +0300, Rémi Denis-Courmont wrote:
> > Le torstaina 6. heinäkuuta 2023, 6.30.17 EEST Charlie Jenkins a écrit :
> > > Create Kconfig files, Makefiles, and functions to enable vendors to
> > > provide information via the riscv_hwprobe syscall about which vendor
> > > extensions are available.
> > > 
> > > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> > > ---
> > > 
> > >  arch/riscv/Kbuild                     |  1 +
> > >  arch/riscv/Kconfig                    |  1 +
> > >  arch/riscv/Kconfig.vendor             |  3 +++
> > >  arch/riscv/include/asm/hwprobe.h      |  1 +
> > >  arch/riscv/kernel/sys_riscv.c         | 40
> > > 
> > > ++++++++++++++++++++++++++++++++---
> > > arch/riscv/vendor_extensions/Makefile |
> > > 
> > >  3 +++
> > >  6 files changed, 46 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
> > > index afa83e307a2e..bea38010d9db 100644
> > > --- a/arch/riscv/Kbuild
> > > +++ b/arch/riscv/Kbuild
> > > @@ -3,6 +3,7 @@
> > > 
> > >  obj-y += kernel/ mm/ net/
> > >  obj-$(CONFIG_BUILTIN_DTB) += boot/dts/
> > >  obj-y += errata/
> > > 
> > > +obj-y += vendor_extensions/
> > > 
> > >  obj-$(CONFIG_KVM) += kvm/
> > >  
> > >  obj-$(CONFIG_ARCH_HAS_KEXEC_PURGATORY) += purgatory/
> > > 
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index c1505c7729ec..19404ede0ee3 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -276,6 +276,7 @@ config AS_HAS_OPTION_ARCH
> > > 
> > >  source "arch/riscv/Kconfig.socs"
> > >  source "arch/riscv/Kconfig.errata"
> > > 
> > > +source "arch/riscv/Kconfig.vendor"
> > > 
> > >  menu "Platform type"
> > > 
> > > diff --git a/arch/riscv/Kconfig.vendor b/arch/riscv/Kconfig.vendor
> > > new file mode 100644
> > > index 000000000000..213ac3e6fed5
> > > --- /dev/null
> > > +++ b/arch/riscv/Kconfig.vendor
> > > @@ -0,0 +1,3 @@
> > > +menu "Vendor extensions selection"
> > > +
> > > +endmenu # "Vendor extensions selection"
> > > diff --git a/arch/riscv/include/asm/hwprobe.h
> > > b/arch/riscv/include/asm/hwprobe.h index 78936f4ff513..fadb38b83243
> > > 100644
> > > --- a/arch/riscv/include/asm/hwprobe.h
> > > +++ b/arch/riscv/include/asm/hwprobe.h
> > > @@ -9,5 +9,6 @@
> > > 
> > >  #include <uapi/asm/hwprobe.h>
> > >  
> > >  #define RISCV_HWPROBE_MAX_KEY 5
> > > 
> > > +#define RISCV_HWPROBE_VENDOR_EXTENSION_SPACE (UL(1)<<63)
> > 
> > Isn't this UB on 32-bit RISC-V ?
> 
> Hmm, yeah it would be, but the hwprobe syscall is based on a 64 bit key
> using the __s64 type. There could be an alternative vendor space at the
> top of 32-bits for those machines.

Key values inside the struct are 64-bit even on RV32, but your key definition 
here is 32-bit. That can't work.

Plus this needs to be defined under uapi/ as the rest of the hwprobe constants.

And then, even on RV64, 1UL << 63 is not a valid signed constant. Kernel code 
might tolerate it, but that will most likely cause warnings or errors in the 
potentially stricter compilation environments of user-space code.

> > >  #endif
> > > 
> > > diff --git a/arch/riscv/kernel/sys_riscv.c
> > > b/arch/riscv/kernel/sys_riscv.c
> > > index 26ef5526bfb4..2351a5f7b8b1 100644
> > > --- a/arch/riscv/kernel/sys_riscv.c
> > > +++ b/arch/riscv/kernel/sys_riscv.c
> > > @@ -188,9 +188,35 @@ static u64 hwprobe_misaligned(const struct cpumask
> > > *cpus) return perf;
> > > 
> > >  }
> > > 
> > > +static int hwprobe_vendor(__u64 mvendorid, struct riscv_hwprobe *pair,
> > > +			 const struct cpumask *cpus)
> > > +{
> > > +	switch (mvendorid) {
> > > +	default:
> > > +		return -1;
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > 
> > >  static void hwprobe_one_pair(struct riscv_hwprobe *pair,
> > >  
> > >  			     const struct cpumask *cpus)
> > >  
> > >  {
> > > 
> > > +	int err;
> > > +
> > > +	if (((unsigned long) pair->key) >=
> > 
> > RISCV_HWPROBE_VENDOR_EXTENSION_SPACE) {
> > 
> > > +		struct riscv_hwprobe mvendorid = {
> > > +			.key = RISCV_HWPROBE_KEY_MVENDORID,
> > > +			.value = 0
> > > +		};
> > > +
> > > +		hwprobe_arch_id(&mvendorid, cpus);
> > > +		if (mvendorid.value != -1ULL)
> > > +			err = hwprobe_vendor(mvendorid.value, pair,
> > 
> > cpus);
> > 
> > > +		else
> > > +			err = -1;
> > > +	}
> > > +
> > > 
> > >  	switch (pair->key) {
> > >  	case RISCV_HWPROBE_KEY_MVENDORID:
> > > 
> > >  	case RISCV_HWPROBE_KEY_MARCHID:
> > > @@ -217,13 +243,21 @@ static void hwprobe_one_pair(struct riscv_hwprobe
> > > *pair,
> > > 
> > >  	/*
> > >  	
> > >  	 * For forward compatibility, unknown keys don't fail the whole
> > > 
> > > -	 * call, but get their element key set to -1 and value set to 0
> > > -	 * indicating they're unrecognized.
> > > +	 * call, instead an error is raised to indicate the element key
> > > +	 * is unrecognized.
> > > 
> > >  	 */
> > >  	
> > >  	default:
> > > +		err = -1;
> > > +		break;
> > > +	}
> > > +
> > > +	/*
> > > +	 * Setting the element key to -1 and value to 0 indicates that
> > > +	 * hwprobe was unable to find the requested key.
> > > +	 */
> > > +	if (err != 0) {
> > > 
> > >  		pair->key = -1;
> > >  		pair->value = 0;
> > > 
> > > -		break;
> > > 
> > >  	}
> > >  
> > >  }
> > > 
> > > diff --git a/arch/riscv/vendor_extensions/Makefile
> > > b/arch/riscv/vendor_extensions/Makefile new file mode 100644
> > > index 000000000000..e815895e9372
> > > --- /dev/null
> > > +++ b/arch/riscv/vendor_extensions/Makefile
> > > @@ -0,0 +1,3 @@
> > > +ifdef CONFIG_RELOCATABLE
> > > +KBUILD_CFLAGS += -fno-pie
> > > +endif


-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/




  reply	other threads:[~2023-07-06 20:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-06  3:30 [PATCH 0/3] RISC-V: Support querying vendor extensions Charlie Jenkins
2023-07-06  3:30 ` [PATCH 1/3] RISC-V: Framework for " Charlie Jenkins
2023-07-06 16:29   ` Rémi Denis-Courmont
2023-07-06 19:44     ` Charlie Jenkins
2023-07-06 20:04       ` Rémi Denis-Courmont [this message]
2023-07-06 17:15   ` Conor Dooley
2023-07-06 19:51     ` Charlie Jenkins
2023-07-06 20:43       ` Conor Dooley
2023-07-06  3:30 ` [PATCH 2/3] RISC-V: Add T-Head 0.7.1 vector extension to hwprobe Charlie Jenkins
2023-07-06 16:32   ` Rémi Denis-Courmont
2023-07-06 20:05     ` Charlie Jenkins
2023-07-06 17:38   ` Conor Dooley
2023-07-06 20:00     ` Charlie Jenkins
2023-07-06 21:24       ` Conor Dooley
2023-07-06  3:30 ` [PATCH 3/3] RISC-V: Include documentation for hwprobe vendor extensions Charlie Jenkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2887841.e9J7NaK4W3@basile.remlab.net \
    --to=remi@remlab.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox