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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0DAF1C021AA for ; Wed, 19 Feb 2025 14:07:26 +0000 (UTC) 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-Owner; bh=ZARQI8ChAULUvHfl1bGiYMqwXqv2WfF1UMQZOipmENk=; b=4SoiC+Nx/SILOQOnXzTHtUN30L KAj0vANggmUGf/UHOsK5eejppXod5kttWYR+T0AFxkWuCI39Rc90mCcyLKVede+t1NGpZJpepgqtS aA7r7fJUKPee23YGPwll3A/ET0wzxI1fmNTNQyOQ2TARul/CZetfY6fiLO5rZk0UHsTMKbvGylRSs l7z2VXVhk/im4ymeJxxLDXPCXCZI17+FgsAYU+NJHmOUhDvAiBrODLsct+DiluO2kmia4cXsVtcku oGpvA6AEEXv19XWoM8BhuPIT2/EVjwscBEHUF55ggd7vq+x2IEcrj5YNSeWnlUSXQM/VwCFEwrCw8 ZRKlPCkQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tkkjJ-0000000DBsP-2eb0; Wed, 19 Feb 2025 14:07:13 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tkkg5-0000000D9Ke-1PiQ for linux-arm-kernel@lists.infradead.org; Wed, 19 Feb 2025 14:03:54 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id D1EB4A42820; Wed, 19 Feb 2025 14:02:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51053C4CED6; Wed, 19 Feb 2025 14:03:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739973832; bh=ftok8XYsXfdKDvQpA7AdcEM4jDXUpULUx2D5Ds2zRGY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=uPCYG2ondSqrYPXZfrcTeozeeM/2BVb2y2hV7gY544ZqF+IrSx5Qm2MJhLEOTt0Fm +gvSkp0EyXWoFp0LRhmIOIHjiq8FlaBaiKmeeQ5juW+gus25Dm5ezP/NWkLxtZafYa fBLZkFCkmi2p8YWX+RPnC8ttZq23fHq9y9EDS2T8FxGjOKhoUCpM1etktvVHkqXO3+ K90393X1uXFgdHkZCi5JHcQtxI/q6wz7eWOERdhMw+RMvpA2+Cr1/+fNpudPvonev8 BAvOEdP6EwrmivHrh57htUNzFuql0/KxP05T/+z64Sxizw93G7K1EG6TrpTOdSL5Kc uh0x3HcCG/bgg== 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 1tkkg1-005qpn-Tb; Wed, 19 Feb 2025 14:03:50 +0000 Date: Wed, 19 Feb 2025 14:03:49 +0000 Message-ID: <86a5airpyy.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 1/2] KVM: arm64: Fix MDCR_EL2.HPMN reset value In-Reply-To: References: <20250217112412.3963324-1-maz@kernel.org> <20250217112412.3963324-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) 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250219_060353_502371_E14B5CFC X-CRM114-Status: GOOD ( 29.34 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 17 Feb 2025 18:53:50 +0000, Oliver Upton wrote: > > Hey, > > On Mon, Feb 17, 2025 at 11:24:11AM +0000, 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 > > The existing ABI expectations are that writes to PMCR_EL0.N constrain > the number of counters, so that should have a similar effect on > MDCR_EL2.HPMN. > > At the same time, I get the feeling that we should throw out this whole > behavior of writing N to change the shape of the PMU, because it > complete breaks down for NV. PMCR_EL0.N is another one of those fields > that change behavior based on EL and isn't a global source of truth on > the shape of the PMU. > > What do you think about adding a new vCPU attribute for selecting the > number of counters for a VM? We can allow non-nested VMs to use the > 'old' method of writing PMCR_EL0.N and force nested VMs to use the > attribute. VCPU attribute? or PMU attribute? I'm really not keen on the former, but the latter is probably workable, as it is VM-wide, similar to the way we keep track of pmcr_n. > We can then enforce ordering on the attribute and prevent it from being > used after vCPU reset. How would that work? Do you really want to mandate the PMU selection (with its counter capping) to strictly occur between vcpu creation and init? This would, for example, break kvmtool which has these two operations back-to-back, and sneaking new device-specific actions in the middle is a bit unpalatable (there is a split between VM-wide and per-vcpu actions). Any idea? M. -- Without deviation from the norm, progress is not possible.