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 27298254AE9; Wed, 19 Mar 2025 11:41:29 +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=1742384490; cv=none; b=SLtnZhepsB3WuT8GU1lOw7joFlKQZ98zurLJxJUBWjhHiMYE41ktIZBTUzeFu26nZs06QQjANLfJF+nU9X/RILItw91uvOYbsutwgsP5gXil1tq1KITcBxk2KG7kR+8Xd8sRHsnPbclEyANtR5TFZmTvryIED9HOkfhkNbr0vW4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742384490; c=relaxed/simple; bh=sCG7TrMV7r+MbaFZ5m1n+E4AY94m6bjL2vVmlHoGurI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=cUmEzgCkMq1g357fuqLyw4A/oSFTR5wuwJ7zxnIy0YMkSEOIFTDHs1jpr14+wJo7Rn4R8H1peaM83Iy6JY3QwItYrRbF71sOQCOG7RGcxW292hDhphAvwNh0MExrWqt8w0XoWDUqnYbdNMQPQzY87hw8qzlj4UxBfngL366iWV8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o1TZS1u/; 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="o1TZS1u/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93B42C4CEE9; Wed, 19 Mar 2025 11:41:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742384489; bh=sCG7TrMV7r+MbaFZ5m1n+E4AY94m6bjL2vVmlHoGurI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=o1TZS1u/fD93AsTsWRKod/hxrQg8n6q5DkGeeKkHUB+MUnvSaFvXiLppI2hZH62JO N5uDsJzd48C2Ftf11jf871UG6PXsAHJnQLz7u1FUDNBtWq8msGXh8iNnnTaUJceKSl YXOVHPMnikCw5WFLe0qvY3L3mClWfc8sVX+a1dt44HcbkvOyJyQU7zOO/18AjDpXgN AG468J0bxaudk9VH5hLbdLzx3JsYoymWoqIYQF5K7cKf1j7EbMqsHh2H1AVtkpKhu4 KuyQk5UdnENU8WqEam1cbuplXnMxE3nL9WnJVDvcdg65SvsHm9S0HEwz65ut78/J0c ZyfvIgcWmEJcQ== 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 1turnb-00F3HT-H5; Wed, 19 Mar 2025 11:41:27 +0000 Date: Wed, 19 Mar 2025 11:41:27 +0000 Message-ID: <86msdhmemw.wl-maz@kernel.org> From: Marc Zyngier To: Akihiko Odaki Cc: Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Kees Cook , "Gustavo A. R. Silva" , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, devel@daynix.com Subject: Re: [PATCH RFC] KVM: arm64: PMU: Use multiple host PMUs In-Reply-To: References: <20250319-hybrid-v1-1-4d1ada10e705@daynix.com> <86plidmjwh.wl-maz@kernel.org> <86o6xxmg87.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: linux-kernel@vger.kernel.org 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: akihiko.odaki@daynix.com, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, kees@kernel.org, gustavoars@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, devel@daynix.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, 19 Mar 2025 11:26:18 +0000, Akihiko Odaki wrote: > > On 2025/03/19 20:07, Marc Zyngier wrote: > > On Wed, 19 Mar 2025 10:26:57 +0000, > >> > > But that'd be a new ABI, which again would require buy-in from > > userspace. Maybe there is scope for an all CPUs, cycle-counter only > > PMUv3 exposed to the guest, but that cannot be set automatically, as > > we would otherwise regress existing setups. > > > > At this stage, and given that you need to change userspace, I'm not > > sure what the best course of action is. > > Having an explicit flag for the userspace is fine for QEMU, which I > care. It can flip the flag if and only if threads are not pinned to > one PMU and the machine is a new setup. > > I also wonder what regression you think setting it automatically causes. The current behaviour is that if you don't specify anything other than creating a PMUv3 (without KVM_ARM_VCPU_PMU_V3_SET_PMU), you get *some* PMU, and userspace is responsible for running the vcpu on CPUs that will implement that PMU. When if does, all the counters, all the events are valid. If it doesn't, nothing counts, but the counters/events are still valid. If you now add this flag automatically, the guest doesn't see the full PMU anymore. Only the cycle counter. That's the regression. Thanks, M. -- Without deviation from the norm, progress is not possible.