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 F2CCEC433EF for ; Wed, 8 Dec 2021 15:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Rsk6Heo4RaKERrRqh6/PpyXYnBBNdtD5SMOTrX02ZLo=; b=y9RdEbp2DFMl6j 5ZxJWn+TOkSCWUPb6aawT4MPXoSXuaSZQnz4EQHBBmytn7gP3dbAxy/8btMq9K6cH3Zqj/3RiZbK3 vIRWiwTM95M5UNZtRa32MPSNknq43g6Rn//xaPR3S5DMOHVVXOb+gqa9RcnHV/czw4mY74KQZNe4g 5gU2KYcKVHytfY/1z99sbt+9Qg4syMKnmhIpYjKMJkAmndyo2fD1US6fYZkANkA7/UYUMV4ExS6EL VXp2KPCfLErm7kzH/LpiPmObInMPmEc4T3zg7BxPDQfMKlqAKHOxONn2ngy3XNojyRsfQwIKBryCP dCfvOszdPh2PNBlPHOqw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muz7f-00DLsf-4d; Wed, 08 Dec 2021 15:44:47 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1muz7Z-00DLqN-C6 for linux-arm-kernel@lists.infradead.org; Wed, 08 Dec 2021 15:44:43 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 54E68CE1FAC; Wed, 8 Dec 2021 15:44:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81B15C00446; Wed, 8 Dec 2021 15:44:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638978277; bh=olrtr/vutUtS6JAs1JgFn6ixytY6DwMSP+1k5yff+Bc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sNQRE8fYBtdAkW6v5vVLPIvcEgDD/4zrvKTfLe9BrVPdWkvoZ5Lzzqt2x2UH/4AjD PQWh1QnQUHmqtetoftiij6OYtOMVQ//ipPz46Ee6tx18AMntneYRlFKHqdqJ/N0l6i BVJmr70Sj1nW15a1O8HU1KyAFEeURW6YIuONf1rkk+R9rvD6TOLgAU+QoWOSeBTrMB lfRM69vkDxBHuM/ackki7uC5ypQPBvL4QTttKewz1RMsrt3LHpOyFDZhNFj1XOLVs6 oSgQAd8q+nD34GyHhXbbqGzXsAeceAwibiEVCtrdZ60TPqYLj3N0xr9e+eUP2hT0Ry fcI9BtwnLxP1Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1muz7T-00Ao7i-Im; Wed, 08 Dec 2021 15:44:35 +0000 Date: Wed, 08 Dec 2021 15:44:35 +0000 Message-ID: <87bl1r14po.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: Reiji Watanabe , james.morse@arm.com, suzuki.poulose@arm.com, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, tglx@linutronix.de, mingo@redhat.com Subject: Re: [PATCH v2 3/4] KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_SET_PMU attribute In-Reply-To: References: <20211206170223.309789-1-alexandru.elisei@arm.com> <20211206170223.309789-4-alexandru.elisei@arm.com> <87czm718cp.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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, reijiw@google.com, james.morse@arm.com, suzuki.poulose@arm.com, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, tglx@linutronix.de, mingo@redhat.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-20211208_074441_833666_BE89079B X-CRM114-Status: GOOD ( 32.88 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 08 Dec 2021 15:20:30 +0000, Alexandru Elisei wrote: > > Hi Marc, > > On Wed, Dec 08, 2021 at 02:25:58PM +0000, Marc Zyngier wrote: > > On Wed, 08 Dec 2021 12:23:44 +0000, > > Alexandru Elisei wrote: > > > > > > This makes me wonder. Should KVM enforce having userspace either not > > > setting the PMU for any VCPU, either setting it for all VCPUs? I think this > > > would be a good idea and will reduce complexity in the long run. I also > > > don't see a use case for userspace choosing to set the PMU for a subset of > > > VCPUs, leaving the other VCPUs with the default behaviour. > > > > Indeed. As much as I'm happy to expose a PMU to a guest on an > > asymmetric system, I really do not want the asymmetry in the guest > > itself. So this should be an all or nothing behaviour. > > From what I can tell, the only asymmetry that can be exposed to a guest as > a result of the series is the number of events supported on a VCPU. Not only. It means that the events are counting different things. It isn't only about pmuver, which is only about the architectural revision implemented by the PMU. If you start assigning two different PMUs (in the perf sense) to a guest, you open the Pandora box of having to deal with all the subtle nonsense that asymmetric systems bring. What about event filtering, for example? > I don't like the idea of forcing userspace to set the *same* PMU for all > VCPUs, as that would severely limit running VMs with PMU on asymmetric > systems. On the contrary, I am *very* happy to limit a VM to a single PMU (and thus CPU) type on these systems. Really. > Even if KVM forces to set a PMU (does not have to be the same PMU) for all > VCPUs, that still does not look like the correct solution for me, because > userspace can set PMUs with different number of events. I don't understand what you mean. If you associate a single PMU type to the guest, that's all the guest sees. > What I can try is to make kvm->arch.pmuver the minimum version of all the > VCPU PMUs and the implict PMU. I'll give that a go in the next iteration. I really don't think we need any of this. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel