From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 79F40C433F5 for ; Wed, 29 Dec 2021 17:56:01 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5B0DF82EC6; Wed, 29 Dec 2021 18:55:58 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=126.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=126.com header.i=@126.com header.b="FwNeVbWD"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 06A7282F70; Wed, 29 Dec 2021 18:55:57 +0100 (CET) Received: from mail-m963.mail.126.com (mail-m963.mail.126.com [123.126.96.3]) by phobos.denx.de (Postfix) with ESMTP id B16F682C6D for ; Wed, 29 Dec 2021 18:55:52 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=126.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=wxjstz@126.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Subject:From:Date:MIME-Version; bh=JlJOv 7V85k558QLywKt/xCpx9F7xedTiyjN4x1ByO3w=; b=FwNeVbWDV2ATRn75+KaMO +IuvP+OXF39AtxhV0WPnsY8aEPxhQiVfyAKbg3rTU9OppB8lu9LzIg3+ow8vIdAh YeZ8nxEf1IlQkhvtTwoVTCLgGG00Laj6Wh1zv31BeqsRTllabo1fsi690xE8ugEr QuQaVTTfIebw0RojICZFF8= Received: from [127.0.0.1] (unknown [58.247.180.72]) by smtp8 (Coremail) with SMTP id NORpCgDnLTQDocxhN7MPBQ--.54091S2; Thu, 30 Dec 2021 01:55:16 +0800 (CST) Message-ID: Subject: Re: [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32 From: Xiang W To: Leo Liang 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 Date: Thu, 30 Dec 2021 01:55:15 +0800 In-Reply-To: <20211229092310.GA1314619@atcsi01> References: <20211221233253.123268-1-wxjstz@126.com> <20211229092310.GA1314619@atcsi01> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: NORpCgDnLTQDocxhN7MPBQ--.54091S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7Kw48KryxJF4Dtw1furWruFg_yoW5Jry5p3 yxC3Z5Ka90qry2v3WSvF18ur15trn5WF1SvrW7ZryUGrZrWryjqF93tFWUJF9Fkry8Aw40 ywn5uF95urs5AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jsF4_UUUUU= X-Originating-IP: [58.247.180.72] X-CM-SenderInfo: pz0m23b26rjloofrz/1tbi2QR4OlpEDI-DIwAAsi X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean 在 2021-12-29星期三的 17:23 +0800，Leo Liang写道： > 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 > > --- > > 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)" ? Do you meening: "$tp % sizeof(ulong)" instead of "$tp" ? There is such a description in the riscv specification： SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register rs1 by the shift amount held in the lower 5 bits of register rs2. SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register rs1 by the shift amount held in register rs2. In RV64I, only the low 6 bits of rs2 are considered for the shift amount. So we don’t need to perform the remainder operation. regards， Xiang W > > +       or      t2, t2, t3 > > +       SREG    t2, 0(t1) > >   > >         amoswap.w.rl zero, zero, 0(t0) > Best regards, > Leo