From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Raghavendra Rao Ananta <rananta@google.com>,
Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will@kernel.org>, James Clark <james.clark@arm.com>
Subject: Re: [PATCH 1/2] KVM: arm64: Disallow vPMU for NV guests
Date: Wed, 11 Oct 2023 16:43:16 +0000 [thread overview]
Message-ID: <ZSbQpJADvMOHgs3A@linux.dev> (raw)
In-Reply-To: <281b88c0d74b9260b659e6be579a4984@kernel.org>
On Wed, Oct 11, 2023 at 04:54:49PM +0100, Marc Zyngier wrote:
> On 2023-10-11 09:16, Oliver Upton wrote:
> > The existing PMU emulation code is inadequate for use with nested
> > virt. Disable the feature altogether with NV until the hypervisor
> > controls are handled correctly.
>
> Could you at least mention *what* is missing? Most of the handling
> should identical, and the couple of bits what would need to be
> handled (such as MDCR_EL2) are not covered by this disabling.
Heh, I could've spelled it out a bit more :)
The part that caught my attention is that we don't honor the NSH bit
(hence the next patch), and doing that correctly isn't going to be
trivial. In cases where event filtering is mismatched between vEL2
and EL1 I think we need to reprogram the associated perf events on
nested transitions. We could probably optimize this by using two sets of
perf events to make the switch a bit faster, but that's beside the
point.
Looks like MDCR_EL2.{HPMN,HPME} aren't handled yet either. These are all
easy enough to work on (and my interest is certainly piqued), but it
seems to me PMU+NV isn't going to work out of the gate. It'd be nice to
permit the combination only when we're confident the feature is
complete.
I haven't any strong opinions here though, and you're the one carrying
the whole NV pile in the first place. Up to you what to do here.
--
Thanks,
Oliver
next prev parent reply other threads:[~2023-10-11 16:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 8:16 [PATCH 0/2] KVM: arm64: vPMU fixes for NV/EL2 Oliver Upton
2023-10-11 8:16 ` [PATCH 1/2] KVM: arm64: Disallow vPMU for NV guests Oliver Upton
2023-10-11 15:54 ` Marc Zyngier
2023-10-11 16:43 ` Oliver Upton [this message]
2023-10-11 8:16 ` [PATCH 2/2] KVM: arm64: Treat PMEVTYPER<n>_EL0.NSH as RES0 Oliver Upton
2023-10-11 12:33 ` Suzuki K Poulose
2023-10-11 16:17 ` Oliver Upton
2023-10-12 15:33 ` Suzuki K Poulose
2023-10-12 9:43 ` James Clark
2023-10-12 12:47 ` Oliver Upton
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=ZSbQpJADvMOHgs3A@linux.dev \
--to=oliver.upton@linux.dev \
--cc=james.clark@arm.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=rananta@google.com \
--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