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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC9C1C433F5 for ; Mon, 13 Dec 2021 21:27:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243120AbhLMV1e (ORCPT ); Mon, 13 Dec 2021 16:27:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234055AbhLMV1d (ORCPT ); Mon, 13 Dec 2021 16:27:33 -0500 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2887C061574 for ; Mon, 13 Dec 2021 13:27:32 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id v138so41595415ybb.8 for ; Mon, 13 Dec 2021 13:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atishpatra.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tS/h42aoWNvC9F09YRt3IPscSl6Go2TabGZNpFMjr1Q=; b=SqJqF6KfjAHG+SeRMuPoCEqf0e/o/Y+PV6/bBLvnCli36DmKOoeFeyh6z46zS/SaE9 BRRHa/3ViRSvPyYD/GxN0Ze6zMSmy0gkyS8R9ezmn/5L+88Cc8V+c2hb8Rr+y3XFKa20 qhUqUlPVqlyvZv4YvFxzWzKGuZjj4iwQBmFoo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tS/h42aoWNvC9F09YRt3IPscSl6Go2TabGZNpFMjr1Q=; b=6ehW62wXIhKya1kn0HBYvbMk8X6r2MoaHt/wAs4eBWv4r2FYqQQmpHYP8jsPGPY9kL glswzIlW2O/RvxcnUUJK/3eCgkf9MSoiImJ9eS16I4Ayyr56muyALdh2YyJcyBzxeXnx vE3Yg68DUoV7rqYecSnqGnBmTiry5XdVz+nowKCptKyg76o6/XgxRCkWPm58GsAxK6RS bwiUMhnvbDn15U4m4YufGD+qqcAQ8m2SvsFtc/ZTiGWhoQjwrLQA7ZOMyLfgOCBQ5yGP yQtfiPd8JKRhxZ4WXHsuxZw64pEmBC53GQTTlsaioet2XszOn5evZstQicEetRIDIwjk Qu+Q== X-Gm-Message-State: AOAM530NolJDzT6sSiFri1DYOCgBqqZMtXGNLH6FoRB/UZgHlizUC1NH BIwJBUPn2DbDoOVkxGZJa5iKxisKarYOcj+dmdWi X-Google-Smtp-Source: ABdhPJzslT8/6oXCsZUd9W7eJu9fAn0X/Rv9oKsdYACWvB/fLMbHtNl1F6uZ+CVQ9FJUh+Dwghg2dQVRfT2vBmV5zUg= X-Received: by 2002:a25:bf8d:: with SMTP id l13mr1136880ybk.713.1639430852154; Mon, 13 Dec 2021 13:27:32 -0800 (PST) MIME-Version: 1.0 References: <20211204002038.113653-1-atishp@atishpatra.org> In-Reply-To: From: Atish Patra Date: Mon, 13 Dec 2021 13:27:21 -0800 Message-ID: Subject: Re: [RFC 0/6] Sparse HART id support To: Rob Herring Cc: "linux-kernel@vger.kernel.org List" , Alexandre Ghiti , Anup Patel , Greentime Hu , Guo Ren , Heinrich Schuchardt , Ingo Molnar , Jisheng Zhang , kvm-riscv@lists.infradead.org, KVM General , linux-riscv , Marc Zyngier , Nanyong Sun , Nick Kossifidis , Palmer Dabbelt , Paul Walmsley , Pekka Enberg , Vincent Chen , Vitaly Wool Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 6, 2021 at 7:28 AM Rob Herring wrote: > > 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? Yes. We can move the cpu_logical_map(which is a macro) & __cpu_logical_map(actual array with NR_CPUS size) to common code so that all the architecture can use it instead of defining it separately. > That would also possibly allow for common populating the map from DT. > I didn't understand this part. The mapping is populated at run time [1] as the boot cpu can be any hart in RISC-V. That booting hart will be mapped to cpu 0. All others will be mapped based on how the cpu node is laid out in the DT. Do you mean we can move the 2nd part to common code as well ? [1] RISC-V: https://elixir.bootlin.com/linux/v5.16-rc5/source/arch/riscv/kernel/smpboot.c#L102 > Rob -- Regards, Atish