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 29414C28B30 for ; Thu, 20 Mar 2025 09:21:07 +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=PCJAzpy8HDIbp+z+ImFUPsEWfbhdpXlMCt8uQ4lZYeA=; b=cGmY0oliqIqgByBWGIa+1ghgyT /ISMhiHj3NFASmSTPsQiQCio5Qi/zafQOBpACKs/vfNADOXUq6fWmvw6O4Ouq1FNYD6r7pVbpezNA wsVZvFwKUtI6irSzy0/txvwDoq2C+0O/Ncf8Xh6CPVaSFw51S1B1PpZ6bPMSfccs2uFg1IAn6Hq3/ MJipJP4B3f9IBFRmt/DIMZlneNjLEKCnEl9iBS1FGHaoLq+KXu5gx3vZ71vshVySOZ6m3Qo0ygVmd sGq26aJLjeqkIUuu14b2fSDmNJdJR/2IiGAj1Us2VQ5Oq15pQB9NVBseZvoZv/beCfHk97sPJ6Tq+ zFTGsWrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tvC57-0000000BfqQ-09uJ; Thu, 20 Mar 2025 09:20:53 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tvC3O-0000000Bff2-2cLn for linux-arm-kernel@lists.infradead.org; Thu, 20 Mar 2025 09:19:07 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id DF5AF5C51AA; Thu, 20 Mar 2025 09:16:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77B2AC4CEDD; Thu, 20 Mar 2025 09:19:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742462345; bh=DyYZu43SCOG8idqcMJJdyHd71H6vj85HgtLk8md7IhI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=g9tP5OaBBniNVKx/1th/Dn6r/KXDHr1v6Sn6QKGJfwbuaAnPrH/sIJd6ryyHFW6mD lXKRAgqhmTQjoin2lcilrtZUBL9zKTtRk4iaOVENNvWYxIXK+eql7BUsnZn3sYnWVX vwT92yDgc2KsrgfDENuN7Dk+7hezHcQ23+TYgVrYsA5tEI7lmDMp1+l5t1WJu2tTSg ZGJ3p8kSQHSMdfishJWD0TmTcnopLzmaLi3ElnS1BE0NAifgAVTiKAPf1WnAQSHpRk GEMHsL5OQMsMuubI5BMr1STWNZ7/rV6ykx4u12zT48FNl7CbYIMjfVl8j9M78Ps8Co dQiHRgwllnVng== 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 1tvC3K-00FMaU-U3; Thu, 20 Mar 2025 09:19:03 +0000 Date: Thu, 20 Mar 2025 09:19:02 +0000 Message-ID: <86h63om54p.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Akihiko Odaki , 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> <86msdhmemw.wl-maz@kernel.org> <86ldt0n9w1.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) 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, akihiko.odaki@daynix.com, 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250320_021906_750658_424FA85B X-CRM114-Status: GOOD ( 35.99 ) 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 Wed, 19 Mar 2025 18:51:28 +0000, Oliver Upton wrote: > > On Wed, Mar 19, 2025 at 06:38:38PM +0000, Marc Zyngier wrote: > > On Wed, 19 Mar 2025 11:51:21 +0000, Akihiko Odaki wrote: > > > What about setting the flag automatically when a user fails to pin > > > vCPUs to CPUs that are covered by one PMU? There would be no change if > > > a user correctly pins vCPUs as it is. Otherwise, they will see a > > > correct feature set advertised to the guest and the cycle counter > > > working. > > > > How do you know that the affinity is "correct"? VCPU affinity can be > > changed at any time. I, for one, do not want my VMs to change > > behaviour because I let the vcpus bounce around as the scheduler sees > > fit. > > > > Honestly, this is not a can of worm I want to open. We already have a > > pretty terrible userspace API for the PMU, let's not add to the > > confusion. *If* we are going down the road of presenting a dumbed-down > > PMU to the guest, it has to be an explicit buy-in from userspace. > > I also have a very strong distaste for the crappy UAPI we have around a > 'default' PMU. At the same time I do recognize this hurts practical > usecases since some VMMs can't be bothered to configure the vPMU / vCPU > pinning correctly. > > I'm at least willing to plug my nose and do the following: > > 1) When the VMM does not specify a vPMU type: > > - We continue to present the 'default' PMU (including event counters) > to the VM > > - KVM ensures that the fixed CPU cycle counter works on any PMUv3 > implementation in the system, even if it is different from the > default > > - Otherwise, event counters will only count on the default > implementation and will not count on different PMUs I think this is confusing. The CC is counting, but nothing else, and people using the cycle counters in conjunction with other events (a very common use case) will not be able to correlate things correctly. The current behaviour is, for all its sins, at least consistent. > > 2) Implement your suggestion of a UAPI where the VMM can select a PMU > that only has the CPU cycle counter and works on any PMUv3 > implementation. > > Either way KVM will need to have some special case handling of the fixed > CPU cycle counter. That'd allow users to actually run Windows *now* and > provide a clear mechanism for userspace to present a less-broken vPMU if > it cares. Honestly, I don't care about one guest or another. My point is that if we are changing the behaviour of the PMU to deal with this sort of things, then it has to be a userspace buy-in. M. -- Without deviation from the norm, progress is not possible.