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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B0A3C433EF for ; Wed, 8 Dec 2021 15:20:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 115FA4B0CC; Wed, 8 Dec 2021 10:20:41 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhWoHY+CvnGd; Wed, 8 Dec 2021 10:20:39 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A821D4B15E; Wed, 8 Dec 2021 10:20:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0520D4B0CC for ; Wed, 8 Dec 2021 10:20:39 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD9iH0Z4OQka for ; Wed, 8 Dec 2021 10:20:37 -0500 (EST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6E4FA4B092 for ; Wed, 8 Dec 2021 10:20:37 -0500 (EST) 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 067E411FB; Wed, 8 Dec 2021 07:20:37 -0800 (PST) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 466683F73B; Wed, 8 Dec 2021 07:20:35 -0800 (PST) Date: Wed, 8 Dec 2021 15:20:30 +0000 From: Alexandru Elisei To: Marc Zyngier 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87czm718cp.wl-maz@kernel.org> Cc: mingo@redhat.com, tglx@linutronix.de, will@kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. 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. 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. 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. Thanks, Alex > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 6337AC433EF for ; Wed, 8 Dec 2021 15:30:21 +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=qfIYosrRM8ARRv0gua8C980g61m7EvgnU/s7h7rVFug=; b=CnAsIR09+47AW/ WJ9O4K0lSpZffxBy8ZhQ59dy+e/gwd6Zd58iBX8zeYVlw7FRKUwBc4ceKK0/8brNd0isg8YVhWWaw cxjGa/kSstGlx7XXuLbOa5zm6xMb5NeEyN6JMc6Eo9mXwTJaKS4lnbO/iDJFeiyCkn78GicNE83Qo mLZMuagmu8gvlUz4V+/IT1Lfx5TTvTFQcUZPrZziP7RnpPRa+dKn7z9CihxbA2r4wliwvUKfGp38C PXzUkhRX0oQlc1eCPQYYXDot2xcV+7sskcmsEE0aHhH59AmJCBMdeBmSzgVlzOsxe0g4X2Lz4neZy bHc9zZvYM3Sk0+I5WfpQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muys5-00DFOo-L6; Wed, 08 Dec 2021 15:28:41 +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 1muykI-00DBX5-L4 for linux-arm-kernel@lists.infradead.org; Wed, 08 Dec 2021 15:20:40 +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 067E411FB; Wed, 8 Dec 2021 07:20:37 -0800 (PST) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 466683F73B; Wed, 8 Dec 2021 07:20:35 -0800 (PST) Date: Wed, 8 Dec 2021 15:20:30 +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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87czm718cp.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211208_072038_821637_AB19B117 X-CRM114-Status: GOOD ( 19.80 ) 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 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. 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. 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. 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. Thanks, Alex > > Thanks, > > 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