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 D705222424C for ; Thu, 10 Apr 2025 10:55:02 +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=1744282502; cv=none; b=HhRLEAYCKOK3BXC/hQN9Ee5mSYBiphTCR7jKvrM04IQc0/ynX0n+g/Tl06GWgrntzSyyojoXV461p1cOnXQaupKCerZrjWW2GK2VR82cKHUiSdLU+r2Wx1GN/fakeJS35TOKVPzqvWOO7PxzKs9XgcTVHBHtvtd6Danh6n5vz+w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744282502; c=relaxed/simple; bh=QQYiFDpEW1BxNEqhLEehjGxlVLQWML3v3QWCApvJReo=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Bik9590L3enSkKJm05ROLStmYpuskwmptdc2dBWmrQzhV4IMyLawWWWi8kcIq649O7bq/IyYZKBhZIjjwEb2BEoZImpcC4LUvbGqjWg1VYunPylApl4zLtw2Bas9WdkcGvxQTDDfcB/NgCM7RTT1pEeZJ+lHJwZrMT2hPNhclZE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E5tjTuWX; 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="E5tjTuWX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 469F7C4CEE3; Thu, 10 Apr 2025 10:55:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744282502; bh=QQYiFDpEW1BxNEqhLEehjGxlVLQWML3v3QWCApvJReo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=E5tjTuWXcfeWv750QRduV9PWV3j6THFJ0vktnckYsAuV8MCtcmoCE7T/qPsmjjDwv 0QNP4xU+IITHuBZl/GnpIZOu9W1IUS9iazr3FUdFKXAcv/jCEkdV7fOCjzrUpZjW/v TGnxj1lDGm8J5izS/ko85NCXKMwRJChVr1CewJY9aJGAepHJZmHKtRlpyKXxKR85Zv VQwej8lTeyrWLSNnOIQm24Wk0BLRac4jFBZC0+3yCTur105Jw7flEuWrIPbFBvkUNI 5IEYYXc3iLLMI4ovI6n/x/fvzR9VWott2YZ/w08sli3FlxtmiMPWZYy2Vrmh1N+sYm BWf9kMMDVkIxw== 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 1u2pYh-004Bhc-TR; Thu, 10 Apr 2025 11:54:59 +0100 Date: Thu, 10 Apr 2025 11:54:59 +0100 Message-ID: <86ikncl20s.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Joey Gouly , Suzuki K Poulose , Zenghui Yu Subject: Re: [PATCH v2 1/6] KVM: arm64: Fix MDCR_EL2.HPMN reset value In-Reply-To: References: <20250409160106.6445-1-maz@kernel.org> <20250409160106.6445-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/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, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.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, 09 Apr 2025 21:21:33 +0100, Oliver Upton wrote: > > On Wed, Apr 09, 2025 at 05:01:01PM +0100, Marc Zyngier wrote: > > The MDCR_EL2 documentation indicates that the HPMN field has > > the following behaviour: > > > > "On a Warm reset, this field resets to the expression NUM_PMU_COUNTERS." > > > > However, it appears we reset it to zero, which is not very useful. > > > > Add a reset helper for MDCR_EL2, and handle the case where userspace > > changes the target PMU, which may force us to change HPMN again. > > > > Reported-by: Joey Gouly > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/pmu-emul.c | 13 +++++++++++++ > > arch/arm64/kvm/sys_regs.c | 8 +++++++- > > 2 files changed, 20 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c > > index a1bc10d7116a5..4dc4f3a473c3f 100644 > > --- a/arch/arm64/kvm/pmu-emul.c > > +++ b/arch/arm64/kvm/pmu-emul.c > > @@ -1033,6 +1033,19 @@ static void kvm_arm_set_pmu(struct kvm *kvm, struct arm_pmu *arm_pmu) > > > > kvm->arch.arm_pmu = arm_pmu; > > kvm->arch.pmcr_n = kvm_arm_pmu_get_max_counters(kvm); > > nit: Can we rename pmcr_n to nr_pmu_counters? The current name is misleading. Fair enough. > > + > > + /* Reset MDCR_EL2.HPMN behind the vcpus' back... */ > > + if (test_bit(KVM_ARM_VCPU_HAS_EL2, kvm->arch.vcpu_features)) { > > + struct kvm_vcpu *vcpu; > > + unsigned long i; > > + > > + kvm_for_each_vcpu(i, vcpu, kvm) { > > + u64 val = __vcpu_sys_reg(vcpu, MDCR_EL2); > > + val &= ~MDCR_EL2_HPMN; > > + val |= FIELD_PREP(MDCR_EL2_HPMN, kvm->arch.pmcr_n); > > + __vcpu_sys_reg(vcpu, MDCR_EL2) = val; > > + } > > Shouldn't we be taking the vCPU mutex(es) here? If we needed to, it shouldn't be here. We hold the config_lock at this point, and taking a vcpu mutex would result in a locking inversion. One option is to punt this to a request, but that makes the updated HPMN un-observable from userspace until the vcpu has run. This already affects the default PMU, btw, since it is only assigned on first run. I'm also not convinced racing against userspace is a big problem here. M. -- Without deviation from the norm, progress is not possible.