From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8CDA606A320 for ; Fri, 23 Oct 2026 12:37:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=jDCCdRsA; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=PysySQZP DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=lklnJv3m9wn+sUjSz23qr/7on9I1vjJJc+u4N9JuGRI=; b=jDCCdRsAJ4znkhM0K4RnYsi741 nPMOAm0om/gRcytCLq3aruwkVH2bPY/mLoJpQsA4aMgPz0yRqFZSQ+fPh3eB6oN810Js0VRRDYLwy U/Gy+3J2KuUbNQxM9jm6wuSb174ZaOJpZOJtvSJCPRuTwukgTvBfYSSMEdEEOHgOp/DevQz5wqCem jZMQYZl54ppJ+qZuon3dU2vX+VDMyOjuoGn1qYWjv3n5TOBf8HMF65YVK6EYY7/EfO323WBiqv3dr 04STlMYrbSH71Jc4VqFbk/2kySSNnNyXtt1AkhwcukJEKkF2loV7TlR8SaGXTe129aNKjYRXFVfbT lXveJBVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xKEWs-0000000GInO-26Cf; Fri, 23 Oct 2026 12:37:50 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xKEWr-0000000GIn8-1M2m for linux-arm-kernel@lists.infradead.org; Fri, 23 Oct 2026 12:37:49 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 2F018602CA; Fri, 23 Oct 2026 12:37:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD98F1F031E2; Fri, 23 Oct 2026 12:37:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792759067; bh=lklnJv3m9wn+sUjSz23qr/7on9I1vjJJc+u4N9JuGRI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=PysySQZPwCVNFDM2IcfoYZwVzRdSOwHFlrDmK+bSa/LMAUCkzMyYw0Gz9WOmiUTQ0 IOVy9Nmhim/H4DCjm5y2RPYdkAhH4yMG8DESjVZmX3XF5DfgdhNYcIJiTVw7coos8+ SqLEuw8h9v4uwLTb0N6Sze0t3B/BK8ARG3TgLlWuckOP2NteVuyg5f3VVdPpmqQO3Y BOKSkRXDMv7DUsC3FyPW+yfkHFL2CmuTteF8RnmxNna3snr82zUBzN8EMmuKECWcHh IYkWZzqWfpUNYGkfQO+aiizlD8clAWlgQWJCyLGhmT04qJ8UYeBG31iMAbnBZ3hUrw A8ap4Vora6qJg== 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.98.2) (envelope-from ) id 1xKEWn-00000006SOz-30jJ; Fri, 23 Oct 2026 12:37:45 +0000 Date: Fri, 23 Oct 2026 13:37:45 +0100 Message-ID: <86cxt0zj6u.wl-maz@kernel.org> From: Marc Zyngier To: Vincent Donnefort Cc: oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, kernel-team@android.com, fuad.tabba@linux.dev Subject: Re: [PATCH v1] KVM: arm64: Use the host kvm_host_data for nr_event_counters In-Reply-To: <20261023092007.3918848-1-vdonnefort@google.com> References: <20261023092007.3918848-1-vdonnefort@google.com> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Archived-By: 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: vdonnefort@google.com, oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, kernel-team@android.com, fuad.tabba@linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-16.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On Fri, 23 Oct 2026 10:20:07 +0100, Vincent Donnefort wrote: > > nr_event_counters is only used by the host to populate mdcr_el2. > However, host_data_ptr() for pKVM switches between the hypervisor copy > of kvm_host_data before it is deprivileged to the host copy after. > > So kvm_init_host_debug_data() initialises nr_event_counters in the > hypervisor's kvm_host_data, while kvm_arm_setup_mdcr_el2() reads the > host copy which is 0. With a HPMN of 0, this stops programmable event > counters from counting a non-protected guest. > > Always use the host copy for nr_event_counters. > > Fixes: 2417218f2f23 ("KVM: arm64: Get rid of __kvm_get_mdcr_el2() and related warts") > Signed-off-by: Vincent Donnefort > --- > arch/arm64/kvm/debug.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c > index f4d7b12045e8..a00771339c62 100644 > --- a/arch/arm64/kvm/debug.c > +++ b/arch/arm64/kvm/debug.c > @@ -44,7 +44,7 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu) > * to disable guest access to the profiling and trace buffers > */ > vcpu->arch.mdcr_el2 = FIELD_PREP(MDCR_EL2_HPMN, > - *host_data_ptr(nr_event_counters)); > + __this_cpu_read(kvm_host_data.nr_event_counters)); > vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | > MDCR_EL2_TPMS | > MDCR_EL2_TTRF | > @@ -80,8 +80,8 @@ void kvm_init_host_debug_data(void) > ID_AA64DFR0_EL1_PMUVer_SHIFT); > > if (pmuv3_implemented(pmuver)) > - *host_data_ptr(nr_event_counters) = FIELD_GET(ARMV8_PMU_PMCR_N, > - read_sysreg(pmcr_el0)); > + __this_cpu_write(kvm_host_data.nr_event_counters, > + FIELD_GET(ARMV8_PMU_PMCR_N, read_sysreg(pmcr_el0))); > > *host_data_ptr(debug_brps) = SYS_FIELD_GET(ID_AA64DFR0_EL1, BRPs, dfr0); > *host_data_ptr(debug_wrps) = SYS_FIELD_GET(ID_AA64DFR0_EL1, WRPs, dfr0); > This really looks like the wrong approach. host_data_ptr() should be reliable, and always point at the correct data, irrespective of the backend. If host_data_ptr() returns a pointer to stale data on pKVM, then it is purely a pKVM bug, and that's what needs fixing by synchronising the two copies by whatever means necessary. Randomly picking a different accessor is not an acceptable outcome. M. -- Without deviation from the norm, progress is not possible.