Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@kernel.org>
To: Congkai Tan <congkai@amazon.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Haris Okanovic <harisokn@amazon.com>,
	Geoff Blake <blakgeof@amazon.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests
Date: Mon, 1 Jun 2026 13:06:17 -0700	[thread overview]
Message-ID: <ah3mObchzwb80_3S@kernel.org> (raw)
In-Reply-To: <20260601193954.2103455-1-congkai@amazon.com>

Hi Congkai,

On Mon, Jun 01, 2026 at 07:39:54PM +0000, Congkai Tan wrote:
> Commit 46081078feb4 ("KVM: arm64: Upgrade PMU support to ARMv8.4")
> trapped PMMIR_EL1 as RAZ/WI and masked STALL_SLOT* from PMCEID1 to
> discourage guests from relying on a register they could not read.
> 
> Forward the SLOTS field of PMMIR_EL1 so that the perf userspace tool
> can read the correct value from
> /sys/bus/event_source/devices/armv8_pmuv3_0/caps/slots. Today, perf
> stat fails with message "Failure to read '#slots'" because it can
> only read 0x0 from the sysfs location, causing the parsing failure
> of the default metrics.
> 
> Fix this by:
> 1. Adding an access_pmmir() handler that reads arm_pmu->reg_pmmir
>    and returns a masked value containing only the SLOTS field [7:0]
>    to the guest. Other PMMIR_EL1 fields are kept as RAZ to limit
>    the extra information that this change exposes; individual
>    fields can be unmasked as KVM gains support for each feature.
> 2. Removing the STALL_SLOT, STALL_SLOT_FRONTEND and STALL_SLOT_BACKEND
>    mask in PMCEID1. The mask existed to hide these events under the
>    sysfs events/ directory when PMMIR_EL1 was RAZ; with SLOTS now
>    readable they should be correctly exposed.
> 
> Tested on Graviton 2 (Neoverse N1, pre-PMUv3p4), Graviton 3
> (Neoverse V1) and Graviton 4 (Neoverse V2) metal hosts with QEMU:
> caps/slots reads 0x00000008 in guests on Graviton 3/4 and 0x00000000
> on Graviton 2 (correct for pre-PMUv3p4). perf stat correctly
> evaluates the default metrics.
> 
> Fixes: 46081078feb4 ("KVM: arm64: Upgrade PMU support to ARMv8.4")
> Cc: stable@vger.kernel.org

This is not stable-worthy, nor is it a bugfix. As KVM presently does not
implement the STALL_SLOTS* events, PMMIR_EL0.SLOTS = 0 is a legal
implementation of FEAT_PMUv3p4.

> ---
>  arch/arm64/kvm/pmu-emul.c | 11 +----------
>  arch/arm64/kvm/sys_regs.c | 26 ++++++++++++++++++++++++--
>  2 files changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index e1860acae641..bafd5a258927 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c
> @@ -864,16 +864,7 @@ static u64 compute_pmceid0(struct arm_pmu *pmu)
>  
>  static u64 compute_pmceid1(struct arm_pmu *pmu)
>  {
> -	u64 val = __compute_pmceid(pmu, 1);
> -
> -	/*
> -	 * Don't advertise STALL_SLOT*, as PMMIR_EL0 is handled
> -	 * as RAZ
> -	 */
> -	val &= ~(BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT - 32) |
> -		 BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT_FRONTEND - 32) |
> -		 BIT_ULL(ARMV8_PMUV3_PERFCTR_STALL_SLOT_BACKEND - 32));
> -	return val;
> +	return __compute_pmceid(pmu, 1);
>  }

Make the change to PMCEID1 in a separate patch from PMMIR_EL1.

> +/*
> + * Expose only PMMIR_EL1.SLOTS to the guest, which is consumed by perf in its
> + * topdown default metric group. Other PMMIR_EL1 fields remain RAZ. Future
> + * patches can extend the exposed mask incrementally as KVM gains support for
> + * those features.
> + */
> +static bool access_pmmir(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> +			 const struct sys_reg_desc *r)
> +{
> +	struct arm_pmu *cpu_pmu = vcpu->kvm->arch.arm_pmu;
> +
> +	if (p->is_write)
> +		return write_to_read_only(vcpu, p, r);
> +
> +	if (check_pmu_access_disabled(vcpu, 0))
> +		return false;
> +
> +	p->regval = cpu_pmu->reg_pmmir & ARMV8_PMU_SLOTS;
> +	return true;
> +}
> +

We can't change the value of PMMIR_EL1 unconditionally since older KVM
treated this register as RAZ/WI. This also mixes poorly with the default
PMU garbage that we have since as the value of the register can change
based on where KVM_ARM_VCPU_INIT gets called...

Considering everything, I'd like to see this wired up where:

 - PMMIR_EL1.SLOTS takes the value of the underlying hardware PMU only
   if the VMM explicitly selects a particular PMU implementation

 - KVM allows userspace to set PMMIR_EL1.SLOTS=0 for backwards
   compatibility

Thanks,
Oliver


  reply	other threads:[~2026-06-01 20:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 19:39 [PATCH] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests Congkai Tan
2026-06-01 20:06 ` Oliver Upton [this message]
2026-06-01 20:13   ` Oliver Upton
2026-06-02  4:14 ` kernel test robot

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=ah3mObchzwb80_3S@kernel.org \
    --to=oupton@kernel.org \
    --cc=blakgeof@amazon.com \
    --cc=catalin.marinas@arm.com \
    --cc=congkai@amazon.com \
    --cc=harisokn@amazon.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@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