[PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when KVM is not initialised

[PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when KVM is not initialised

[Jia He]

Currently, `kvm_host_pmu_init()` does not check if KVM has been
successfully initialized before proceeding. This can lead to unintended
behavior if the function is called in an environment where KVM is not
available, e.g., kernel is landed in EL1.

Signed-off-by: Jia He <justin.he@arm.com>
---
 arch/arm64/kvm/pmu.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/kvm/pmu.c b/arch/arm64/kvm/pmu.c
index 7169c1a24dd6..e39c48d12b81 100644
--- a/arch/arm64/kvm/pmu.c
+++ b/arch/arm64/kvm/pmu.c
@@ -227,6 +227,13 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
 {
 	struct arm_pmu_entry *entry;
 
+	/*
+	 * Prevent unintended behavior where KVM is not available or not
+	 * successfully initialised, e.g., kernel is landed in EL1.
+	 */
+	if (!is_kvm_arm_initialised())
+		return;
+
 	/*
 	 * Check the sanitised PMU version for the system, as KVM does not
 	 * support implementations where PMUv3 exists on a subset of CPUs.
-- 
2.34.1

Re: [PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when KVM is not initialised

[Marc Zyngier]

On Sat, 22 Mar 2025 03:51:15 +0000,
Jia He <justin.he@arm.com> wrote:
> 
> Currently, `kvm_host_pmu_init()` does not check if KVM has been
> successfully initialized before proceeding. This can lead to unintended
> behavior if the function is called in an environment where KVM is not

Which unintended behaviour? Other than the pointless allocation of a
tiny amount of memory? Does anything really go wrong?

> available, e.g., kernel is landed in EL1.

s/landed in/booted from/

> 
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
>  arch/arm64/kvm/pmu.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm64/kvm/pmu.c b/arch/arm64/kvm/pmu.c
> index 7169c1a24dd6..e39c48d12b81 100644
> --- a/arch/arm64/kvm/pmu.c
> +++ b/arch/arm64/kvm/pmu.c
> @@ -227,6 +227,13 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)

Huh:

maz@valley-girl:~/hot-poop/arm-platforms$ git grep -l kvm_host_pmu_init
arch/arm64/kvm/pmu-emul.c
drivers/perf/arm_pmu.c
include/linux/perf/arm_pmu.h

Amusingly, arch/arm64/kvm/pmu.c is nowhere to be seen in this list.
I have no idea what this patch applies to, but that's neither 6.13,
the current upstream, nor kvmarm/next.

>  {
>  	struct arm_pmu_entry *entry;
>  
> +	/*
> +	 * Prevent unintended behavior where KVM is not available or not
> +	 * successfully initialised, e.g., kernel is landed in EL1.

Same comment here.

> +	 */
> +	if (!is_kvm_arm_initialised())

This is definitely the wrong thing to check for, as it relies on the
probe ordering between the PMU drivers and KVM. Relying on that is not
acceptable.

If you're worried about a kernel booted at EL1, then check for that.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

RE: [PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when KVM is not initialised

[Justin He]

Hi Marc,

> -----Original Message-----
> From: Marc Zyngier <maz@kernel.org>
> Sent: Saturday, March 22, 2025 6:08 PM
> To: Justin He <Justin.He@arm.com>
> Cc: Oliver Upton <oliver.upton@linux.dev>; linux-arm-
> kernel@lists.infradead.org; kvmarm@lists.linux.dev; Joey Gouly
> <Joey.Gouly@arm.com>; Suzuki Poulose <Suzuki.Poulose@arm.com>;
> Zenghui Yu <yuzenghui@huawei.com>; Catalin Marinas
> <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when
> KVM is not initialised
> 
> On Sat, 22 Mar 2025 03:51:15 +0000,
> Jia He <justin.he@arm.com> wrote:
> >
> > Currently, `kvm_host_pmu_init()` does not check if KVM has been
> > successfully initialized before proceeding. This can lead to
> > unintended behavior if the function is called in an environment where
> > KVM is not
> 
> Which unintended behaviour? Other than the pointless allocation of a tiny
> amount of memory? Does anything really go wrong?
> 
Sorry for the confusion --- I should explain more clearly.
I noticed the usage of host_data_ptr in Colton Lewis's RFC patch [1]. After
applying the patch, the guest VM fails to boot.Upon investigating the root
cause, I found that host_data_ptr can trigger a kernel panic if KVM is not
initialized.

[1] https://patchwork.kernel.org/project/kvm/patch/20250213180317.3205285-6-coltonlewis@google.com/
> > available, e.g., kernel is landed in EL1.
> 
> s/landed in/booted from/
> 
> >
> > Signed-off-by: Jia He <justin.he@arm.com>
> > ---
> >  arch/arm64/kvm/pmu.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/pmu.c b/arch/arm64/kvm/pmu.c index
> > 7169c1a24dd6..e39c48d12b81 100644
> > --- a/arch/arm64/kvm/pmu.c
> > +++ b/arch/arm64/kvm/pmu.c
> > @@ -227,6 +227,13 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
> 
> Huh:
> 
> maz@valley-girl:~/hot-poop/arm-platforms$ git grep -l kvm_host_pmu_init
> arch/arm64/kvm/pmu-emul.c drivers/perf/arm_pmu.c
> include/linux/perf/arm_pmu.h
> 
> Amusingly, arch/arm64/kvm/pmu.c is nowhere to be seen in this list.
> I have no idea what this patch applies to, but that's neither 6.13, the current
> upstream, nor kvmarm/next.
Sorry for the mistake, the patch is based on Colton Lewis's series.
I’ll need to respin it if you're interested in the fix 😊

> >  {
> >  	struct arm_pmu_entry *entry;
> >
> > +	/*
> > +	 * Prevent unintended behavior where KVM is not available or not
> > +	 * successfully initialised, e.g., kernel is landed in EL1.
> 
> Same comment here.
> 
> > +	 */
> > +	if (!is_kvm_arm_initialised())
> 
> This is definitely the wrong thing to check for, as it relies on the probe
> ordering between the PMU drivers and KVM. Relying on that is not
> acceptable.
> 
Indeed, would is_hyp_mode_available() be a proper replacement for
is_kvm_arm_initialised() here?
Or should we add a prevention condition in host_data_ptr instead?

> If you're worried about a kernel booted at EL1, then check for that.
> 

--- 
Cheers,
Justin He(Jia He)

Re: [PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when KVM is not initialised

[Marc Zyngier]

On Sat, 22 Mar 2025 13:54:17 +0000,
Justin He <Justin.He@arm.com> wrote:
> 
> Hi Marc,
> 
> > -----Original Message-----
> > From: Marc Zyngier <maz@kernel.org>
> > Sent: Saturday, March 22, 2025 6:08 PM
> > To: Justin He <Justin.He@arm.com>
> > Cc: Oliver Upton <oliver.upton@linux.dev>; linux-arm-
> > kernel@lists.infradead.org; kvmarm@lists.linux.dev; Joey Gouly
> > <Joey.Gouly@arm.com>; Suzuki Poulose <Suzuki.Poulose@arm.com>;
> > Zenghui Yu <yuzenghui@huawei.com>; Catalin Marinas
> > <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when
> > KVM is not initialised
> > 
> > On Sat, 22 Mar 2025 03:51:15 +0000,
> > Jia He <justin.he@arm.com> wrote:
> > >
> > > Currently, `kvm_host_pmu_init()` does not check if KVM has been
> > > successfully initialized before proceeding. This can lead to
> > > unintended behavior if the function is called in an environment where
> > > KVM is not
> > 
> > Which unintended behaviour? Other than the pointless allocation of a tiny
> > amount of memory? Does anything really go wrong?
> > 
> Sorry for the confusion --- I should explain more clearly.
> I noticed the usage of host_data_ptr in Colton Lewis's RFC patch [1]. After
> applying the patch, the guest VM fails to boot.Upon investigating the root
> cause, I found that host_data_ptr can trigger a kernel panic if KVM is not
> initialized.

How relevant is this for upstream?

> 
> [1] https://patchwork.kernel.org/project/kvm/patch/20250213180317.3205285-6-coltonlewis@google.com/
> > > available, e.g., kernel is landed in EL1.
> > 
> > s/landed in/booted from/
> > 
> > >
> > > Signed-off-by: Jia He <justin.he@arm.com>
> > > ---
> > >  arch/arm64/kvm/pmu.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/arch/arm64/kvm/pmu.c b/arch/arm64/kvm/pmu.c index
> > > 7169c1a24dd6..e39c48d12b81 100644
> > > --- a/arch/arm64/kvm/pmu.c
> > > +++ b/arch/arm64/kvm/pmu.c
> > > @@ -227,6 +227,13 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
> > 
> > Huh:
> > 
> > maz@valley-girl:~/hot-poop/arm-platforms$ git grep -l kvm_host_pmu_init
> > arch/arm64/kvm/pmu-emul.c drivers/perf/arm_pmu.c
> > include/linux/perf/arm_pmu.h
> > 
> > Amusingly, arch/arm64/kvm/pmu.c is nowhere to be seen in this list.
> > I have no idea what this patch applies to, but that's neither 6.13, the current
> > upstream, nor kvmarm/next.
> Sorry for the mistake, the patch is based on Colton Lewis's series.
> I’ll need to respin it if you're interested in the fix 😊

I'm interested in a patch if:

- the patch applies to an upstream or a kvmarm tag
- the patch fixes *something* in the upstream code
- the commit message accurately describes the problem

Otherwise, no, thank you.

> > >  {
> > >  	struct arm_pmu_entry *entry;
> > >
> > > +	/*
> > > +	 * Prevent unintended behavior where KVM is not available or not
> > > +	 * successfully initialised, e.g., kernel is landed in EL1.
> > 
> > Same comment here.
> > 
> > > +	 */
> > > +	if (!is_kvm_arm_initialised())
> > 
> > This is definitely the wrong thing to check for, as it relies on the probe
> > ordering between the PMU drivers and KVM. Relying on that is not
> > acceptable.
> > 
> Indeed, would is_hyp_mode_available() be a proper replacement for
> is_kvm_arm_initialised() here?

Looks more appropriate, at least for upstream.
> Or should we add a prevention condition in host_data_ptr instead?

I can't comment about a series that I haven't reviewed and that is not
yet targeting upstream. But using host_data_ptr() from outside of KVM
is plain wrong, as it falls into the same trap as above. Checking for
random init flags is not going to help with that.

Instead of posting random patches that make no sense for upstream, why
don't you instead reply to Colton's series outlining your concerns and
findings? It sounds to me like a more useful way to make progress.

	M.

-- 
Without deviation from the norm, progress is not possible.