Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp758201rwb; Thu, 12 Jan 2023 11:57:00 -0800 (PST) X-Google-Smtp-Source: AMrXdXuGAuOGShkCq6a+OFen8GyLoPs7NBBHgvZBNDg9KT7+JiqbkG7t1A4WVzgQnpJbPpwkdM8i X-Received: by 2002:a17:906:258b:b0:7b4:edca:739 with SMTP id m11-20020a170906258b00b007b4edca0739mr634251ejb.5.1673553420246; Thu, 12 Jan 2023 11:57:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673553420; cv=none; d=google.com; s=arc-20160816; b=hnOVjwdWwMRbWuw5JXSdsR9NdrZTLV+bftCdav7Ar/U+XcEtG+LbOTzlWbJr3th1Wj 6ZSa+Zw/AErEX/b9AvYkVsHQd+rB3gaO3Lqq4zt5Av+VJJn/9IKBsn57DaZtNFNy1KPJ IZxI5POwfikfYc/KPP5ZBxlsrlMPbWsMgHFCTOO80/uoMFFftNSpBfe4CPgCZo/EaKAR Go+zPvEaUV+1Jsr+rlp5apbeckM+mjjs8NiuQZP1Awqo8w2zjqqgx5MvYM2m52l7yKoA Z29PGKuNPrKqihY3qtPjOXlYIPWzj/n3CBdZyoPKbra49XW0MJkJGO6wT3eqyQ/vrMEc LHtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=imZPqnzDLF2i+5vb28S1oLdL2hZHuB+mTkpveovIShk=; b=oqCf1DMNZefL/p2shl+Br68H51Euvj9b11hvEOyHRJbf9My5YTs7yoy6HahLh4g37w l0aldY5gWCI2bXMEQreyO24KKpW2X2r2rSG4EkFen+6n2AWWdERe3T4GpaEPlOYgvKbx VlWK32xiyePqj9O08v9KQIyHROq3DI40gCfwCc9885pTSBrmXkmB4oOTZz5uDQcioAfg xZ6ZCLVKALRwAmJPlzipTEwlSbIBrQteC10mNNdLV9a8jHBPJ8jJGRnt91MvaZGFX2E1 gwlCHD+MyJncJVrH9ADMUp7mYOfVDiDVzZBjuYjePxS30LsvHSOi+9zD8GmhQjnXrjlg bLyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=8VPUwINS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-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 mp26-20020a1709071b1a00b0084cd1ecf338si13312887ejc.705.2023.01.12.11.56.48; Thu, 12 Jan 2023 11:57:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=8VPUwINS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232125AbjALSp0 (ORCPT + 50 others); Thu, 12 Jan 2023 13:45:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234657AbjALSpA (ORCPT ); Thu, 12 Jan 2023 13:45:00 -0500 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3065B10BD for ; Thu, 12 Jan 2023 10:18:17 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id c85so11127452pfc.8 for ; Thu, 12 Jan 2023 10:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=imZPqnzDLF2i+5vb28S1oLdL2hZHuB+mTkpveovIShk=; b=8VPUwINSyiSI8p+IdNef4gnXqazXTASW8rBSVLlDYvmPraC9doolFMbw3zp/AJjK6m Rf7FeuSH8EFiRzhi8a2coSTBWG6ltnJghPB4eoWhm645OGLNdAbbP0i3HCo+H7/+/R+h +3QmsyeDcsezIxnvJ/Bux8S2zdsvWQBPmE1Z2/XCBemjEz1NAd1qMe6yF7K4ormQQJwm nVWCX4gWlYISWrLoo03A7nPZIkgjtpVyNAZOZJ3PKyvMPuz6/ibPdUHSXJaVI5Mokhdb FOFv8/88KlRvqTyZaxBzoOcZ7KQWg6A/RhfCMAXEySD2Num6gP/vrdCa/hkP0F5cLPx5 +jIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=imZPqnzDLF2i+5vb28S1oLdL2hZHuB+mTkpveovIShk=; b=k0z27XRu+0HKoesDjMGUJTKBCOAfAzcYtuviu9wV8ApL2nrNd6RiokNiIqIFn6DAHh t7cD35tIsaHgjw4XUU1jRPLFC+w4oBx1cy1gzXKvIKfO/vJUe4RdnXgwxCZ+wD9josqr QL2RFCFv84xRAKY71LgYRX9WGhhZa/1SXfLVGRnC2V6aIB39/4N9kzH02m85HeF/L+pz z9wtApNNZTaz+FJDtlZJ9DSNQK3/BkDt0dAmxJun+58ImYQhCvZz0iQauioC62pywKsf ii+Kned7Ssk9XWd7e12GxTlVDo9QJo2ABgw84GSyJUVb/imgLaDPijYOyvQNgawgtuFN /y0w== X-Gm-Message-State: AFqh2koi8aPD8fQUCaPsv9kIUvWcCTiwPFX8h325LKns+6FPoxcyzVDx XWzf7QDg/siTLhHh0Em9tjHGETCgqUfsmZDrEvOqLA== X-Received: by 2002:a63:d902:0:b0:490:597e:1c0a with SMTP id r2-20020a63d902000000b00490597e1c0amr3599808pgg.309.1673547496600; Thu, 12 Jan 2023 10:18:16 -0800 (PST) MIME-Version: 1.0 References: <20221215170046.2010255-1-atishp@rivosinc.com> <20221215170046.2010255-2-atishp@rivosinc.com> <20230112100608.d7tnvhbotjfctlgk@orel> In-Reply-To: <20230112100608.d7tnvhbotjfctlgk@orel> From: Atish Kumar Patra Date: Thu, 12 Jan 2023 10:18:05 -0800 Message-ID: Subject: Re: [PATCH v2 01/11] RISC-V: Define helper functions expose hpm counter width and count To: Andrew Jones Cc: linux-kernel@vger.kernel.org, Anup Patel , Atish Patra , Guo Ren , kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-riscv@lists.infradead.org, Mark Rutland , Palmer Dabbelt , Paul Walmsley , Sergey Matyukevich , Eric Lin , Will Deacon Content-Type: text/plain; charset="UTF-8" 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 autolearn=ham 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-kernel@vger.kernel.org On Thu, Jan 12, 2023 at 2:06 AM Andrew Jones wrote: > > On Thu, Dec 15, 2022 at 09:00:36AM -0800, Atish Patra wrote: > > KVM module needs to know how many hardware counters and the counter > > width that the platform supports. Otherwise, it will not be able to show > > optimal value of virtual counters to the guest. The virtual hardware > > counters also need to have the same width as the logical hardware > > counters for simplicity. However, there shouldn't be mapping between > > virtual hardware counters and logical hardware counters. As we don't > > support hetergeneous harts or counters with different width as of now, > > the implementation relies on the counter width of the first available > > programmable counter. > > > > Signed-off-by: Atish Patra > > --- > > drivers/perf/riscv_pmu_sbi.c | 35 +++++++++++++++++++++++++++++++++- > > include/linux/perf/riscv_pmu.h | 3 +++ > > 2 files changed, 37 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c > > index 3852c18..65d4aa4 100644 > > --- a/drivers/perf/riscv_pmu_sbi.c > > +++ b/drivers/perf/riscv_pmu_sbi.c > > @@ -49,6 +49,9 @@ static const struct attribute_group *riscv_pmu_attr_groups[] = { > > static union sbi_pmu_ctr_info *pmu_ctr_list; > > static unsigned int riscv_pmu_irq; > > > > +/* Cache the available counters in a bitmask */ > > +unsigned long cmask; > > I presume this can be static since it's not getting added to the header. > And don't we need this to be a long long for rv32? We should probably > just use u64. > Yeah. u64 would be better. I will change it along with static. Thanks. > > + > > struct sbi_pmu_event_data { > > union { > > union { > > @@ -264,6 +267,37 @@ static bool pmu_sbi_ctr_is_fw(int cidx) > > return (info->type == SBI_PMU_CTR_TYPE_FW) ? true : false; > > } > > > > +/* > > + * Returns the counter width of a programmable counter and number of hardware > > + * counters. As we don't support heterneous CPUs yet, it is okay to just > > heterogeneous > Fixed. > > + * return the counter width of the first programmable counter. > > + */ > > +int riscv_pmu_get_hpm_info(u32 *hw_ctr_width, u32 *num_hw_ctr) > > +{ > > + int i; > > + union sbi_pmu_ctr_info *info; > > + u32 hpm_width = 0, hpm_count = 0; > > + > > + if (!cmask) > > + return -EINVAL; > > + > > + for_each_set_bit(i, &cmask, RISCV_MAX_COUNTERS) { > > + info = &pmu_ctr_list[i]; > > + if (!info) > > + continue; > > + if (!hpm_width && (info->csr != CSR_CYCLE) && (info->csr != CSR_INSTRET)) > > nit: No need for () around the != expressions > Fixed. > > + hpm_width = info->width; > > + if (info->type == SBI_PMU_CTR_TYPE_HW) > > + hpm_count++; > > + } > > + > > + *hw_ctr_width = hpm_width; > > + *num_hw_ctr = hpm_count; > > + > > + return 0; > > +} > > +EXPORT_SYMBOL(riscv_pmu_get_hpm_info); > > EXPORT_SYMBOL_GPL ? > Is that mandatory ? I have seen usage of both in arch/riscv and other places though. I am also not sure if any other non-GPL module should/need access to this. > > + > > static int pmu_sbi_ctr_get_idx(struct perf_event *event) > > { > > struct hw_perf_event *hwc = &event->hw; > > @@ -798,7 +832,6 @@ static void riscv_pmu_destroy(struct riscv_pmu *pmu) > > static int pmu_sbi_device_probe(struct platform_device *pdev) > > { > > struct riscv_pmu *pmu = NULL; > > - unsigned long cmask = 0; > > int ret = -ENODEV; > > int num_counters; > > > > diff --git a/include/linux/perf/riscv_pmu.h b/include/linux/perf/riscv_pmu.h > > index e17e86a..a1c3f77 100644 > > --- a/include/linux/perf/riscv_pmu.h > > +++ b/include/linux/perf/riscv_pmu.h > > @@ -73,6 +73,9 @@ void riscv_pmu_legacy_skip_init(void); > > static inline void riscv_pmu_legacy_skip_init(void) {}; > > #endif > > struct riscv_pmu *riscv_pmu_alloc(void); > > +#ifdef CONFIG_RISCV_PMU_SBI > > +int riscv_pmu_get_hpm_info(u32 *hw_ctr_width, u32 *num_hw_ctr); > > +#endif > > > > #endif /* CONFIG_RISCV_PMU */ > > > > -- > > 2.25.1 > > > > Thanks, > drew