From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: James Clark <james.clark@arm.com>,
coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, broonie@kernel.org,
suzuki.poulose@arm.com, acme@kernel.org,
James Morse <james.morse@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mike Leach <mike.leach@linaro.org>,
Leo Yan <leo.yan@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Rob Herring <robh@kernel.org>,
Miguel Luis <miguel.luis@oracle.com>,
Jintack Lim <jintack.lim@linaro.org>,
Ard Biesheuvel <ardb@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
Vincent Donnefort <vdonnefort@google.com>,
Kristina Martsenko <kristina.martsenko@arm.com>,
Fuad Tabba <tabba@google.com>, Joey Gouly <joey.gouly@arm.com>,
Akihiko Odaki <akihiko.odaki@daynix.com>,
Jing Zhang <jingzhangos@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/7] arm64: KVM: Use shared area to pass PMU event state to hypervisor
Date: Mon, 5 Feb 2024 16:38:55 +0000 [thread overview]
Message-ID: <ZcEPHyfQ4n23YOTW@linux.dev> (raw)
In-Reply-To: <861q9q7vwr.wl-maz@kernel.org>
On Mon, Feb 05, 2024 at 03:50:12PM +0000, Marc Zyngier wrote:
> On Mon, 05 Feb 2024 15:37:34 +0000,
> James Clark <james.clark@arm.com> wrote:
> >
> > Hmmm in that case if there's currently no way to distinguish between
> > normal VMs and pVMs in protected-mode then what I was thinking of
> > probably won't work.
>
> Have you looked? kvm_vm_is_protected() has been in for a while, even
> if that's not a lot. The upcoming code will flesh this helper out,
Blame me for the bad intel. What I was mentioning earlier is that (1) we
use the hyp's shadowed vCPUs when running in protected mode and (2) we
don't sync PMU state into the shadow vCPU. So really PMU support for
non-protected guests has been broken since commit be66e67f1750 ("KVM:
arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()").
Fixing PMU support for non-protected guests implies the hypervisor will
conditionally trust data coming from the host based on the type of VM
that it is running.
For protected guests the hypervisor will need a private location to
do save/restore of the enable regs since I'm certain we will not trust
whatever the host tells us in these circumstances.
Both of these reasons has me feeling like the PMU context still needs to
be associated with the vCPU, though the tracing stuff can be percpu.
--
Thanks,
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:[~2024-02-05 16:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 16:27 [PATCH v4 0/7] kvm/coresight: Support exclude guest and exclude host James Clark
2024-01-04 16:27 ` [PATCH v4 1/7] arm64: KVM: Fix renamed function in comment James Clark
2024-01-04 16:58 ` Suzuki K Poulose
2024-01-04 16:27 ` [PATCH v4 2/7] arm64: KVM: Use shared area to pass PMU event state to hypervisor James Clark
2024-01-05 9:40 ` Suzuki K Poulose
2024-02-01 16:14 ` James Clark
2024-02-02 22:00 ` Oliver Upton
2024-02-05 12:16 ` James Clark
2024-02-05 13:04 ` Oliver Upton
2024-02-05 13:15 ` Marc Zyngier
2024-02-05 13:21 ` Oliver Upton
2024-02-05 14:16 ` Marc Zyngier
2024-02-05 14:17 ` James Clark
2024-02-05 14:52 ` Marc Zyngier
2024-02-05 15:37 ` James Clark
2024-02-05 15:50 ` Marc Zyngier
2024-02-05 16:38 ` Oliver Upton [this message]
2024-01-04 16:27 ` [PATCH v4 3/7] arm64/sysreg/tools: Move TRFCR definitions to sysreg James Clark
2024-01-05 9:18 ` Suzuki K Poulose
2024-01-05 9:59 ` James Clark
2024-01-04 16:27 ` [PATCH v4 4/7] arm64: KVM: Add iflag for FEAT_TRF James Clark
2024-01-04 16:27 ` [PATCH v4 5/7] arm64: KVM: Add interface to set guest value for TRFCR register James Clark
2024-01-05 9:20 ` Suzuki K Poulose
2024-01-04 16:27 ` [PATCH v4 6/7] arm64: KVM: Write TRFCR value on guest switch with nVHE James Clark
2024-01-05 9:50 ` Suzuki K Poulose
2024-01-05 10:05 ` James Clark
2024-01-04 16:27 ` [PATCH v4 7/7] coresight: Pass guest TRFCR value to KVM James Clark
2024-01-05 9:55 ` 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=ZcEPHyfQ4n23YOTW@linux.dev \
--to=oliver.upton@linux.dev \
--cc=acme@kernel.org \
--cc=akihiko.odaki@daynix.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=coresight@lists.linaro.org \
--cc=james.clark@arm.com \
--cc=james.morse@arm.com \
--cc=jingzhangos@google.com \
--cc=jintack.lim@linaro.org \
--cc=joey.gouly@arm.com \
--cc=kristina.martsenko@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=miguel.luis@oracle.com \
--cc=mike.leach@linaro.org \
--cc=robh@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.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;
as well as URLs for NNTP newsgroup(s).