Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1227007rwr; Wed, 26 Apr 2023 11:45:48 -0700 (PDT) X-Google-Smtp-Source: AKy350aKXB0B3uNVCaxqql+ePwBViedibhCsfazdj0CAnGoVf+PIhWkiVCYkICnN6pp3xHN6Byw4 X-Received: by 2002:a17:902:e852:b0:1a9:4b42:a5a2 with SMTP id t18-20020a170902e85200b001a94b42a5a2mr22402757plg.0.1682534748305; Wed, 26 Apr 2023 11:45:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682534748; cv=none; d=google.com; s=arc-20160816; b=vscNTfAEiJ+rWseldSW2RdXLjVoUi3AVheaNASUG+mHalfF3OC9vOjceUdfaSsFKNJ GYO+izT70E7DlE4YjngqlvH+xahP0fH7symCMeemso0lMnNCnAs9oj4fatl+/Lh+G44Z cBt1oqyBO9IhdRjRjKTgxKt+Q8ETPRSOjZSe4SNFPjQv0tWNLiBE/BzIDx3J52Qreqea +MUqVJXLJkl4FI/WemFNH0vHQ2wW4cX5CVE2oErFTZBqavCxCiE45xf19UQf8Tbq2bg9 xMdMxIGnDJN9vHXRpjiGTdtdNEo0yhwABSTx4YuvScztVvL6DQc1XH5h0wIACIulu2/Y aUsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=39lPpeZJ6Vfq5QIqd0kQjSRRWCoPA/qmtkXRKTNu56g=; b=JKZKcCkVqxOtlIlNmnJYJoxFJbBnV2agw/8Qut3gOlrpJGZU+/SF3agDYlX/AuKJ4U 55r5Epf0rs3FLWlqsX7GNXj2rsoY/cEZecONDt6ntw4Wh7t8k7pNtSTpUj4PYPoW9NKu 9BdOLNWYpGi+wtfUrsC6Q9WEwatiaWGxsgUK6S+5Nom0km+JFis845BbFub+STiVyqS2 p18SrgGhv+F2U9cNWPyAjHLywoLllDQnNT1a2+vOHHlePcFe2jUEleT6quPCiOQ2xXtW 8wdXqhmJeeCT6amwLe9kjO62x+mKdtoyDxQqvrQGDavE7sxXBohuRrmPgJv1mb7B5IS+ OoYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dabbelt-com.20221208.gappssmtp.com header.s=20221208 header.b=0cTuHZsz; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h6-20020a170902680600b001a63b9bfd62si15859764plk.461.2023.04.26.11.45.32; Wed, 26 Apr 2023 11:45:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@dabbelt-com.20221208.gappssmtp.com header.s=20221208 header.b=0cTuHZsz; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234827AbjDZSpN (ORCPT + 99 others); Wed, 26 Apr 2023 14:45:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235048AbjDZSpH (ORCPT ); Wed, 26 Apr 2023 14:45:07 -0400 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E50086A0 for ; Wed, 26 Apr 2023 11:45:02 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-2478485fd76so5178589a91.2 for ; Wed, 26 Apr 2023 11:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20221208.gappssmtp.com; s=20221208; t=1682534701; x=1685126701; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=39lPpeZJ6Vfq5QIqd0kQjSRRWCoPA/qmtkXRKTNu56g=; b=0cTuHZsz+N1jNTSkL1VOEIXLta2nzIDK/QbZnIPF852eIN4/wy+BhVCrhX+aN/xiWq Pv8Xl1lrAsfRMHTAPqE0dD2zudgK+WM13ls67lFNlX2d9l7OHYZ0my8/qgS+OpPBbXS+ 2z+QXiSeWX2lV416QR2qREaa5lGfE5QamuUn4krS9vrilqtLpmfxdn0+t3ARTYK7nKRN +YoiaJhWjD93At8jHJYvd1pLLZRfh1qnpcxcZsNNeup01xnSGt1p/Yo4ruFnF3NuZSlO Cv4D/kiEjyEGrSlEa/CD8W0PXqoIgw5IzxsUfdFzP16WeBAlKG6nQHZfXug9NKXds/tk Supg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682534701; x=1685126701; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=39lPpeZJ6Vfq5QIqd0kQjSRRWCoPA/qmtkXRKTNu56g=; b=IuaTQfiOMmXuKIqDHVN4spbEGGD/ZxFpuxW5YoTh+KD/NPWx73DSdF82MYqWCqaEzS uavx3VqMxWPUYvXAX8+Kw5e45D9Qacjr/1pRRMSggUm0YihGoem1pLbI5ZhbGN7N9GPd CkffUNM0qxU6MwzK+8GgYLB20dKpTowLschT+zcmW381m9kk6BcQbTO48ROH8sQUlzSx OZDcWDfIwdAhSy7V9yGhfHT1vDEXIt0NcZB81qEvETHjrgITs9EyqbmFHiy+VDZDIcQF k0HTqSaeXaEsStyQ7oikDyE8xn1vbdm96jnG8oGpSbhMW39nip3OkHLqxtN8qwV4c/1S 84xw== X-Gm-Message-State: AAQBX9c8RcIGR44jj5NygmnUktMXCyNKNyklBTtrkjwKeZfvxMOg46KK bgR8NTykBFmcW11S+9ZObifZYg== X-Received: by 2002:a17:90b:4b0b:b0:240:9bf7:8df2 with SMTP id lx11-20020a17090b4b0b00b002409bf78df2mr23207939pjb.37.1682534701381; Wed, 26 Apr 2023 11:45:01 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id u5-20020a17090ae00500b002467717fa60sm10261751pjy.16.2023.04.26.11.45.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 11:45:00 -0700 (PDT) Date: Wed, 26 Apr 2023 11:45:00 -0700 (PDT) X-Google-Original-Date: Wed, 26 Apr 2023 11:38:37 PDT (-0700) Subject: Re: [PATCH V4 08/23] RISC-V: ACPI: Cache and retrieve the RINTC structure In-Reply-To: <20230404182037.863533-9-sunilvl@ventanamicro.com> CC: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-acpi@vger.kernel.org, linux-crypto@vger.kernel.org, platform-driver-x86@vger.kernel.org, llvm@lists.linux.dev, corbet@lwn.net, Paul Walmsley , aou@eecs.berkeley.edu, lenb@kernel.org, daniel.lezcano@linaro.org, tglx@linutronix.de, qianweili@huawei.com, wangzhou1@hisilicon.com, herbert@gondor.apana.org.au, Marc Zyngier , luzmaximilian@gmail.com, hdegoede@redhat.com, markgross@kernel.org, nathan@kernel.org, ndesaulniers@google.com, trix@redhat.com, rafael@kernel.org, davem@davemloft.net, sunilvl@ventanamicro.com, rafael.j.wysocki@intel.com From: Palmer Dabbelt To: sunilvl@ventanamicro.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, 04 Apr 2023 11:20:22 PDT (-0700), sunilvl@ventanamicro.com wrote: > RINTC structures in the MADT provide mapping between the hartid > and the CPU. This is required many times even at run time like > cpuinfo. So, instead of parsing the ACPI table every time, cache > the RINTC structures and provide a function to get the correct > RINTC structure for a given cpu. > > Signed-off-by: Sunil V L > Acked-by: Rafael J. Wysocki > --- > arch/riscv/include/asm/acpi.h | 2 ++ > arch/riscv/kernel/acpi.c | 60 +++++++++++++++++++++++++++++++++++ > 2 files changed, 62 insertions(+) > > diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h > index 9be52b6ffae1..1606dce8992e 100644 > --- a/arch/riscv/include/asm/acpi.h > +++ b/arch/riscv/include/asm/acpi.h > @@ -59,6 +59,8 @@ static inline bool acpi_has_cpu_in_madt(void) > > static inline void arch_fix_phys_package_id(int num, u32 slot) { } > > +struct acpi_madt_rintc *acpi_cpu_get_madt_rintc(int cpu); > +u32 get_acpi_id_for_cpu(int cpu); > #endif /* CONFIG_ACPI */ > > #endif /*_ASM_ACPI_H*/ > diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c > index 81d448c41714..40ab55309c70 100644 > --- a/arch/riscv/kernel/acpi.c > +++ b/arch/riscv/kernel/acpi.c > @@ -24,6 +24,66 @@ EXPORT_SYMBOL(acpi_disabled); > int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */ > EXPORT_SYMBOL(acpi_pci_disabled); > > +static struct acpi_madt_rintc cpu_madt_rintc[NR_CPUS]; > + > +static int acpi_parse_madt_rintc(union acpi_subtable_headers *header, const unsigned long end) > +{ > + struct acpi_madt_rintc *rintc = (struct acpi_madt_rintc *)header; > + int cpuid; > + > + if (!(rintc->flags & ACPI_MADT_ENABLED)) > + return 0; > + > + cpuid = riscv_hartid_to_cpuid(rintc->hart_id); Unless I'm missing something, this races with CPUs coming online. Maybe that's a rare enough case we don't care, but I think we'd also just have simpler logic if we fixed it... > + /* > + * When CONFIG_SMP is disabled, mapping won't be created for > + * all cpus. > + * CPUs more than NR_CPUS, will be ignored. > + */ > + if (cpuid >= 0 && cpuid < NR_CPUS) > + cpu_madt_rintc[cpuid] = *rintc; > + > + return 0; > +} > + > +static int acpi_init_rintc_array(void) > +{ > + if (acpi_table_parse_madt(ACPI_MADT_TYPE_RINTC, acpi_parse_madt_rintc, 0) > 0) > + return 0; > + > + return -ENODEV; > +} > + > +/* > + * Instead of parsing (and freeing) the ACPI table, cache > + * the RINTC structures since they are frequently used > + * like in cpuinfo. > + */ > +struct acpi_madt_rintc *acpi_cpu_get_madt_rintc(int cpu) > +{ > + static bool rintc_init_done; ... basically just get rid of this global variable, and instead have a if (!&cpu_madt_rintc[cpu]) ... parse ... return &cpu_madt_rintc[cpu]; that'd probably let us get rid of a handful of these helpers too, as now it's just a call to the parsing bits. > + > + if (!rintc_init_done) { > + if (acpi_init_rintc_array()) { > + pr_err("No valid RINTC entries exist\n"); > + return NULL; > + } > + > + rintc_init_done = true; > + } > + > + return &cpu_madt_rintc[cpu]; > +} > + > +u32 get_acpi_id_for_cpu(int cpu) > +{ > + struct acpi_madt_rintc *rintc = acpi_cpu_get_madt_rintc(cpu); > + > + BUG_ON(!rintc); We should have some better error reporting here. It looks like all the callerss of get_acpi_id_for_cpu() are tolerant of a nonsense ID being returned, so maybe we just pr_warn() something users can understand and then return -1 or something? > + > + return rintc->uid; > +} > + > /* > * __acpi_map_table() will be called before paging_init(), so early_ioremap() > * or early_memremap() should be called here to for ACPI table mapping.