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 D76FEC433F5 for ; Wed, 8 Dec 2021 16:12:49 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WG4dLHNWmWQ6xjyrQlWORDeXUQotPLR/WLI9c70kUAk=; b=E9VcIX5nl4B9Hm OyJAHIidVljaCQKEpwhjTTj1uzw8jhR/iqAtQuQofWvved23ttRnpgI+J4Yv9Yqq1iQrnV8En9Vu7 Dz34KdIid4a9CMzZiIFwi+WepywvkjfOWk5dKtvAslL1OSHXijhWrccqREaqzlrr0z18+tb8GAOIX RBQICVWV99ZaIcHuT4nUGOXdTiHO7FQOVYKqO73pUv6n/DQNL/Kw1zXQ76CujNN5rQqaS5G1nehjh zVIJkZl5dSVuxwWLuPWHJbFwPsnvlY92gg+UHdcscabp1J6d2bSsW/v5suvJ1DdCsdvmFylwmCA0R UbHy8QibppaF0WdDc+ng==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muzXU-00DUlq-G1; Wed, 08 Dec 2021 16:11:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muzXN-00DUjp-A2 for linux-arm-kernel@lists.infradead.org; Wed, 08 Dec 2021 16:11:22 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 381C7101E; Wed, 8 Dec 2021 08:11:20 -0800 (PST) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 74FD73F5A1; Wed, 8 Dec 2021 08:11:18 -0800 (PST) Date: Wed, 8 Dec 2021 16:11:13 +0000 From: Alexandru Elisei To: Marc Zyngier 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 Message-ID: References: <20211206170223.309789-1-alexandru.elisei@arm.com> <20211206170223.309789-4-alexandru.elisei@arm.com> <87czm718cp.wl-maz@kernel.org> <87bl1r14po.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87bl1r14po.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211208_081121_466878_E259DE71 X-CRM114-Status: GOOD ( 34.39 ) 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 Hi Marc, On Wed, Dec 08, 2021 at 03:44:35PM +0000, Marc Zyngier wrote: > 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? kvm_pmu_set_counter_event_type() uses the number of events to mask out the unsupported events, so still depends on pmuver. But I understand what you are saying, there might be differences between what exactly an event is counting, how it increments and how the counter value should be interpreted based on the microarchitecture. > > > 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. Ok, so any kind of asymmetry is unacceptable. Accepted behaviour: 1. If userspace sets PMU for one VCPU, then *all* other VCPUs must have a PMU set, and furthermore, it must be the same PMU as the first VCPU, or 2. If userspace has initialized a PMU (via KVM_ARM_VCPU_PMU_V3_CTRL(KVM_ARM_VCPU_PMU_V3_INIT)) without setting a PMU, then it is forbidden for userspace to set a PMU for the other VCPUs. Is that what you had in mind? > > > 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. I was talking in the context of allowing userspace to associate different PMUs to different VCPUs. Thanks, Alex > > > 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