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 X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 981FFC433ED for ; Thu, 15 Apr 2021 10:42:09 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 108DC6124B for ; Thu, 15 Apr 2021 10:42:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 108DC6124B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 889E84B642; Thu, 15 Apr 2021 06:42:08 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBTImwjrS8Ld; Thu, 15 Apr 2021 06:42:06 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8F3274B63A; Thu, 15 Apr 2021 06:42:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 643584B4D4 for ; Thu, 15 Apr 2021 06:42:05 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88Mq1JATnSsT for ; Thu, 15 Apr 2021 06:42:04 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 2579B4B642 for ; Thu, 15 Apr 2021 06:42:04 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2B0E860C41; Thu, 15 Apr 2021 10:42:03 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lWzRh-007cZw-9M; Thu, 15 Apr 2021 11:42:01 +0100 Date: Thu, 15 Apr 2021 11:42:00 +0100 Message-ID: <87h7k7n81z.wl-maz@kernel.org> From: Marc Zyngier To: Keqian Zhu Subject: Re: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile helpers In-Reply-To: References: <20210414134409.1266357-1-maz@kernel.org> <20210414134409.1266357-2-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: zhukeqian1@huawei.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, dalias@libc.org, ysato@users.sourceforge.jp, peterz@infradead.org, viresh.kumar@linaro.org, hca@linux.ibm.com, acme@kernel.org, nathan@kernel.org, borntraeger@de.ibm.com, kernel-team@android.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: linux-s390@vger.kernel.org, Rich Felker , Yoshinori Sato , kvm@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Viresh Kumar , Heiko Carstens , linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , nathan@kernel.org, Christian Borntraeger , Will Deacon , kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, 15 Apr 2021 07:59:26 +0100, Keqian Zhu wrote: > > Hi Marc, > > On 2021/4/14 21:44, Marc Zyngier wrote: > > KVM/arm64 is the sole user of perf_num_counters(), and really > > could do without it. Stop using the obsolete API by relying on > > the existing probing code. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/perf.c | 7 +------ > > arch/arm64/kvm/pmu-emul.c | 2 +- > > include/kvm/arm_pmu.h | 4 ++++ > > 3 files changed, 6 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c > > index 739164324afe..b8b398670ef2 100644 > > --- a/arch/arm64/kvm/perf.c > > +++ b/arch/arm64/kvm/perf.c > > @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = { > > > > int kvm_perf_init(void) > > { > > - /* > > - * Check if HW_PERF_EVENTS are supported by checking the number of > > - * hardware performance counters. This could ensure the presence of > > - * a physical PMU and CONFIG_PERF_EVENT is selected. > > - */ > > - if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0) > > + if (kvm_pmu_probe_pmuver() != 0xf) > The probe() function may be called many times > (kvm_arm_pmu_v3_set_attr also calls it). I don't know whether the > first calling is enough. If so, can we use a static variable in it, > so the following calling can return the result right away? No, because that wouldn't help with crappy big-little implementations that could have PMUs with different versions. We want to find the version at the point where the virtual PMU is created, which is why we call the probe function once per vcpu. This of course is broken in other ways (BL+KVM is a total disaster when it comes to PMU), but making this static would just make it worse. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6488C433B4 for ; Thu, 15 Apr 2021 10:43:50 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5A748611F1 for ; Thu, 15 Apr 2021 10:43:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A748611F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:Cc:To: From:Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5QjSdiht3FSfBseYIPwCUhqbemdRAYdjOnZS0HNc4ng=; b=HVej4Ujxy17nIUGSZ2yEMS6v9 lCFZFx65JieI6NYnefObnnA3mAAnw8PhFbEW8C0WtStpra9r1VmwhhS3uc/MjbWWMkoZdFwQ3O6Oi dywLDOm1WCYTW+CU5U8yxfmJU809Vtx/rzWU0EVQZPkukz5+ujWj2QGoLXriz8spU69IMRCgRImd9 7KD1NALcfsSi/16hubDxUme62JRgGwPa5+hZBzW1LIWaO1dvDGNk+xGcPozA1VXCtxh945vyQFyzr WvKhdVKgvSOcNqersTYGPE1w9slkYN/v/ZvOo6O7uCTcWoCOFFq+R+a+5m8JX2daETWlXOZpOaQIr nTidUxgpw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lWzRt-00Flsz-6O; Thu, 15 Apr 2021 10:42:13 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lWzRm-00Fls3-D9 for linux-arm-kernel@desiato.infradead.org; Thu, 15 Apr 2021 10:42:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:MIME-Version:References: In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=dbp1SYmiTtSH/0ewhgNAp1ki3xA1Hi0F02ZUrar+khA=; b=mDgdz7qFa55TYg69eRaeFg4g+s EGZYgb+dZGUcMSOwvfN1y29jAPN3JyraSg4dwD32icy4j3pZ2SqG3Tsfbt8Kg/AAM0mjimJV6jwqZ ki9WsYpUAJwtNlEagkPiKeitIZAfUEJy3FO6W5Lk4als+OjTqEuYzOcmNJtNRmkxEjBc7+igwCotW zf5PbiJN58CmKQFo2vikhIzhNW2vs9uiL0WLRoN+EgkUICoO8ucEM9QoMAFpv1abYJb7QGTRATr5+ ZUxblg9Ao38bFTI9Hmp8akYkRN3vpboPyr+CTHJBJsuM51DDFwtoOjwkxinz/T3Yf5k7XDH4tB6ta 6zsN2nGA==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lWzRj-008URJ-Ie for linux-arm-kernel@lists.infradead.org; Thu, 15 Apr 2021 10:42:04 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2B0E860C41; Thu, 15 Apr 2021 10:42:03 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lWzRh-007cZw-9M; Thu, 15 Apr 2021 11:42:01 +0100 Date: Thu, 15 Apr 2021 11:42:00 +0100 Message-ID: <87h7k7n81z.wl-maz@kernel.org> From: Marc Zyngier To: Keqian Zhu Cc: , , , , , , Rich Felker , Yoshinori Sato , Peter Zijlstra , "Viresh\ Kumar" , Heiko Carstens , "Arnaldo Carvalho de Melo" , , "Christian Borntraeger" , , Will Deacon Subject: Re: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile helpers In-Reply-To: References: <20210414134409.1266357-1-maz@kernel.org> <20210414134409.1266357-2-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: zhukeqian1@huawei.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, dalias@libc.org, ysato@users.sourceforge.jp, peterz@infradead.org, viresh.kumar@linaro.org, hca@linux.ibm.com, acme@kernel.org, nathan@kernel.org, borntraeger@de.ibm.com, kernel-team@android.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210415_034203_677939_1AE1577D X-CRM114-Status: GOOD ( 29.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 15 Apr 2021 07:59:26 +0100, Keqian Zhu wrote: > > Hi Marc, > > On 2021/4/14 21:44, Marc Zyngier wrote: > > KVM/arm64 is the sole user of perf_num_counters(), and really > > could do without it. Stop using the obsolete API by relying on > > the existing probing code. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/perf.c | 7 +------ > > arch/arm64/kvm/pmu-emul.c | 2 +- > > include/kvm/arm_pmu.h | 4 ++++ > > 3 files changed, 6 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c > > index 739164324afe..b8b398670ef2 100644 > > --- a/arch/arm64/kvm/perf.c > > +++ b/arch/arm64/kvm/perf.c > > @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = { > > > > int kvm_perf_init(void) > > { > > - /* > > - * Check if HW_PERF_EVENTS are supported by checking the number of > > - * hardware performance counters. This could ensure the presence of > > - * a physical PMU and CONFIG_PERF_EVENT is selected. > > - */ > > - if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0) > > + if (kvm_pmu_probe_pmuver() != 0xf) > The probe() function may be called many times > (kvm_arm_pmu_v3_set_attr also calls it). I don't know whether the > first calling is enough. If so, can we use a static variable in it, > so the following calling can return the result right away? No, because that wouldn't help with crappy big-little implementations that could have PMUs with different versions. We want to find the version at the point where the virtual PMU is created, which is why we call the probe function once per vcpu. This of course is broken in other ways (BL+KVM is a total disaster when it comes to PMU), but making this static would just make it worse. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel