From: Oliver Upton <oliver.upton@linux.dev>
To: James Clark <james.clark@arm.com>
Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, broonie@kernel.org, maz@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 13:04:51 +0000 [thread overview]
Message-ID: <ZcDc8-FQo8wKavA4@linux.dev> (raw)
In-Reply-To: <8a908ee8-620a-d9c2-734b-5a6402950072@arm.com>
On Mon, Feb 05, 2024 at 12:16:53PM +0000, James Clark wrote:
> > This now allows the host to program event counters for a protected
> > guest. That _might_ be a useful feature behind some debug option, but is
> > most definitely *not* something we want to do for pVMs generally.
>
> Unless I'm missing something, using PMUs on protected guests was added
> by 722625c6f4c5b ("KVM: arm64: Reenable pmu in Protected Mode"). This
> change is just a refactor that will allow us to add the same behavior
> for a similar feature (tracing) without adding yet another copy of some
> state before the guest switch.
Ha, I had forgotten about that patch (and I had reviewed it!)
My interpretation of the intent for that change was to enable the usage
of vPMU for non-protected VMs. The situation has changed since then, as
we use the shadow state for vCPUs unconditionally in protected mode as
of commit be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure
in handle___kvm_vcpu_run()")
Protected mode is well understood at this point to be a WIP feature, and
that not all things are expected to work with it. Eventually we will
need a way to distinguish between 'normal' VMs and true pVMs (i.e. the
VMM selected full isolation) in nVHE, but right now what we have enables
testing of some isolation features.
> > I'm perfectly happy leaving these sorts of features broken for pKVM and
> > using the 'normal' way of getting percpu data to the nVHE hypervisor
> > otherwise.
> >
>
> I can do that. But do I also disable PMU at the same time in a new
> commit? Now that both PMU and tracing is working maybe it would be a
> waste to throw that away and hiding it behind an option is better. Or I
> can leave the PMU as it is and just keep tracing disabled in pKVM.
>
> I don't mind either way, my main goal was to get exclude/include guest
> tracing working for normal VMs. For pKVM I don't have a strong opinion.
Unless someone has strong opinions about making this work in protected
mode, I am happy to see tracing support limited to the 'normal' nVHE
configuration. The protected feature as a whole is just baggage until
upstream support is completed.
--
Thanks,
Oliver
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: James Clark <james.clark@arm.com>
Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, broonie@kernel.org, maz@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 13:04:51 +0000 [thread overview]
Message-ID: <ZcDc8-FQo8wKavA4@linux.dev> (raw)
In-Reply-To: <8a908ee8-620a-d9c2-734b-5a6402950072@arm.com>
On Mon, Feb 05, 2024 at 12:16:53PM +0000, James Clark wrote:
> > This now allows the host to program event counters for a protected
> > guest. That _might_ be a useful feature behind some debug option, but is
> > most definitely *not* something we want to do for pVMs generally.
>
> Unless I'm missing something, using PMUs on protected guests was added
> by 722625c6f4c5b ("KVM: arm64: Reenable pmu in Protected Mode"). This
> change is just a refactor that will allow us to add the same behavior
> for a similar feature (tracing) without adding yet another copy of some
> state before the guest switch.
Ha, I had forgotten about that patch (and I had reviewed it!)
My interpretation of the intent for that change was to enable the usage
of vPMU for non-protected VMs. The situation has changed since then, as
we use the shadow state for vCPUs unconditionally in protected mode as
of commit be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure
in handle___kvm_vcpu_run()")
Protected mode is well understood at this point to be a WIP feature, and
that not all things are expected to work with it. Eventually we will
need a way to distinguish between 'normal' VMs and true pVMs (i.e. the
VMM selected full isolation) in nVHE, but right now what we have enables
testing of some isolation features.
> > I'm perfectly happy leaving these sorts of features broken for pKVM and
> > using the 'normal' way of getting percpu data to the nVHE hypervisor
> > otherwise.
> >
>
> I can do that. But do I also disable PMU at the same time in a new
> commit? Now that both PMU and tracing is working maybe it would be a
> waste to throw that away and hiding it behind an option is better. Or I
> can leave the PMU as it is and just keep tracing disabled in pKVM.
>
> I don't mind either way, my main goal was to get exclude/include guest
> tracing working for normal VMs. For pKVM I don't have a strong opinion.
Unless someone has strong opinions about making this work in protected
mode, I am happy to see tracing support limited to the 'normal' nVHE
configuration. The protected feature as a whole is just baggage until
upstream support is completed.
--
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 13:04 UTC|newest]
Thread overview: 56+ 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 ` James Clark
2024-01-04 16:27 ` [PATCH v4 1/7] arm64: KVM: Fix renamed function in comment James Clark
2024-01-04 16:27 ` James Clark
2024-01-04 16:58 ` Suzuki K Poulose
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-04 16:27 ` James Clark
2024-01-05 9:40 ` Suzuki K Poulose
2024-01-05 9:40 ` Suzuki K Poulose
2024-02-01 16:14 ` James Clark
2024-02-01 16:14 ` James Clark
2024-02-02 22:00 ` Oliver Upton
2024-02-02 22:00 ` Oliver Upton
2024-02-05 12:16 ` James Clark
2024-02-05 12:16 ` James Clark
2024-02-05 13:04 ` Oliver Upton [this message]
2024-02-05 13:04 ` Oliver Upton
2024-02-05 13:15 ` Marc Zyngier
2024-02-05 13:15 ` Marc Zyngier
2024-02-05 13:21 ` Oliver Upton
2024-02-05 13:21 ` Oliver Upton
2024-02-05 14:16 ` Marc Zyngier
2024-02-05 14:16 ` Marc Zyngier
2024-02-05 14:17 ` James Clark
2024-02-05 14:17 ` James Clark
2024-02-05 14:52 ` Marc Zyngier
2024-02-05 14:52 ` Marc Zyngier
2024-02-05 15:37 ` James Clark
2024-02-05 15:37 ` James Clark
2024-02-05 15:50 ` Marc Zyngier
2024-02-05 15:50 ` Marc Zyngier
2024-02-05 16:38 ` Oliver Upton
2024-02-05 16:38 ` Oliver Upton
2024-01-04 16:27 ` [PATCH v4 3/7] arm64/sysreg/tools: Move TRFCR definitions to sysreg James Clark
2024-01-04 16:27 ` James Clark
2024-01-05 9:18 ` Suzuki K Poulose
2024-01-05 9:18 ` Suzuki K Poulose
2024-01-05 9:59 ` James Clark
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 ` 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-04 16:27 ` James Clark
2024-01-05 9:20 ` Suzuki K Poulose
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-04 16:27 ` James Clark
2024-01-05 9:50 ` Suzuki K Poulose
2024-01-05 9:50 ` Suzuki K Poulose
2024-01-05 10:05 ` James Clark
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-04 16:27 ` James Clark
2024-01-05 9:55 ` Suzuki K Poulose
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=ZcDc8-FQo8wKavA4@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 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.