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>
Subject: Re: [PATCH v2 2/2] KVM: arm64: Virtualise PMEVTYPER<n>_EL1.{NSU,NSK}
Date: Wed, 18 Oct 2023 18:24:11 +0000 [thread overview]
Message-ID: <ZTAiy7Ijq2UmySyX@linux.dev> (raw)
In-Reply-To: <86o7gwm50g.wl-maz@kernel.org>
On Wed, Oct 18, 2023 at 02:31:11PM +0100, Marc Zyngier wrote:
> On Fri, 13 Oct 2023 06:29:01 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > Suzuki noticed that KVM's PMU emulation is oblivious to the NSU and NSK
> > event filter bits. On systems that have EL3 these bits modify the
> > filter behavior in non-secure EL0 and EL1, respectively. Even though the
> > kernel doesn't use these bits, it is entirely possible some other guest
> > OS does.
>
> But what does it mean for KVM itself? We have no EL3 to speak of as
> far as a guest is concerned. And the moment we allow things like
> NSU/NSK to be set, why don't we allow M as well?
Yeah, we need to have a think about all these extra bits TBH.
KVM doesn't filter the advertised ELs in PFR0, so from the guest POV
both EL2 and EL3 could potentially be implemented by the vCPU. Based
on that I think the bits at least need to be stateful, even though KVM's
emulation will never let the guest count events in a higher EL.
My patches aren't even consistent with the above statement, as NSH gets
RES0 treatment and the NS{U,K} bits do not. So how about this:
- If EL3 is advertised in the guest's ID registers NS{U,K}, and M can
be set. NS{U,K} work as proposed, M is ignored in KVM emulation.
- If EL2 is advertised in the guest's ID registers NSH can be set but
is ignored in KVM emulation.
Thoughts?
--
Thanks,
Oliver
next prev parent reply other threads:[~2023-10-18 18:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 5:28 [PATCH v2 0/2] KVM: arm64: PMU event filtering fixes Oliver Upton
2023-10-13 5:29 ` [PATCH v2 1/2] KVM: arm64: Treat PMEVTYPER<n>_EL0.NSH as RES0 Oliver Upton
2023-10-13 5:29 ` [PATCH v2 2/2] KVM: arm64: Virtualise PMEVTYPER<n>_EL1.{NSU,NSK} Oliver Upton
2023-10-13 5:56 ` Oliver Upton
2023-10-18 13:31 ` Marc Zyngier
2023-10-18 18:24 ` Oliver Upton [this message]
2023-10-19 7:20 ` Marc Zyngier
2023-10-16 12:47 ` [PATCH v2 0/2] KVM: arm64: PMU event filtering fixes Suzuki K Poulose
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=ZTAiy7Ijq2UmySyX@linux.dev \
--to=oliver.upton@linux.dev \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox