[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87bjttqh6k.wl-maz@kernel.org>
Date: Sat, 22 Mar 2025 14:21:55 +0000
From: Marc Zyngier <maz@...nel.org>
To: Justin He <Justin.He@....com>
Cc: Oliver Upton <oliver.upton@...ux.dev>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"kvmarm@...ts.linux.dev"
<kvmarm@...ts.linux.dev>,
Joey Gouly <Joey.Gouly@....com>,
Colton Lewis
<coltonlewis@...gle.com>,
Suzuki Poulose <Suzuki.Poulose@....com>,
Zenghui Yu
<yuzenghui@...wei.com>,
Catalin Marinas <Catalin.Marinas@....com>,
Will
Deacon <will@...nel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when KVM is not initialised
On Sat, 22 Mar 2025 13:54:17 +0000,
Justin He <Justin.He@....com> wrote:
>
> Hi Marc,
>
> > -----Original Message-----
> > From: Marc Zyngier <maz@...nel.org>
> > Sent: Saturday, March 22, 2025 6:08 PM
> > To: Justin He <Justin.He@....com>
> > Cc: Oliver Upton <oliver.upton@...ux.dev>; linux-arm-
> > kernel@...ts.infradead.org; kvmarm@...ts.linux.dev; Joey Gouly
> > <Joey.Gouly@....com>; Suzuki Poulose <Suzuki.Poulose@....com>;
> > Zenghui Yu <yuzenghui@...wei.com>; Catalin Marinas
> > <Catalin.Marinas@....com>; Will Deacon <will@...nel.org>; linux-
> > kernel@...r.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@....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@....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@...ley-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.
Powered by blists - more mailing lists