linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Alistair Francis <Alistair.Francis@wdc.com>
To: "paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	Anup Patel <Anup.Patel@wdc.com>
Cc: Damien Le Moal <Damien.LeMoal@wdc.com>,
	"palmer@sifive.com" <palmer@sifive.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
	"anup@brainfault.org" <anup@brainfault.org>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"hch@infradead.org" <hch@infradead.org>,
	Atish Patra <Atish.Patra@wdc.com>,
	"graf@amazon.com" <graf@amazon.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [PATCH v7 02/21] RISC-V: Add bitmap reprensenting ISA features common across CPUs
Date: Mon, 23 Sep 2019 15:54:19 +0000	[thread overview]
Message-ID: <19bd7db1983e98de10ef1b083bc1b884f587aacc.camel@wdc.com> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1909210245000.2030@viisi.sifive.com>

On Sat, 2019-09-21 at 03:01 -0700, Paul Walmsley wrote:
> Hi Anup,
> 
> Thanks for changing this to use a bitmap.  A few comments below -
> 
> On Wed, 4 Sep 2019, Anup Patel wrote:
> 
> > This patch adds riscv_isa bitmap which represents Host ISA features
> > common across all Host CPUs. The riscv_isa is not same as elf_hwcap
> > because elf_hwcap will only have ISA features relevant for user-
> > space
> > apps whereas riscv_isa will have ISA features relevant to both
> > kernel
> > and user-space apps.
> > 
> > One of the use-case for riscv_isa bitmap is in KVM hypervisor where
> > we will use it to do following operations:
> > 
> > 1. Check whether hypervisor extension is available
> > 2. Find ISA features that need to be virtualized (e.g. floating
> >    point support, vector extension, etc.)
> > 
> > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > Reviewed-by: Alexander Graf <graf@amazon.com>
> > ---
> >  arch/riscv/include/asm/hwcap.h | 26 +++++++++++
> >  arch/riscv/kernel/cpufeature.c | 79
> > ++++++++++++++++++++++++++++++++--
> >  2 files changed, 102 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/riscv/include/asm/hwcap.h
> > b/arch/riscv/include/asm/hwcap.h
> > index 7ecb7c6a57b1..9b657375aa51 100644
> > --- a/arch/riscv/include/asm/hwcap.h
> > +++ b/arch/riscv/include/asm/hwcap.h
> > @@ -8,6 +8,7 @@
> >  #ifndef __ASM_HWCAP_H
> >  #define __ASM_HWCAP_H
> >  
> > +#include <linux/bits.h>
> >  #include <uapi/asm/hwcap.h>
> >  
> >  #ifndef __ASSEMBLY__
> > @@ -22,5 +23,30 @@ enum {
> >  };
> >  
> >  extern unsigned long elf_hwcap;
> > +
> > +#define RISCV_ISA_EXT_a		('a' - 'a')
> > +#define RISCV_ISA_EXT_c		('c' - 'a')
> > +#define RISCV_ISA_EXT_d		('d' - 'a')
> > +#define RISCV_ISA_EXT_f		('f' - 'a')
> > +#define RISCV_ISA_EXT_h		('h' - 'a')
> > +#define RISCV_ISA_EXT_i		('i' - 'a')
> > +#define RISCV_ISA_EXT_m		('m' - 'a')
> > +#define RISCV_ISA_EXT_s		('s' - 'a')
> > +#define RISCV_ISA_EXT_u		('u' - 'a')
> > +#define RISCV_ISA_EXT_zicsr	(('z' - 'a') + 1)
> > +#define RISCV_ISA_EXT_zifencei	(('z' - 'a') + 2)
> > +#define RISCV_ISA_EXT_zam	(('z' - 'a') + 3)
> > +#define RISCV_ISA_EXT_ztso	(('z' - 'a') + 4)
> 
> If we add the Z extensions here, it's probably best if we drop Zam
> from 
> this list.  The rationale is, as maintainers, we're planning to hold
> off 
> on merging any support for extensions or modules that aren't in the 
> "frozen" or "ratified" states, and according to the RISC-V specs,
> Zicsr, 
> Zifencei, and Ztso are all either frozen or ratified.  However, see 
> below -

