linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Reiji Watanabe <reijiw@google.com>
Cc: Marc Zyngier <maz@kernel.org>,
	kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev,
	kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ricardo Koller <ricarkol@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	Raghavendra Rao Anata <rananta@google.com>
Subject: Re: [PATCH 0/7] KVM: arm64: PMU: Allow userspace to limit the number of PMCs on vCPU
Date: Tue, 10 Jan 2023 02:01:00 +0000	[thread overview]
Message-ID: <Y7zG3B3DmFZLU200@google.com> (raw)
In-Reply-To: <20221230035928.3423990-1-reijiw@google.com>

Hi Reiji,

On Thu, Dec 29, 2022 at 07:59:21PM -0800, Reiji Watanabe wrote:
> The goal of this series is to allow userspace to limit the number
> of PMU event counters on the vCPU.
> 
> 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 host value by default. Userspace can set PMCR_EL0.N for the
> vCPU to a lower value than the host value, 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.

I just wanted to bring up the conversation we had today on the list as
it is a pretty relevant issue.

KVM currently allows any value to be written to PMCR_EL0.N, meaning that
userspace could advertize more PMCs than are supported by the system.

IDK if Marc feels otherwise, but it doesn't seem like we should worry
about ABI change here (i.e. userspace can no longer write junk to the
register) as KVM has advertized the correct value to userspace. The only
case that breaks would be a userspace that intentionally sets PMCR_EL0.N
to something larger than the host. As accesses to unadvertized PMC
indices is CONSTRAINED UNPRED behavior, I'm having a hard time coming up
with a use case.

--
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-01-10  2:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30  3:59 [PATCH 0/7] KVM: arm64: PMU: Allow userspace to limit the number of PMCs on vCPU Reiji Watanabe
2022-12-30  3:59 ` [PATCH 1/7] KVM: arm64: PMU: Have reset_pmu_reg() to clear a register Reiji Watanabe
2023-01-08 19:07   ` Oliver Upton
2023-01-10  5:50     ` Reiji Watanabe
2022-12-30  3:59 ` [PATCH 2/7] KVM: arm64: PMU: Use reset_pmu_reg() for PMUSERENR_EL0 and PMCCFILTR_EL0 Reiji Watanabe
2023-01-08 19:13   ` Oliver Upton
2023-01-10  1:17     ` Reiji Watanabe
2023-01-10  1:46       ` Oliver Upton
2022-12-30  3:59 ` [PATCH 3/7] KVM: arm64: PMU: Preserve vCPU's PMCR_EL0.N value on vCPU reset Reiji Watanabe
2022-12-30  3:59 ` [PATCH 4/7] tools: arm64: Import perf_event.h Reiji Watanabe
2022-12-30  3:59 ` [PATCH 5/7] KVM: selftests: aarch64: Introduce vpmu_counter_access test Reiji Watanabe
2022-12-30  3:59 ` [PATCH 6/7] KVM: selftests: aarch64: vPMU register test for implemented counters Reiji Watanabe
2022-12-30  3:59 ` [PATCH 7/7] KVM: selftests: aarch64: vPMU register test for unimplemented counters Reiji Watanabe
2023-01-03 12:40 ` [PATCH 0/7] KVM: arm64: PMU: Allow userspace to limit the number of PMCs on vCPU Jonathan Cameron
2023-01-03 12:47   ` Marc Zyngier
2023-01-05  2:59     ` Reiji Watanabe
2023-01-10  2:01 ` Oliver Upton [this message]
2023-01-11  0:55   ` Reiji Watanabe

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=Y7zG3B3DmFZLU200@google.com \
    --to=oliver.upton@linux.dev \
    --cc=alexandru.elisei@arm.com \
    --cc=james.morse@arm.com \
    --cc=jingzhangos@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rananta@google.com \
    --cc=reijiw@google.com \
    --cc=ricarkol@google.com \
    --cc=suzuki.poulose@arm.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).