From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E840519D8A8 for ; Wed, 20 Nov 2024 09:55:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732096544; cv=none; b=WcxbO67NjLCXVNxijlk/WQJ+PZrAAbf+mVrmUs1NEVsgfCTNK/lysFjYU33T+dbAfOiJTd9CqUiqbA5vKKjpa5phzHNCdQmMy/fnIy+pYyeHcFOE/jQ/quOwMrl0ZTs0L/kFCCELDuit+pELRNrA0RygW0Hd/DvnrA8Mgk8Zi3Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732096544; c=relaxed/simple; bh=XvOnLhCVctZKly7ydYiiYPd4feK/HQNRGFJJzoe/USc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Jmo/gn9wuz8QkCcK6O+z6TAExjFAO9hXBOBm4fqqwheDVppfc5h7o4fYdXe/ueV2DqbxyaP2h/5w5MNIOsJ2XkoTUI6ktvTuxyL2QHeuu2kHJybSrco3wErJDSmfN7Rl/GI526fIzCBw5rFVCUl6xtE0+n1OVCHbeDULrmZGGE8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i2+95qjv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i2+95qjv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 824CBC4CECD; Wed, 20 Nov 2024 09:55:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732096543; bh=XvOnLhCVctZKly7ydYiiYPd4feK/HQNRGFJJzoe/USc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=i2+95qjvtTuWAA1HJnFK1ZBqPxd7LBwGRNNBx2WCdnCvhO6aO5beVhtPEbs96zX7L Ie2MWZP0v5tRK7oCFCoJvP8dMekw4L3rNWDNeJPhHjVEwd3F2C1npU+AIx84HfQi3C khKa3DEOsNc0WpTsA9XErgnwgv0aWsZypcM1t+ODPMYQ9zt6P8EhXjBCHZ9ByalU+U xX2f6/P5NAtZLPzYwoyIrxY/I0TgDd4rk+rs/nMfhvdK91YpU6Nd3ewsDG2GbKyGQB ECVEUtKqyEDmaCa0cWnrtRY3H1nJLtGibgzcRdrnQaT3Wrs9/xnOkI9hi1FvfoFcOT CaMik3JhVPVmQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tDhQz-00EQWI-2o; Wed, 20 Nov 2024 09:55:41 +0000 Date: Wed, 20 Nov 2024 09:55:40 +0000 Message-ID: <86sermut43.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, Joey Gouly , Suzuki K Poulose , Zenghui Yu , Mingwei Zhang , Colton Lewis , Raghavendra Rao Ananta Subject: Re: [PATCH v2 2/2] KVM: arm64: Use MDCR_EL2.HPME to evaluate overflow of hyp counters In-Reply-To: References: <20241120005230.2335682-1-oliver.upton@linux.dev> <20241120005230.2335682-3-oliver.upton@linux.dev> <86ttc2uwox.wl-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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, kvmarm@lists.linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, mizhang@google.com, coltonlewis@google.com, rananta@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 20 Nov 2024 08:54:45 +0000, Oliver Upton wrote: > > On Wed, Nov 20, 2024 at 08:38:22AM +0000, Marc Zyngier wrote: > > On Wed, 20 Nov 2024 00:52:30 +0000, Oliver Upton wrote: > > > +/* > > > + * Returns the PMU overflow state, which is true if there exists an event > > > + * counter where the values of the global enable control, PMOVSSET_EL0[n], and > > > + * PMINTENSET_EL1[n] are all 1. > > > + */ > > > +static bool kvm_pmu_overflow_status(struct kvm_vcpu *vcpu) > > > { > > > - u64 reg = 0; > > > + u64 reg = __vcpu_sys_reg(vcpu, PMOVSSET_EL0); > > > > > > - if ((kvm_vcpu_read_pmcr(vcpu) & ARMV8_PMU_PMCR_E)) { > > > - reg = __vcpu_sys_reg(vcpu, PMOVSSET_EL0); > > > - reg &= __vcpu_sys_reg(vcpu, PMINTENSET_EL1); > > > - } > > > + reg &= __vcpu_sys_reg(vcpu, PMINTENSET_EL1); > > > + > > > + /* > > > + * PMCR_EL0.E is the global enable control for event counters available > > > + * to EL0 and EL1. > > > + */ > > > + if (!(kvm_vcpu_read_pmcr(vcpu) & ARMV8_PMU_PMCR_E)) > > > + reg &= kvm_pmu_hyp_counter_mask(vcpu); > > > > So if the PMU is disabled at EL1, we remove the cycle counter from the > > list of counters that are considered for an overflow. > > > > I don't think that's what you really want. > > That's how it is written though, no? My understanding is that the fixed > counters are never reserved by EL2: > > """ > The PE signals a request for: > > [...] > > - The cycle counter, when the values of PMCR_EL0.E, PMOVSSET[31] and > PMINTENSET[31] are all 1 > """ Ah, fair enough. I had the misguided impression that there would be another control for that, but this is actually called out in D13.11.2 ("The PMU does not provide any control that a hypervisor can use to reserve the cycle counter for its own use."). I stand corrected. > > PMUOverflowCondition() and PMUCounterIsHyp() seem to match this too. > Unless I can't read, which happens a lot. Nah, that's definitely me. FWIW, and with the follow-up fixes: Reviewed-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.