From: Rob Herring <robh@kernel.org>
To: kvm-riscv@lists.infradead.org
Subject: [RFC 0/6] Sparse HART id support
Date: Mon, 6 Dec 2021 09:28:13 -0600 [thread overview]
Message-ID: <Ya4sDX974/dVEOQw@robh.at.kernel.org> (raw)
In-Reply-To: <20211204002038.113653-1-atishp@atishpatra.org>
On Fri, Dec 03, 2021 at 04:20:32PM -0800, Atish Patra wrote:
> Currently, sparse hartid is not supported for Linux RISC-V for the following
> reasons.
> 1. Both spinwait and ordered booting method uses __cpu_up_stack/task_pointer
> which is an array size of NR_CPUs.
> 2. During early booting, any hartid greater than NR_CPUs are not booted at all.
> 3. riscv_cpuid_to_hartid_mask uses struct cpumask for generating hartid bitmap.
> 4. SBI v0.2 implementation uses NR_CPUs as the maximum hartid number while
> generating hartmask.
>
> In order to support sparse hartid, the hartid & NR_CPUS needs to be disassociated
> which was logically incorrect anyways. NR_CPUs represent the maximum logical|
> CPU id configured in the kernel while the hartid represent the physical hartid
> stored in mhartid CSR defined by the privilege specification. Thus, hartid
> can have much greater value than logical cpuid.
We already have a couple of architectures with logical to physical CPU
id maps. See cpu_logical_map. Can we make that common and use it here?
That would also possibly allow for common populating the map from DT.
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Atish Patra <atishp@atishpatra.org>
Cc: linux-kernel@vger.kernel.org, Alexandre Ghiti <alex@ghiti.fr>,
Anup Patel <anup.patel@wdc.com>,
Greentime Hu <greentime.hu@sifive.com>,
Guo Ren <guoren@linux.alibaba.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Ingo Molnar <mingo@kernel.org>,
Jisheng Zhang <jszhang@kernel.org>,
kvm-riscv@lists.infradead.org, kvm@vger.kernel.org,
linux-riscv@lists.infradead.org, Marc Zyngier <maz@kernel.org>,
Nanyong Sun <sunnanyong@huawei.com>,
Nick Kossifidis <mick@ics.forth.gr>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Pekka Enberg <penberg@kernel.org>,
Vincent Chen <vincent.chen@sifive.com>,
Vitaly Wool <vitaly.wool@konsulko.com>
Subject: Re: [RFC 0/6] Sparse HART id support
Date: Mon, 6 Dec 2021 09:28:13 -0600 [thread overview]
Message-ID: <Ya4sDX974/dVEOQw@robh.at.kernel.org> (raw)
In-Reply-To: <20211204002038.113653-1-atishp@atishpatra.org>
On Fri, Dec 03, 2021 at 04:20:32PM -0800, Atish Patra wrote:
> Currently, sparse hartid is not supported for Linux RISC-V for the following
> reasons.
> 1. Both spinwait and ordered booting method uses __cpu_up_stack/task_pointer
> which is an array size of NR_CPUs.
> 2. During early booting, any hartid greater than NR_CPUs are not booted at all.
> 3. riscv_cpuid_to_hartid_mask uses struct cpumask for generating hartid bitmap.
> 4. SBI v0.2 implementation uses NR_CPUs as the maximum hartid number while
> generating hartmask.
>
> In order to support sparse hartid, the hartid & NR_CPUS needs to be disassociated
> which was logically incorrect anyways. NR_CPUs represent the maximum logical|
> CPU id configured in the kernel while the hartid represent the physical hartid
> stored in mhartid CSR defined by the privilege specification. Thus, hartid
> can have much greater value than logical cpuid.
We already have a couple of architectures with logical to physical CPU
id maps. See cpu_logical_map. Can we make that common and use it here?
That would also possibly allow for common populating the map from DT.
Rob
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Atish Patra <atishp@atishpatra.org>
Cc: linux-kernel@vger.kernel.org, Alexandre Ghiti <alex@ghiti.fr>,
Anup Patel <anup.patel@wdc.com>,
Greentime Hu <greentime.hu@sifive.com>,
Guo Ren <guoren@linux.alibaba.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Ingo Molnar <mingo@kernel.org>,
Jisheng Zhang <jszhang@kernel.org>,
kvm-riscv@lists.infradead.org, kvm@vger.kernel.org,
linux-riscv@lists.infradead.org, Marc Zyngier <maz@kernel.org>,
Nanyong Sun <sunnanyong@huawei.com>,
Nick Kossifidis <mick@ics.forth.gr>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Pekka Enberg <penberg@kernel.org>,
Vincent Chen <vincent.chen@sifive.com>,
Vitaly Wool <vitaly.wool@konsulko.com>
Subject: Re: [RFC 0/6] Sparse HART id support
Date: Mon, 6 Dec 2021 09:28:13 -0600 [thread overview]
Message-ID: <Ya4sDX974/dVEOQw@robh.at.kernel.org> (raw)
In-Reply-To: <20211204002038.113653-1-atishp@atishpatra.org>
On Fri, Dec 03, 2021 at 04:20:32PM -0800, Atish Patra wrote:
> Currently, sparse hartid is not supported for Linux RISC-V for the following
> reasons.
> 1. Both spinwait and ordered booting method uses __cpu_up_stack/task_pointer
> which is an array size of NR_CPUs.
> 2. During early booting, any hartid greater than NR_CPUs are not booted at all.
> 3. riscv_cpuid_to_hartid_mask uses struct cpumask for generating hartid bitmap.
> 4. SBI v0.2 implementation uses NR_CPUs as the maximum hartid number while
> generating hartmask.
>
> In order to support sparse hartid, the hartid & NR_CPUS needs to be disassociated
> which was logically incorrect anyways. NR_CPUs represent the maximum logical|
> CPU id configured in the kernel while the hartid represent the physical hartid
> stored in mhartid CSR defined by the privilege specification. Thus, hartid
> can have much greater value than logical cpuid.
We already have a couple of architectures with logical to physical CPU
id maps. See cpu_logical_map. Can we make that common and use it here?
That would also possibly allow for common populating the map from DT.
Rob
next prev parent reply other threads:[~2021-12-06 15:28 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-04 0:20 [RFC 0/6] Sparse HART id support Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-04 0:20 ` [RFC 1/6] RISC-V: Avoid using per cpu array for ordered booting Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-13 12:48 ` Anup Patel
2021-12-13 12:48 ` Anup Patel
2021-12-13 12:48 ` Anup Patel
2021-12-13 21:05 ` Atish Patra
2021-12-13 21:05 ` Atish Patra
2021-12-13 21:05 ` Atish Patra
2021-12-04 0:20 ` [RFC 2/6] RISC-V: Do not print the SBI version during HSM extension boot print Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-13 12:49 ` Anup Patel
2021-12-13 12:49 ` Anup Patel
2021-12-13 12:49 ` Anup Patel
2021-12-04 0:20 ` [RFC 3/6] RISC-V: Use __cpu_up_stack/task_pointer only for spinwait method Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-13 12:50 ` Anup Patel
2021-12-13 12:50 ` Anup Patel
2021-12-13 12:50 ` Anup Patel
2021-12-13 12:59 ` Marc Zyngier
2021-12-13 12:59 ` Marc Zyngier
2021-12-13 12:59 ` Marc Zyngier
2021-12-13 21:12 ` Atish Patra
2021-12-13 21:12 ` Atish Patra
2021-12-13 21:12 ` Atish Patra
2021-12-04 0:20 ` [RFC 4/6] RISC-V: Move the entire hart selection via lottery to SMP Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-13 12:57 ` Anup Patel
2021-12-13 12:57 ` Anup Patel
2021-12-04 0:20 ` [RFC 5/6] RISC-V: Move spinwait booting method to its own config Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-04 0:40 ` Randy Dunlap
2021-12-04 0:40 ` Randy Dunlap
2021-12-04 0:40 ` Randy Dunlap
2021-12-13 13:01 ` Anup Patel
2021-12-13 13:01 ` Anup Patel
2021-12-13 13:01 ` Anup Patel
2021-12-13 21:08 ` Atish Patra
2021-12-13 21:08 ` Atish Patra
2021-12-13 21:08 ` Atish Patra
2021-12-04 0:20 ` [RFC 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-04 0:20 ` Atish Patra
2021-12-06 15:28 ` Rob Herring [this message]
2021-12-06 15:28 ` [RFC 0/6] Sparse HART id support Rob Herring
2021-12-06 15:28 ` Rob Herring
2021-12-13 21:27 ` Atish Patra
2021-12-13 21:27 ` Atish Patra
2021-12-13 21:27 ` Atish Patra
2021-12-13 23:11 ` Rob Herring
2021-12-13 23:11 ` Rob Herring
2021-12-13 23:11 ` Rob Herring
2021-12-14 0:58 ` Atish Patra
2021-12-14 0:58 ` Atish Patra
2021-12-14 0:58 ` Atish Patra
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=Ya4sDX974/dVEOQw@robh.at.kernel.org \
--to=robh@kernel.org \
--cc=kvm-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 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.