From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-87.mta0.migadu.com (out-87.mta0.migadu.com [91.218.175.87]) (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 5E4C61426E for ; Fri, 28 Jul 2023 19:52:57 +0000 (UTC) Date: Fri, 28 Jul 2023 19:52:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1690573975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TQnXf4XQhMtZfBROiaMu1NxfovrLksRnYCtkHo8F1w0=; b=oZ81VoC3a5IgdTQygqqElR6r0AxdAOElqtYvotppOy3ruvmJ5NITRrT6CV2P7SvVrgCddn qiwEq0J+0FjYYl+WXmz3jsg6GaNbQ35Xw9szgkq7AqaN3d1jfSDW13dFzWX5ClJ0YjysA6 0lU36L2w/JLq3ul0BQimzqJSvi5FEqs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Alexandru Elisei , Zenghui Yu , Suzuki K Poulose , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH v2 2/5] KVM: arm64: PMU: Disallow vPMU on non-uniform PMUVer systems Message-ID: References: <20230728181907.1759513-1-reijiw@google.com> <20230728181907.1759513-3-reijiw@google.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230728181907.1759513-3-reijiw@google.com> X-Migadu-Flow: FLOW_OUT On Fri, Jul 28, 2023 at 11:19:04AM -0700, Reiji Watanabe wrote: > Disallow userspace from configuring vPMU for guests on systems > where the PMUVer is not uniform across all PEs. > KVM has not been advertising PMUv3 to the guests with vPMU on > such systems anyway, and such systems would be extremely > uncommon and unlikely to even use KVM. This doesn't actually disallow userspace from configuring a vPMU, it only hides the KVM cap. kvm_host_pmu_init() will still insert the host PMU instance in the list of valid PMUs, and there doesn't appear to be any check against the static key anywhere on that path. FWIW, this static key is actually responsible for indicating whether KVM supports context switching the PMU between host/guest. While vPMU obviously depends on that, the perf subsystem also allows the host to program events to count while the guest is running. I actually prefer where we flip the static key, as PMU context switching depends on both KVM support as well as the PMU driver coming up successfully. Instead, you could hoist the check against the sanitised PMU version into kvm_host_pmu_init(), maybe something like: diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c index 560650972478..f6a0e558472f 100644 --- a/arch/arm64/kvm/pmu-emul.c +++ b/arch/arm64/kvm/pmu-emul.c @@ -672,8 +672,11 @@ void kvm_host_pmu_init(struct arm_pmu *pmu) { struct arm_pmu_entry *entry; - if (pmu->pmuver == ID_AA64DFR0_EL1_PMUVer_NI || - pmu->pmuver == ID_AA64DFR0_EL1_PMUVer_IMP_DEF) + /* + * Check the sanitised PMU version for the system, as KVM does not + * support implementations where PMUv3 exists on a subset of CPUs. + */ + if (!pmuv3_implemented(kvm_arm_pmu_get_pmuver_limit())) return; mutex_lock(&arm_pmus_lock); -- Thanks, Oliver 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 BDA95C001DF for ; Fri, 28 Jul 2023 19:53:26 +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=F02D8adqiJ4jmkiVa2L5knp/OywrJ/K3oydeCZkOisA=; b=As7eaSmXkvMwOQ GWxKppJK5oD9NVOpKJ1q7VGlyd0sUUsDbhMPe7vNsXu9bw5mlV/Abe61rgz3/mh/+jUX67olocaAY 8LKfUgsP3vDrt8OssycypHmZDzsONLHSY4+uIbGj4bH/fpz93tpzP3mOHffImE/1Pox2fpeF0BbVm h5oBcp6wtBt/lTK2wiqr3S65PL8zIKmBu0ymBsod7SXO7V5ToZxh3CWzG6u0SHc94F0hgP1U2Yi8z kebWNAWNPeFkpCfMAFKH8JqHU47xXbPIQxLZQS5AnCQqzwNuUdBZsOB8NvfJQs93wA/jCseOZWkY/ fbgVI1Fwe7lv1zvRkh7w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qPTWI-004ovq-1b; Fri, 28 Jul 2023 19:53:02 +0000 Received: from out-64.mta0.migadu.com ([91.218.175.64]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qPTWF-004oub-0T for linux-arm-kernel@lists.infradead.org; Fri, 28 Jul 2023 19:53:01 +0000 Date: Fri, 28 Jul 2023 19:52:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1690573975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TQnXf4XQhMtZfBROiaMu1NxfovrLksRnYCtkHo8F1w0=; b=oZ81VoC3a5IgdTQygqqElR6r0AxdAOElqtYvotppOy3ruvmJ5NITRrT6CV2P7SvVrgCddn qiwEq0J+0FjYYl+WXmz3jsg6GaNbQ35Xw9szgkq7AqaN3d1jfSDW13dFzWX5ClJ0YjysA6 0lU36L2w/JLq3ul0BQimzqJSvi5FEqs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Alexandru Elisei , Zenghui Yu , Suzuki K Poulose , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH v2 2/5] KVM: arm64: PMU: Disallow vPMU on non-uniform PMUVer systems Message-ID: References: <20230728181907.1759513-1-reijiw@google.com> <20230728181907.1759513-3-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230728181907.1759513-3-reijiw@google.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230728_125259_694236_72F311C1 X-CRM114-Status: GOOD ( 16.12 ) 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 Fri, Jul 28, 2023 at 11:19:04AM -0700, Reiji Watanabe wrote: > Disallow userspace from configuring vPMU for guests on systems > where the PMUVer is not uniform across all PEs. > KVM has not been advertising PMUv3 to the guests with vPMU on > such systems anyway, and such systems would be extremely > uncommon and unlikely to even use KVM. This doesn't actually disallow userspace from configuring a vPMU, it only hides the KVM cap. kvm_host_pmu_init() will still insert the host PMU instance in the list of valid PMUs, and there doesn't appear to be any check against the static key anywhere on that path. FWIW, this static key is actually responsible for indicating whether KVM supports context switching the PMU between host/guest. While vPMU obviously depends on that, the perf subsystem also allows the host to program events to count while the guest is running. I actually prefer where we flip the static key, as PMU context switching depends on both KVM support as well as the PMU driver coming up successfully. Instead, you could hoist the check against the sanitised PMU version into kvm_host_pmu_init(), maybe something like: diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c index 560650972478..f6a0e558472f 100644 --- a/arch/arm64/kvm/pmu-emul.c +++ b/arch/arm64/kvm/pmu-emul.c @@ -672,8 +672,11 @@ void kvm_host_pmu_init(struct arm_pmu *pmu) { struct arm_pmu_entry *entry; - if (pmu->pmuver == ID_AA64DFR0_EL1_PMUVer_NI || - pmu->pmuver == ID_AA64DFR0_EL1_PMUVer_IMP_DEF) + /* + * Check the sanitised PMU version for the system, as KVM does not + * support implementations where PMUv3 exists on a subset of CPUs. + */ + if (!pmuv3_implemented(kvm_arm_pmu_get_pmuver_limit())) return; mutex_lock(&arm_pmus_lock); -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel