From nobody Sat May 18 21:00:24 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1612982399; cv=none; d=zohomail.com; s=zohoarc; b=CRerQxFP8SE0jTiI0673GshMCFuNKlVFfXHjcT2XzyAv5x6UyPXjuabrJg2Hdwb7IYTDkHxozS0M34wTcGd+yn3uqqcXOXFLT5BTk+oJbsXm24JWGuHCVc5r4Zm4jtivbKpo8DvPE8FPdDPf5x/9GZ0UvYaOP6/ZnG6uO1jIz9I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1612982399; h=Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Sender:Subject:To; bh=eNjsFYwO+tcwntcJ4FGeCgVPTtZNdXtn2p32ocgpeHY=; b=dHwQRr3gFlAtVh77LqFG9K4khDDULzrMlDMjM7iGniZMbciuKLvxpBQnPnzQKSp1680zXrBM2i/CWD7OV3S3u/Fj65USIUkk+aBU8NMoUx4yLFKCQKuN1uMIprnluO7MWA6qZqk8xf4rmCry1u7wQUdI/jOW7w3+zBQC/EFzqSs= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1612982398939493.98204397472705; Wed, 10 Feb 2021 10:39:58 -0800 (PST) Received: from localhost ([::1]:53200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9tr3-0004r9-4h for importer@patchew.org; Wed, 10 Feb 2021 13:04:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60658) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9tkc-0000cR-3f for qemu-devel@nongnu.org; Wed, 10 Feb 2021 12:58:06 -0500 Received: from 66-220-144-178.mail-mxout.facebook.com ([66.220.144.178]:35447) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l9tka-0004BP-IN for qemu-devel@nongnu.org; Wed, 10 Feb 2021 12:58:05 -0500 Received: by devvm1718.prn0.facebook.com (Postfix, from userid 221162) id 46DF4A6F731; Wed, 10 Feb 2021 09:41:27 -0800 (PST) To: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org, peter.maydell@linaro.org, =?UTF-8?q?Daniel=20M=C3=BCller?= Subject: [PATCH v2] target/arm: Correctly initialize MDCR_EL2.HPMN Date: Wed, 10 Feb 2021 09:41:22 -0800 Message-Id: <20210210174122.410690-1-muellerd@fb.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: none client-ip=66.220.144.178; envelope-from=muellerd@devvm1718.prn0.facebook.com; helo=66-220-144-178.mail-mxout.facebook.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_NONE=0.001, TVD_RCVD_IP=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Reply-to: =?UTF-8?q?Daniel=20M=C3=BCller?= From: =?UTF-8?q?Daniel=20M=C3=BCller?= via Content-Type: text/plain; charset="utf-8" When working with performance monitoring counters, we look at MDCR_EL2.HPMN as part of the check whether a counter is enabled. This check fails, because MDCR_EL2.HPMN is reset to 0, meaning that no counters are "enabled" for < EL2. That's in violation of the Arm specification, which states that > On a Warm reset, this field [MDCR_EL2.HPMN] resets to the value in > PMCR_EL0.N That's also what a comment in the code acknowledges, but the necessary adjustment seems to have been forgotten when support for more counters was added. This change fixes the issue by setting the reset value to PMCR.N, which is four. --- target/arm/helper.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/target/arm/helper.c b/target/arm/helper.c index 38cd35c049..4a5d512b51 100644 --- a/target/arm/helper.c +++ b/target/arm/helper.c @@ -37,6 +37,7 @@ #endif =20 #define ARM_CPU_FREQ 1000000000 /* FIXME: 1 GHz, should be configurable */ +#define PMCR_NUM_COUNTERS 4 /* QEMU IMPDEF choice */ =20 #ifndef CONFIG_USER_ONLY =20 @@ -5662,13 +5663,11 @@ static const ARMCPRegInfo el2_cp_reginfo[] =3D { .writefn =3D gt_hyp_ctl_write, .raw_writefn =3D raw_write }, #endif /* The only field of MDCR_EL2 that has a defined architectural reset v= alue - * is MDCR_EL2.HPMN which should reset to the value of PMCR_EL0.N; but= we - * don't implement any PMU event counters, so using zero as a reset - * value for MDCR_EL2 is okay + * is MDCR_EL2.HPMN which should reset to the value of PMCR_EL0.N. */ { .name =3D "MDCR_EL2", .state =3D ARM_CP_STATE_BOTH, .opc0 =3D 3, .opc1 =3D 4, .crn =3D 1, .crm =3D 1, .opc2 =3D 1, - .access =3D PL2_RW, .resetvalue =3D 0, + .access =3D PL2_RW, .resetvalue =3D PMCR_NUM_COUNTERS, .fieldoffset =3D offsetof(CPUARMState, cp15.mdcr_el2), }, { .name =3D "HPFAR", .state =3D ARM_CP_STATE_AA32, .cp =3D 15, .opc1 =3D 4, .crn =3D 6, .crm =3D 0, .opc2 =3D 4, @@ -6566,7 +6565,7 @@ static void define_pmu_regs(ARMCPU *cpu) * field as main ID register, and we implement four counters in * addition to the cycle count register. */ - unsigned int i, pmcrn =3D 4; + unsigned int i, pmcrn =3D PMCR_NUM_COUNTERS; ARMCPRegInfo pmcr =3D { .name =3D "PMCR", .cp =3D 15, .crn =3D 9, .crm =3D 12, .opc1 =3D 0= , .opc2 =3D 0, .access =3D PL0_RW, --=20 2.27.0