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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.