From: Leo Liang <ycliang@andestech.com>
To: Xiang W <wxjstz@126.com>
Cc: <u-boot@lists.denx.de>, <anup.patel@wdc.com>,
<atish.patra@wdc.com>, <bmeng.cn@gmail.com>, <rick@andestech.com>,
<lukas.auer@aisec.fraunhofer.de>
Subject: Re: [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32
Date: Wed, 29 Dec 2021 17:23:10 +0800 [thread overview]
Message-ID: <20211229092310.GA1314619@atcsi01> (raw)
In-Reply-To: <20211221233253.123268-1-wxjstz@126.com>
Hi Xiang,
On Wed, Dec 22, 2021 at 07:32:53AM +0800, Xiang W wrote:
> Various specifications of riscv allow the number of hart to be
> greater than 32. The limit of 32 is determined by
> gd->arch.available_harts. We can eliminate this limitation through
> bitmaps. Currently, the number of hart is limited to 4095, and 4095
> is the limit of the RISC-V Advanced Core Local Interruptor
> Specification.
>
> Test on sifive unmatched.
>
> Signed-off-by: Xiang W <wxjstz@126.com>
> ---
> Changes since v1:
>
> * When NR_CPUS is very large, the value of GD_AVAILABLE_HARTS will
> overflow the immediate range of ld/lw. This patch fixes this
> problem
>
> arch/riscv/Kconfig | 4 ++--
> arch/riscv/cpu/start.S | 21 ++++++++++++++++-----
> arch/riscv/include/asm/global_data.h | 4 +++-
> arch/riscv/lib/smp.c | 2 +-
> 4 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 76850ec9be..92f3b78f29 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -166,11 +166,22 @@ wait_for_gd_init:
> mv gp, s0
>
> /* register available harts in the available_harts mask */
> - li t1, 1
> - sll t1, t1, tp
> - LREG t2, GD_AVAILABLE_HARTS(gp)
> - or t2, t2, t1
> - SREG t2, GD_AVAILABLE_HARTS(gp)
> + li t1, GD_AVAILABLE_HARTS
> + add t1, t1, gp
> + LREG t1, 0(t1)
> +#if defined(CONFIG_ARCH_RV64I)
> + srli t2, tp, 6
> + slli t2, t2, 3
> +#elif defined(CONFIG_ARCH_RV32I)
> + srli t2, tp, 5
> + slli t2, t2, 2
> +#endif
> + add t1, t1, t2
> + LREG t2, 0(t1)
> + li t3, 1
> + sll t3, t3, tp
This seems incorrect.
Shouldn't we have "$tp % sizeof(ulong)" instead of "$tp / sizeof(ulong)" ?
> + or t2, t2, t3
> + SREG t2, 0(t1)
>
> amoswap.w.rl zero, zero, 0(t0)
Best regards,
Leo
next prev parent reply other threads:[~2021-12-29 9:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 23:32 [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32 Xiang W
2021-12-29 9:23 ` Leo Liang [this message]
2021-12-29 17:55 ` Xiang W
2022-01-03 11:11 ` Leo Liang
2023-02-03 14:24 ` David Abdurachmanov
2023-02-06 8:07 ` Leo Liang
2023-02-10 7:25 ` Leo Liang
2023-02-11 14:11 ` Xiang W
2023-02-13 8:46 ` Leo Liang
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=20211229092310.GA1314619@atcsi01 \
--to=ycliang@andestech.com \
--cc=anup.patel@wdc.com \
--cc=atish.patra@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=lukas.auer@aisec.fraunhofer.de \
--cc=rick@andestech.com \
--cc=u-boot@lists.denx.de \
--cc=wxjstz@126.com \
/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