linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Colton Lewis <coltonlewis@google.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-perf-users@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 07/23] perf: arm_pmuv3: Introduce method to partition the PMU
Date: Fri, 20 Jun 2025 18:06:50 -0700	[thread overview]
Message-ID: <aFYFqrYRsmCi6oii@linux.dev> (raw)
In-Reply-To: <20250620221326.1261128-8-coltonlewis@google.com>

On Fri, Jun 20, 2025 at 10:13:07PM +0000, Colton Lewis wrote:
> For PMUv3, the register field MDCR_EL2.HPMN partitiones the PMU
> counters into two ranges where counters 0..HPMN-1 are accessible by
> EL1 and, if allowed, EL0 while counters HPMN..N are only accessible by
> EL2.
> 
> Create module parameters partition_pmu and reserved_guest_counters to
> reserve a number of counters for the guest. These numbers are set at
> boot because the perf subsystem assumes the number of counters will
> not change after the PMU is probed.
> 
> Introduce the function armv8pmu_partition() to modify the PMU driver's
> cntr_mask of available counters to exclude the counters being reserved
> for the guest and record reserved_guest_counters as the maximum
> allowable value for HPMN.
> 
> Due to the difficulty this feature would create for the driver running
> at EL1 on the host, partitioning is only allowed in VHE mode. Working
> on nVHE mode would require a hypercall for every counter access in the
> driver because the counters reserved for the host by HPMN are only
> accessible to EL2.
> 
> Signed-off-by: Colton Lewis <coltonlewis@google.com>
> ---
>  arch/arm/include/asm/arm_pmuv3.h   | 10 ++++
>  arch/arm64/include/asm/arm_pmuv3.h |  5 ++
>  drivers/perf/arm_pmuv3.c           | 95 +++++++++++++++++++++++++++++-
>  include/linux/perf/arm_pmu.h       |  1 +
>  4 files changed, 109 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arm_pmuv3.h b/arch/arm/include/asm/arm_pmuv3.h
> index 2ec0e5e83fc9..9dc43242538c 100644
> --- a/arch/arm/include/asm/arm_pmuv3.h
> +++ b/arch/arm/include/asm/arm_pmuv3.h
> @@ -228,6 +228,11 @@ static inline bool kvm_set_pmuserenr(u64 val)
>  
>  static inline void kvm_vcpu_pmu_resync_el0(void) {}
>  
> +static inline bool has_vhe(void)
> +{
> +	return false;
> +}
> +

This has nothing to do with PMUv3, I'm a bit surprised to see you're
touching 32-bit ARM. Can you just gate the whole partitioning thing on
arm64?

> +static bool partition_pmu __read_mostly;
> +static u8 reserved_guest_counters __read_mostly;
> +
> +module_param(partition_pmu, bool, 0);
> +MODULE_PARM_DESC(partition_pmu,
> +		 "Partition the PMU into host and guest VM counters [y/n]");
> +
> +module_param(reserved_guest_counters, byte, 0);
> +MODULE_PARM_DESC(reserved_guest_counters,
> +		 "How many counters to reserve for guest VMs [0-$NR_COUNTERS]");
> +

This is confusing and not what we discussed offline.

Please use a single parameter that describes the number of counters used
by the *host*. This affects the *host* PMU driver, KVM can discover (and
use) the leftovers.

If the single module parameter goes unspecified the user did not ask for
PMU partitioning.

> +/**
> + * armv8pmu_reservation_is_valid() - Determine if reservation is allowed
> + * @guest_counters: Number of host counters to reserve
> + *
> + * Determine if the number of host counters in the argument is
> + * allowed. It is allowed if it will produce a valid value for
> + * register field MDCR_EL2.HPMN.
> + *
> + * Return: True if reservation allowed, false otherwise
> + */
> +static bool armv8pmu_reservation_is_valid(u8 guest_counters)
> +{
> +	return guest_counters <= armv8pmu_pmcr_n_read();
> +}
> +
> +/**
> + * armv8pmu_partition_supported() - Determine if partitioning is possible
> + *
> + * Partitioning is only supported in VHE mode (with PMUv3, assumed
> + * since we are in the PMUv3 driver)
> + *
> + * Return: True if partitioning is possible, false otherwise
> + */
> +static bool armv8pmu_partition_supported(void)
> +{
> +	return has_vhe();
> +}
> +
> +/**
> + * armv8pmu_partition() - Partition the PMU
> + * @pmu: Pointer to pmu being partitioned
> + * @guest_counters: Number of host counters to reserve
> + *
> + * Partition the given PMU by taking a number of host counters to
> + * reserve and, if it is a valid reservation, recording the
> + * corresponding HPMN value in the hpmn field of the PMU and clearing
> + * the guest-reserved counters from the counter mask.
> + *
> + * Passing 0 for @guest_counters has the effect of disabling partitioning.
> + *
> + * Return: 0 on success, -ERROR otherwise
> + */
> +static int armv8pmu_partition(struct arm_pmu *pmu, u8 guest_counters)
> +{
> +	u8 nr_counters;
> +	u8 hpmn;
> +
> +	if (!armv8pmu_reservation_is_valid(guest_counters))
> +		return -EINVAL;
> +
> +	nr_counters = armv8pmu_pmcr_n_read();
> +	hpmn = guest_counters;
> +
> +	pmu->hpmn_max = hpmn;

I'm not sure the host driver needs this for anything, KVM just needs to
know what's potentially in use by the host.

> +	/* Inform host driver of available counters */

... said the driver to itself :)

