From: Oliver Upton <oliver.upton@linux.dev>
To: Reiji Watanabe <reijiw@google.com>
Cc: Marc Zyngier <maz@kernel.org>,
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>,
Zenghui Yu <yuzenghui@huawei.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Jing Zhang <jingzhangos@google.com>,
Raghavendra Rao Anata <rananta@google.com>
Subject: Re: [PATCH v2 2/5] KVM: arm64: PMU: Disallow vPMU on non-uniform PMUVer systems
Date: Mon, 31 Jul 2023 09:41:02 -0700 [thread overview]
Message-ID: <ZMfkHrRNGNA7XLso@linux.dev> (raw)
In-Reply-To: <CAAeT=FyC42s=kcS3QTC6A-s6EZjhoQL7XJyxWCb5YyisJrQvdg@mail.gmail.com>
On Mon, Jul 31, 2023 at 04:54:04AM -0700, Reiji Watanabe wrote:
> Hi Oliver,
>
> > This doesn't actually disallow userspace from configuring a vPMU, it
> > only hides the KVM cap. kvm_host_pmu_init() will still insert the host
> > PMU instance in the list of valid PMUs, and there doesn't appear to be
> > any check against the static key anywhere on that path.
>
> In v6.5-rc3, which I used as the base, or even in v6.5-rc4,
> it appears kvm_reset_vcpu() checks against the static key.
> So, the initial KVM_ARM_VCPU_INIT with vPMU configured will
> fail on the systems. Or am I missing something ? (Or is that
> going to be removed by other patches that are already queued?)
No, I definitely missed something, sorry for the noise! I had only
checked the PMU attributes, forgot about feature flags for a moment.
> > I actually prefer where we flip the static key, as PMU context switching
> > depends on both KVM support as well as the PMU driver coming up successfully.
> > Instead, you could hoist the check against the sanitised PMU version into
> > kvm_host_pmu_init(), maybe something like:
>
> Thank you, it looks better. I will fix this in v3.
Sounds good, thanks!
--
Best,
Oliver
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Reiji Watanabe <reijiw@google.com>
Cc: Marc Zyngier <maz@kernel.org>,
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>,
Zenghui Yu <yuzenghui@huawei.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Jing Zhang <jingzhangos@google.com>,
Raghavendra Rao Anata <rananta@google.com>
Subject: Re: [PATCH v2 2/5] KVM: arm64: PMU: Disallow vPMU on non-uniform PMUVer systems
Date: Mon, 31 Jul 2023 09:41:02 -0700 [thread overview]
Message-ID: <ZMfkHrRNGNA7XLso@linux.dev> (raw)
In-Reply-To: <CAAeT=FyC42s=kcS3QTC6A-s6EZjhoQL7XJyxWCb5YyisJrQvdg@mail.gmail.com>
On Mon, Jul 31, 2023 at 04:54:04AM -0700, Reiji Watanabe wrote:
> Hi Oliver,
>
> > This doesn't actually disallow userspace from configuring a vPMU, it
> > only hides the KVM cap. kvm_host_pmu_init() will still insert the host
> > PMU instance in the list of valid PMUs, and there doesn't appear to be
> > any check against the static key anywhere on that path.
>
> In v6.5-rc3, which I used as the base, or even in v6.5-rc4,
> it appears kvm_reset_vcpu() checks against the static key.
> So, the initial KVM_ARM_VCPU_INIT with vPMU configured will
> fail on the systems. Or am I missing something ? (Or is that
> going to be removed by other patches that are already queued?)
No, I definitely missed something, sorry for the noise! I had only
checked the PMU attributes, forgot about feature flags for a moment.
> > I actually prefer where we flip the static key, as PMU context switching
> > depends on both KVM support as well as the PMU driver coming up successfully.
> > Instead, you could hoist the check against the sanitised PMU version into
> > kvm_host_pmu_init(), maybe something like:
>
> Thank you, it looks better. I will fix this in v3.
Sounds good, thanks!
--
Best,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-07-31 16:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 18:19 [PATCH v2 0/5] KVM: arm64: PMU: Fix PMUver related handling for vPMU support Reiji Watanabe
2023-07-28 18:19 ` Reiji Watanabe
2023-07-28 18:19 ` [PATCH v2 1/5] KVM: arm64: PMU: Use of pmuv3_implemented() instead of open-coded version Reiji Watanabe
2023-07-28 18:19 ` Reiji Watanabe
2023-07-28 18:19 ` [PATCH v2 2/5] KVM: arm64: PMU: Disallow vPMU on non-uniform PMUVer systems Reiji Watanabe
2023-07-28 18:19 ` Reiji Watanabe
2023-07-28 19:52 ` Oliver Upton
2023-07-28 19:52 ` Oliver Upton
2023-07-31 11:54 ` Reiji Watanabe
2023-07-31 11:54 ` Reiji Watanabe
2023-07-31 16:41 ` Oliver Upton [this message]
2023-07-31 16:41 ` Oliver Upton
2023-07-28 18:19 ` [PATCH v2 3/5] KVM: arm64: PMU: Avoid inappropriate use of host's PMUVer Reiji Watanabe
2023-07-28 18:19 ` Reiji Watanabe
2023-07-28 18:19 ` [PATCH v2 4/5] KVM: arm64: PMU: Don't advertise the STALL_SLOT event Reiji Watanabe
2023-07-28 18:19 ` Reiji Watanabe
2023-07-28 18:19 ` [PATCH v2 5/5] KVM: arm64: PMU: Don't advertise STALL_SLOT_{FRONTEND,BACKEND} Reiji Watanabe
2023-07-28 18:19 ` 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=ZMfkHrRNGNA7XLso@linux.dev \
--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.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=suzuki.poulose@arm.com \
--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.