All of 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>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Haris Okanovic <harisokn@amazon.com>,
	Geoff Blake <blakgeof@amazon.com>,
	Stanislav Spassov <stanspas@amazon.de>,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests
Date: Tue, 7 Jul 2026 15:28:40 -0700	[thread overview]
Message-ID: <ak19mPPWcupFwfuE@kernel.org> (raw)
In-Reply-To: <20260702190421.420992-1-congkai@amazon.com>

Hi Congkai,

Thanks for respinning.

On Thu, Jul 02, 2026 at 07:04:18PM +0000, Congkai Tan wrote:
> Today when the perf tool runs in a guest on cores with PMUv3p4, it fails
> to parse the default metrics with "Failure to read '#slots'", since perf
> can only read 0 from sysfs caps/slots, which is backed by PMMIR_EL1.SLOTS
> that KVM traps as RAZ/WI.
> 
> Taking into account backward compatibility and heterogeneous systems, the
> exposure of PMMIR_EL1.SLOTS is gated behind a new vCPU feature flag:
> 
> - Patch 1 adds the new flag KVM_ARM_VCPU_PMU_V3_STRICT. When set, KVM does
>   not create a default PMU during vCPU init, and the VMM must select one
>   explicitly via KVM_ARM_VCPU_PMU_V3_SET_PMU before the first KVM_RUN.
> - Patch 2 exposes PMMIR_EL1.SLOTS of the selected PMU under the flag, and
>   adds userspace get/set for PMMIR_EL1 so that SLOTS can be reset to 0
>   for backward compatibility.
> - Patch 3 stops masking STALL_SLOT* in PMCEID1 under the flag.

I think the series is starting to shape up. Few more things to address:

 - Didn't mention it in v1, but writes to PMCR_EL0.N should be ignored
   when V3_STRICT is set. We now have a vCPU attribute for configuring
   event counters and the register-based thing is just broken :)

 - The vCPU feature flag needs a corresponding KVM_CAP so userspace can
   detect it

 - In terms of patch ordering, the vCPU flag / KVM_CAP exposure should
   come last after all the behavior changes are implemented (and
   flag-guarded)

 - Move enforcement of a non-NULL arm_pmu to kvm_arm_pmu_v3_init() since
   userspace must call KVM_ARM_VCPU_PMU_V3_INIT before KVM_RUN

 - Prevent the PMU event filter from being configured until a hardware
   PMU has been selected

I've addressed all of this locally and pushed to my tree [*]. Untested,
as always :) Would you be able to give it a spin?

Also, do you have VMM patches for using the new feature flag?

[*]: https://git.kernel.org/pub/scm/linux/kernel/git/oupton/linux.git/log/?h=kvm-arm64/pmu-7.3

Thanks,
Oliver

  parent reply	other threads:[~2026-07-07 22:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 19:04 [PATCH v2 0/3] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests Congkai Tan
2026-07-02 19:04 ` [PATCH v2 1/3] KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_STRICT vCPU feature Congkai Tan
2026-07-02 19:29   ` sashiko-bot
2026-07-02 19:04 ` [PATCH v2 2/3] KVM: arm64: Expose PMMIR_EL1.SLOTS under strict PMUv3 UAPI Congkai Tan
2026-07-02 19:04 ` [PATCH v2 3/3] KVM: arm64: Advertise STALL_SLOT* in PMCEID1 " Congkai Tan
2026-07-07 22:28 ` Oliver Upton [this message]
2026-07-10  6:44   ` [PATCH v2 0/3] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests Congkai Tan

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=ak19mPPWcupFwfuE@kernel.org \
    --to=oupton@kernel.org \
    --cc=blakgeof@amazon.com \
    --cc=catalin.marinas@arm.com \
    --cc=congkai@amazon.com \
    --cc=corbet@lwn.net \
    --cc=harisokn@amazon.com \
    --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=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=stanspas@amazon.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.