Thanks,
Oliver

  reply	other threads:[~2025-06-21  1:07 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-20 22:13 [PATCH v2 00/23] ARM64 PMU Partitioning Colton Lewis
2025-06-20 22:13 ` [PATCH v2 01/23] arm64: cpufeature: Add cpucap for HPMN0 Colton Lewis
2025-06-21  0:44   ` Oliver Upton
2025-06-23 18:25     ` Colton Lewis
2025-06-24  7:28       ` Oliver Upton
2025-06-24 20:05         ` Colton Lewis
2025-06-20 22:13 ` [PATCH v2 02/23] arm64: Generate sign macro for sysreg Enums Colton Lewis
2025-06-20 22:13 ` [PATCH v2 03/23] arm64: cpufeature: Add cpucap for PMICNTR Colton Lewis
2025-06-21  0:45   ` Oliver Upton
2025-06-23 18:25     ` Colton Lewis
2025-06-20 22:13 ` [PATCH v2 04/23] arm64: Define PMI{CNTR,FILTR}_EL0 as undef_access Colton Lewis
2025-06-20 22:13 ` [PATCH v2 05/23] KVM: arm64: Cleanup PMU includes Colton Lewis
2025-06-21 14:56   ` kernel test robot
2025-06-23 22:04     ` Colton Lewis
2025-06-20 22:13 ` [PATCH v2 06/23] KVM: arm64: Reorganize PMU functions Colton Lewis
2025-06-20 22:13 ` [PATCH v2 07/23] perf: arm_pmuv3: Introduce method to partition the PMU Colton Lewis
2025-06-21  1:06   ` Oliver Upton [this message]
2025-06-23 18:26     ` Colton Lewis
2025-06-24  7:05       ` Oliver Upton
2025-06-24 20:05         ` Colton Lewis
2025-06-20 22:13 ` [PATCH v2 07/23] perf: pmuv3: " Colton Lewis
2025-06-20 22:13 ` [PATCH v2 08/23] perf: arm_pmuv3: Generalize counter bitmasks Colton Lewis
2025-06-20 22:13 ` [PATCH v2 09/23] perf: arm_pmuv3: Keep out of guest counter partition Colton Lewis
2025-06-20 22:13 ` [PATCH v2 10/23] KVM: arm64: Correct kvm_arm_pmu_get_max_counters() Colton Lewis
2025-06-20 22:13 ` [PATCH v2 11/23] KVM: arm64: Set up FGT for Partitioned PMU Colton Lewis
2025-06-20 22:13 ` [PATCH v2 12/23] KVM: arm64: Writethrough trapped PMEVTYPER register Colton Lewis
2025-06-20 22:13 ` [PATCH v2 13/23] KVM: arm64: Use physical PMSELR for PMXEVTYPER if partitioned Colton Lewis
2025-06-20 22:13 ` [PATCH v2 14/23] KVM: arm64: Writethrough trapped PMOVS register Colton Lewis
2025-06-20 22:13 ` [PATCH v2 15/23] KVM: arm64: Write fast path PMU register handlers Colton Lewis
2025-06-20 22:13 ` [PATCH v2 16/23] KVM: arm64: Setup MDCR_EL2 to handle a partitioned PMU Colton Lewis
2025-06-20 22:13 ` [PATCH v2 17/23] KVM: arm64: Account for partitioning in PMCR_EL0 access Colton Lewis
2025-06-22  9:32   ` kernel test robot
2025-06-23 22:11     ` Colton Lewis
2025-06-20 22:13 ` [PATCH v2 18/23] KVM: arm64: Context swap Partitioned PMU guest registers Colton Lewis
2025-06-20 22:13 ` [PATCH v2 19/23] KVM: arm64: Enforce PMU event filter at vcpu_load() Colton Lewis
2025-06-20 22:13 ` [PATCH v2 20/23] perf: arm_pmuv3: Handle IRQs for Partitioned PMU guest counters Colton Lewis
2025-06-20 22:13 ` [PATCH v2 20/23] perf: pmuv3: " Colton Lewis
2025-06-20 22:13 ` [PATCH v2 21/23] KVM: arm64: Inject recorded guest interrupts Colton Lewis
2025-06-20 22:13 ` [PATCH v2 22/23] KVM: arm64: Add ioctl to partition the PMU when supported Colton Lewis
2025-06-20 22:13 ` [PATCH v2 23/23] KVM: arm64: selftests: Add test case for partitioned PMU Colton Lewis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aFYFqrYRsmCi6oii@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=catalin.marinas@arm.com \
    --cc=coltonlewis@google.com \
    --cc=corbet@lwn.net \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=shuah@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).