Hey Paul,

I think that this should be documented somewhere in the kernel tree. In
QEMU land we have decieded that draft extensions will be accepted and
there are currently two extension series on list (Hypervisor from WDC
and Vector from CSKY). I suspect as RISC-V grows there are going to be
more and more groups that are interested in some specific extension and
want it upstream. In this case it makes sense to have it very clearly
documeneted so that everyone knows what will/won't be accepted.

If it's clearly documented then everyone will be on the same page as to
what will/won't be accepted by individual projects. As a side note I'll
probably look at adding something for QEMU as well :)

Alistair

> 
> > +
> > +#define RISCV_ISA_EXT_MAX	256
> > +
> > +unsigned long riscv_isa_extension_base(const unsigned long
> > *isa_bitmap);
> > +
> > +#define riscv_isa_extension_mask(ext)
> > BIT_MASK(RISCV_ISA_EXT_##ext)
> > +
> > +bool __riscv_isa_extension_available(const unsigned long
> > *isa_bitmap, int bit);
> > +#define riscv_isa_extension_available(isa_bitmap, ext)	\
> > +	__riscv_isa_extension_available(isa_bitmap,
> > RISCV_ISA_EXT_##ext)
> > +
> >  #endif
> >  #endif
> > diff --git a/arch/riscv/kernel/cpufeature.c
> > b/arch/riscv/kernel/cpufeature.c
> > index b1ade9a49347..4ce71ce5e290 100644
> > --- a/arch/riscv/kernel/cpufeature.c
> > +++ b/arch/riscv/kernel/cpufeature.c
> > @@ -6,21 +6,64 @@
> >   * Copyright (C) 2017 SiFive
> >   */
> >  
> > +#include <linux/bitmap.h>
> >  #include <linux/of.h>
> >  #include <asm/processor.h>
> >  #include <asm/hwcap.h>
> >  #include <asm/smp.h>
> >  
> >  unsigned long elf_hwcap __read_mostly;
> > +
> > +/* Host ISA bitmap */
> > +static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly;
> > +
> >  #ifdef CONFIG_FPU
> >  bool has_fpu __read_mostly;
> >  #endif
> >  
> > +/**
> > + * riscv_isa_extension_base - Get base extension word
> > + *
> > + * @isa_bitmap ISA bitmap to use
> > + * @returns base extension word as unsigned long value
> > + *
> > + * NOTE: If isa_bitmap is NULL then Host ISA bitmap will be used.
> > + */
> 
> Am happy to see comments that can be automatically parsed, but could
> you 
> reformat them into kernel-doc format? 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/doc-guide/kernel-doc.rst
> 
> > +unsigned long riscv_isa_extension_base(const unsigned long
> > *isa_bitmap)
> > +{
> > +	if (!isa_bitmap)
> > +		return riscv_isa[0];
> > +	return isa_bitmap[0];
> > +}
> > +EXPORT_SYMBOL_GPL(riscv_isa_extension_base);
> > +
> > +/**
> > + * __riscv_isa_extension_available - Check whether given extension
> > + * is available or not
> > + *
> > + * @isa_bitmap ISA bitmap to use
> > + * @bit bit position of the desired extension
> > + * @returns true or false
> > + *
> > + * NOTE: If isa_bitmap is NULL then Host ISA bitmap will be used.
> > + */
> 
> Same comment as above.
> 
> > +bool __riscv_isa_extension_available(const unsigned long
> > *isa_bitmap, int bit)
> > +{
> > +	const unsigned long *bmap = (isa_bitmap) ? isa_bitmap :
> > riscv_isa;
> > +
> > +	if (bit >= RISCV_ISA_EXT_MAX)
> > +		return false;
> > +
> > +	return test_bit(bit, bmap) ? true : false;
> > +}
> > +EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
> > +
> >  void riscv_fill_hwcap(void)
> >  {
> >  	struct device_node *node;
> >  	const char *isa;
> > -	size_t i;
> > +	char print_str[BITS_PER_LONG+1];
> > +	size_t i, j, isa_len;
> >  	static unsigned long isa2hwcap[256] = {0};
> >  
> >  	isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
> > @@ -32,8 +75,11 @@ void riscv_fill_hwcap(void)
> >  
> >  	elf_hwcap = 0;
> >  
> > +	bitmap_zero(riscv_isa, RISCV_ISA_EXT_MAX);
> > +
> >  	for_each_of_cpu_node(node) {
> >  		unsigned long this_hwcap = 0;
> > +		unsigned long this_isa = 0;
> >  
> >  		if (riscv_of_processor_hartid(node) < 0)
> >  			continue;
> > @@ -43,8 +89,20 @@ void riscv_fill_hwcap(void)
> >  			continue;
> >  		}
> >  
> > -		for (i = 0; i < strlen(isa); ++i)
> > +		i = 0;
> > +		isa_len = strlen(isa);
> > +#if defined(CONFIG_32BIT)
> > +		if (!strncmp(isa, "rv32", 4))
> > +			i += 4;
> > +#elif defined(CONFIG_64BIT)
> > +		if (!strncmp(isa, "rv64", 4))
> > +			i += 4;
> > +#endif
> > +		for (; i < isa_len; ++i) {
> >  			this_hwcap |= isa2hwcap[(unsigned
> > char)(isa[i])];
> > +			if ('a' <= isa[i] && isa[i] <= 'z')
> > +				this_isa |= (1UL << (isa[i] - 'a'));
> 
> Continuing from the earlier comment, this code won't properly handle
> the X 
> and Z prefix extensions.  So maybe for the time being, we should just
> drop 
> the lines mentioned earlier that imply that we can parse Z-prefix 
> extensions, and change this line so it ignores X and Z letters?
> 
> Then a subsequent patch can add support for more complicated
> extension 
> string parsing.
> 
> 
> > +		}
> >  
> >  		/*
> >  		 * All "okay" hart should have same isa. Set HWCAP
> > based on
> > @@ -55,6 +113,11 @@ void riscv_fill_hwcap(void)
> >  			elf_hwcap &= this_hwcap;
> >  		else
> >  			elf_hwcap = this_hwcap;
> > +
> > +		if (riscv_isa[0])
> > +			riscv_isa[0] &= this_isa;
> > +		else
> > +			riscv_isa[0] = this_isa;
> >  	}
> >  
> >  	/* We don't support systems with F but without D, so mask those
> > out
> > @@ -64,7 +127,17 @@ void riscv_fill_hwcap(void)
> >  		elf_hwcap &= ~COMPAT_HWCAP_ISA_F;
> >  	}
> >  
> > -	pr_info("elf_hwcap is 0x%lx\n", elf_hwcap);
> > +	memset(print_str, 0, sizeof(print_str));
> > +	for (i = 0, j = 0; i < BITS_PER_LONG; i++)
> > +		if (riscv_isa[0] & BIT_MASK(i))
> > +			print_str[j++] = (char)('a' + i);
> > +	pr_info("riscv: ISA extensions %s\n", print_str);
> > +
> > +	memset(print_str, 0, sizeof(print_str));
> > +	for (i = 0, j = 0; i < BITS_PER_LONG; i++)
> > +		if (elf_hwcap & BIT_MASK(i))
> > +			print_str[j++] = (char)('a' + i);
> > +	pr_info("riscv: ELF capabilities %s\n", print_str);
> >  
> >  #ifdef CONFIG_FPU
> >  	if (elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))
> > -- 
> > 2.17.1
> > 
> > 
> 
> - Paul
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2019-09-23 15:54 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-04 16:13 [PATCH v7 00/21] KVM RISC-V Support Anup Patel
2019-09-04 16:13 ` [PATCH v7 01/21] KVM: RISC-V: Add KVM_REG_RISCV for ONE_REG interface Anup Patel
2019-09-19 12:37   ` Paul Walmsley
2019-09-04 16:13 ` [PATCH] RISC-V: Enable KVM for RV64 and RV32 Anup Patel
2019-09-04 16:17   ` Anup Patel
2019-09-04 16:13 ` [PATCH v7 02/21] RISC-V: Add bitmap reprensenting ISA features common across CPUs Anup Patel
2019-09-19 12:56   ` Anup Patel
2019-09-21 10:01   ` Paul Walmsley
2019-09-23  3:39     ` Anup Patel
2019-09-23 15:54     ` Alistair Francis [this message]
2019-09-04 16:14 ` [PATCH v7 03/21] RISC-V: Export few kernel symbols Anup Patel
2019-09-19 12:39   ` Paul Walmsley
2019-09-04 16:14 ` [PATCH v7 04/21] RISC-V: Add hypervisor extension related CSR defines Anup Patel
2019-09-04 16:14 ` [PATCH v7 05/21] RISC-V: Add initial skeletal KVM support Anup Patel
2019-09-04 16:14 ` [PATCH v7 06/21] RISC-V: KVM: Implement VCPU create, init and destroy functions Anup Patel
2019-09-23  6:44   ` Alexander Graf
2019-09-23 12:37     ` Anup Patel
2019-09-04 16:14 ` [PATCH v7 07/21] RISC-V: KVM: Implement VCPU interrupts and requests handling Anup Patel
2019-09-04 16:14 ` [PATCH v7 08/21] RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls Anup Patel
2019-09-23  3:42   ` Anup Patel
2019-09-04 16:15 ` [PATCH v7 09/21] RISC-V: KVM: Implement VCPU world-switch Anup Patel
2019-09-04 16:15 ` [PATCH v7 10/21] RISC-V: KVM: Handle MMIO exits for VCPU Anup Patel
2019-09-23  6:50   ` Alexander Graf
2019-09-23 11:12   ` Paolo Bonzini
2019-09-23 13:09     ` Anup Patel
2019-09-23 13:33       ` Paolo Bonzini
2019-09-24  5:07         ` Anup Patel
2019-10-08 22:44     ` Palmer Dabbelt
2019-10-09  4:58       ` Anup Patel
2019-09-04 16:15 ` [PATCH v7 11/21] RISC-V: KVM: Handle WFI " Anup Patel
2019-09-23  6:53   ` Alexander Graf
2019-09-23 12:54     ` Anup Patel
2019-09-04 16:15 ` [PATCH v7 12/21] RISC-V: KVM: Implement VMID allocator Anup Patel
2019-09-04 16:15 ` [PATCH v7 13/21] RISC-V: KVM: Implement stage2 page table programming Anup Patel
2019-09-04 16:15 ` [PATCH v7 14/21] RISC-V: KVM: Implement MMU notifiers Anup Patel
2019-09-04 16:15 ` [PATCH v7 15/21] RISC-V: KVM: Add timer functionality Anup Patel
2019-09-04 16:15 ` [PATCH v7 16/21] RISC-V: KVM: FP lazy save/restore Anup Patel
2019-09-04 16:15 ` [PATCH v7 17/21] RISC-V: KVM: Implement ONE REG interface for FP registers Anup Patel
2019-09-04 16:16 ` [PATCH v7 18/21] RISC-V: KVM: Add SBI v0.1 support Anup Patel
2019-09-05  8:35   ` Andreas Schwab
2019-09-23  7:01   ` Alexander Graf
2019-09-23 12:59     ` Anup Patel
2019-09-04 16:16 ` [PATCH v7 19/21] RISC-V: KVM: Document RISC-V specific parts of KVM API Anup Patel
2019-09-04 16:16 ` [PATCH v7 20/21] RISC-V: Enable VIRTIO drivers in RV64 and RV32 defconfig Anup Patel
2019-09-19  7:54   ` Paul Walmsley
2019-09-04 16:16 ` [PATCH v7 21/21] RISC-V: KVM: Add MAINTAINERS entry Anup Patel

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=19bd7db1983e98de10ef1b083bc1b884f587aacc.camel@wdc.com \
    --to=alistair.francis@wdc.com \
    --cc=Anup.Patel@wdc.com \
    --cc=Atish.Patra@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=anup@brainfault.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=graf@amazon.com \
    --cc=hch@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).