From patchwork Fri Feb 3 04:02:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Reiji Watanabe X-Patchwork-Id: 13126978 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 EDE4FC636CC for ; Fri, 3 Feb 2023 04:03:48 +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:Cc:To:From:Subject:Message-ID: Mime-Version:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=z26uuD9oweVbY5g/x/UlNzj2M3DPvn2w2VRMwE/c/KI=; b=ytH 9iBrpB+tSbNMiVnF5LKaAThPEHK5HL6rbZl5kBHEmvs63GpYHm+zE7H7Y9P4frQHWHQWcYg02bE1Z dF+Z2HffIu6tmIzp8xCyBR/HYb7oCrLmHC/UJ8IvY3BKGqIsyHfJV1AbLrQU6WIbwnt/2zqA6mKTF /0SVZKfgvMky7aeAg/BLlLacXLNp0wr8aIQu+5FF+KRte2KIQXcrbZb7HOIec07wvJPzpPYEcyWwj WBqfthEguKJfpYG9FKZ12SNT4ft1RiLbhHFQ3PL32EV6Gjp9ANLFVZMBlpBp3NJmTPMzOTe2D1sHf ypk0BME6L/9ul5xSzbA7OSTwbeyRo5A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNnHu-000GKD-8p; Fri, 03 Feb 2023 04:02:58 +0000 Received: from mail-yb1-xb49.google.com ([2607:f8b0:4864:20::b49]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNnHq-000GJF-VN for linux-arm-kernel@lists.infradead.org; Fri, 03 Feb 2023 04:02:56 +0000 Received: by mail-yb1-xb49.google.com with SMTP id i17-20020a25bc11000000b007b59a5b74aaso3702499ybh.7 for ; Thu, 02 Feb 2023 20:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=aEW/Npz2sdHk1B5OTprUVUyiPN1G1EFi6du1BLhPkgg=; b=IjRPSeWgMjBBwCHli4Yw1tohOaRbiHodVFVBcp42Td04xRfKajH+/5sxJYxs3aPIIq sg/N/xGsMQcvJ2qGly6VuU4VgnsKJfHPoTcQdd3hyACasDChXTGgkLm22UioGKMFfCOs AmWnbfkOw4IoZ1vBpzcdd/wzqIustrBn7/l2cdl5tesW0333/tzUt27LS5VzFHG35w2I Mh/BqZV4JSBV34wZgjUKrLt5FC6PTcHFRbyrZk9UngDknbmIwxwnWSoRCjMQLUKsdMTC w9hVYuwPTK9mxisml+1GwBvMUvOQ4lDI6f7KAsewPvr8ldY2sRFkQJ7/R/6d1Ra/KqM7 oaIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=aEW/Npz2sdHk1B5OTprUVUyiPN1G1EFi6du1BLhPkgg=; b=oz3XFscEHUcENTAia4+vIkuBco+EBjwbhELYfRXx0IvfA++Cwy1pcKOOb0HT1CfUqf xGB3MXs7U5hfqrEUVCvG+17VCHmVHKSh2al7HL4nVpA1aHx4SRmC5R22IeiHlm7Dpu87 grJYXDbsCxEWZCwvoiTbXXJ9NmBBtuVIYf0YzdAIi6eoruFqRn8sSsJUORGg2X9noHkH 5HXIcUtyowgtELudJVppFoJ15X35AIRXcAwJH5sCp2gOm/yjp1S6NQbfg6KDjspSQb0e iBNCG9aKbQYROD4VcI3fMhlPBLLm1lfuZucHtDx8P+fPxl4gzohkyqnanf22IIc0HgmR 58JQ== X-Gm-Message-State: AO0yUKWoruzrfO41TxEKf7fojUQsjh37W34ITzONpGFELZFpSqUGLOFT XIPyeHZj1YGt6KZKmvY4tN0DzqxNJNY= X-Google-Smtp-Source: AK7set+TsD6+Z9hBoYbr1+iHxu4ZqInnlSg1Oe6NDZYC7iweFzclF6WbZV4M9ru1qUDhdb5v+qNknlzyKew= X-Received: from reijiw-west4.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:aa1]) (user=reijiw job=sendgmr) by 2002:a25:b188:0:b0:70c:bbcb:3432 with SMTP id h8-20020a25b188000000b0070cbbcb3432mr1191509ybj.173.1675396970806; Thu, 02 Feb 2023 20:02:50 -0800 (PST) Date: Thu, 2 Feb 2023 20:02:28 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.1.519.gcb327c4b5f-goog Message-ID: <20230203040242.1792453-1-reijiw@google.com> Subject: [PATCH v3 00/14] KVM: arm64: PMU: Allow userspace to limit the number of PMCs on vCPU From: Reiji Watanabe To: Marc Zyngier , kvmarm@lists.linux.dev Cc: kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Alexandru Elisei , Zenghui Yu , Suzuki K Poulose , Paolo Bonzini , Ricardo Koller , Oliver Upton , Jing Zhang , Raghavendra Rao Anata , Shaoqin@google.com, Huang@google.com, shahuang@redhat.com, Reiji Watanabe X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230202_200255_037182_CA0F7BC8 X-CRM114-Status: GOOD ( 27.97 ) 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 The goal of this series is to allow userspace to limit the number of PMU event counters on the vCPU. We need this to support migration across systems that implement different numbers of counters. The number of PMU event counters is indicated in PMCR_EL0.N. For a vCPU with PMUv3 configured, its value will be the same as the current PE by default. Userspace can set PMCR_EL0.N for the vCPU to any value even with the current KVM using KVM_SET_ONE_REG. However, it is practically unsupported, as KVM resets PMCR_EL0.N to the host value on vCPU reset and some KVM code uses the host value to identify (un)implemented event counters on the vCPU. This series will ensure that the PMCR_EL0.N value is preserved on vCPU reset and that KVM doesn't use the host value to identify (un)implemented event counters on the vCPU. This allows userspace to limit the number of the PMU event counters on the vCPU. This series also includes bug fixes related to the handling of PMCR_EL0.N and PMUVer for a vCPU with PMUv3 configured on heterogeneous PMU systems. The issues to be addressed are: [A] KVM uses the host PMU's PMUVer (kvm->arch.arm_pmu->pmuver) for the vCPU in some cases even though userspace might have changed the vCPU's PMUVer(kvm->arch.dfr0_pmuver.imp). [B] ID_AA64DFR0_EL1.PMUVer of the vCPU is set based on the sanitized value of the field. This could be inappropriate on heterogeneous PMU systems because only one of PMUs on the system can be associated to the guest anyway. [C] The value of PMCR_EL0.N for the vCPU is set to the same value as the current PE. The value might be different from the PMCR_EL0.N value of the PMU associated with the guest. To fix [A], we will stop using kvm->arch.arm_pmu->pmuver in this series. To fix [B] and [C], the vCPU's PMCR_EL0.N and ID_AA64DFR0_EL1.PMUVer will be set based on the host's PMU (kvm->arch.arm_pmu->pmuver) by default in this series. When the PMU is changed for the guest using KVM_ARM_VCPU_PMU_V3_SET_PMU, those are reset to the new PMU's values. See patch 2, 3, and 9 for more details. The series is based on v6.2-rc6. Patch 1 add a helper to set a PMU for the guest. This helper will make it easier for the following patches to add modify codes for that process. Patch 2 make the default PMU for the guest set on the first vCPU reset. Patch 3 and 4 fixes the issue [B] and [A], respectively. Patch 5 fixes reset_pmu_reg() to ensure that (RAZ) bits of PMCNTEN{SET,CLR}_EL0, PMINTEN{SET,CLR}_EL1, and PMOVS{SET,CLR}_EL1 corresponding to unimplemented event counters on the vCPU are reset to zero. Patch 6 is a minor refactoring to use the default PMU register reset function for PMUSERENR_EL0 and PMCCFILTR_EL0. Patch 7 simplifies the existing code that extracts PMCR_EL0.N by using FIELD_GET(). Patch 8 add a helper to read vCPU's PMCR_EL0. Patch 9 changes the code to use the guest's PMCR_EL0.N, instead of the PE's PMCR_EL0.N. This patch fixes the issue [C]. Patch 10 adds support userspace modifying PMCR_EL0.N. Patch 11-14 adds a selftest to verify reading and writing PMU registers for implemented or unimplemented PMU event counters on the vCPU. v3: - Remove reset_pmu_reg(), and use reset_val() instead. [Marc] - Fixed the initial value of PMCR_EL0.N on heterogeneous PMU systems. [Oliver] - Fixed PMUVer issues on heterogeneous PMU systems. - Fixed typos [Shaoqin] v2: https://lore.kernel.org/all/20230117013542.371944-1-reijiw@google.com/ - Added the sys_reg's set_user() handler for the PMCR_EL0 to disallow userspace to set PMCR_EL0.N for the vCPU to a value that is greater than the host value (and added a new test case for this behavior). [Oliver] - Added to the commit log of the patch 2 that PMUSERENR_EL0 and PMCCFILTR_EL0 have UNKNOWN reset values. v1: https://lore.kernel.org/all/20221230035928.3423990-1-reijiw@google.com/ Reiji Watanabe (14): KVM: arm64: PMU: Introduce a helper to set the guest's PMU KVM: arm64: PMU: Set the default PMU for the guest on vCPU reset KVM: arm64: PMU: Don't use the sanitized value for PMUVer KVM: arm64: PMU: Don't use the PMUVer of the PMU set for the guest KVM: arm64: PMU: Clear PM{C,I}NTEN{SET,CLR} and PMOVS{SET,CLR} on vCPU reset KVM: arm64: PMU: Don't define the sysreg reset() for PM{USERENR,CCFILTR}_EL0 KVM: arm64: PMU: Simplify extracting PMCR_EL0.N KVM: arm64: PMU: Add a helper to read a vCPU's PMCR_EL0 KVM: arm64: PMU: Set PMCR_EL0.N for vCPU based on the associated PMU KVM: arm64: PMU: Allow userspace to limit PMCR_EL0.N for the guest tools: arm64: Import perf_event.h KVM: selftests: aarch64: Introduce vpmu_counter_access test KVM: selftests: aarch64: vPMU register test for implemented counters KVM: selftests: aarch64: vPMU register test for unimplemented counters arch/arm64/include/asm/kvm_host.h | 7 + arch/arm64/include/asm/perf_event.h | 2 +- arch/arm64/kernel/perf_event.c | 3 +- arch/arm64/kvm/arm.c | 9 +- arch/arm64/kvm/pmu-emul.c | 81 ++- arch/arm64/kvm/reset.c | 21 +- arch/arm64/kvm/sys_regs.c | 133 ++-- include/kvm/arm_pmu.h | 13 +- tools/arch/arm64/include/asm/perf_event.h | 258 +++++++ tools/testing/selftests/kvm/Makefile | 1 + .../kvm/aarch64/vpmu_counter_access.c | 643 ++++++++++++++++++ .../selftests/kvm/include/aarch64/processor.h | 1 + 12 files changed, 1083 insertions(+), 89 deletions(-) create mode 100644 tools/arch/arm64/include/asm/perf_event.h create mode 100644 tools/testing/selftests/kvm/aarch64/vpmu_counter_access.c base-commit: 6d796c50f84ca79f1722bb131799e5a5710c4700