From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 72F9C1D5CD4; Sat, 22 Mar 2025 14:22:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742653322; cv=none; b=b6Bo2I1pt2qIQelbkST5vnfRRtcVtulC8ukd+WAb5MnLwnnGYN9Agk3Ue1OQ9Vbhbg0pgbnp3XLWsOxLHvOi/IPfTYFB1Lj9Z79MkdWc4rT1pDGTZuM8dn1HiQK8UFaOVLLavvQkanEShYhBAb/LNx/EvOcoxFcxQo5L7Q0KOEc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742653322; c=relaxed/simple; bh=TIu42g6hbijrCcZuE/1tP1wo0BubLGFRertECUWE7Sc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ObSYCsBEnEXZXxx0QQrYUKfjujbLYwvsuVlXq0lXHMcoMnUThYjrvO4XWFqRn7vBAKRLQkMXv2S+nRCmDTBwWbOvJorquET0/tOjNETdc39diLGqfa+iDjMHG4JHqYZyAIq+l7/SX6zkUodEA0FPgxIZWpU234DuxSWeq22w87E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p1tyYzkF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p1tyYzkF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7A76C4CEDD; Sat, 22 Mar 2025 14:22:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742653321; bh=TIu42g6hbijrCcZuE/1tP1wo0BubLGFRertECUWE7Sc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=p1tyYzkFurPMBJ5WfGDti97Xz1uPdqJvT14/QgesVhBtdPv/I6K5ERDiVIW5eHztK UGusDr084KFRmpkqC7oHJQnegzcbG8ZNj2ZRCHA1GqoUjJ+iOrsLvykIDPkLTnkIfU 9v7ylu/BlXKjqESOr20cJGuRoSGb1kYqq9GY/oOof5HGAydPj0QRkGdChoA2bfMutB dNA68QN2vwNDP+BlRwMOseEm4Vtci/QlcyGTCVWu7K1uLM3s6V1jm6/GP96Ff1Cdej k4mend9OVs0ggZkbfsqgzgETk6P+wybinScXonfPODBcLVX/xQQtnmJ6vt6zo9nxRe sCR6huekN9VSw== Received: from 82-132-213-7.dab.02.net ([82.132.213.7] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tvzjb-00G7Qc-3m; Sat, 22 Mar 2025 14:21:59 +0000 Date: Sat, 22 Mar 2025 14:21:55 +0000 Message-ID: <87bjttqh6k.wl-maz@kernel.org> From: Marc Zyngier To: Justin He Cc: Oliver Upton , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , Joey Gouly , Colton Lewis , Suzuki Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when KVM is not initialised In-Reply-To: References: <20250322035115.118048-1-justin.he@arm.com> <867c4hml8v.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 82.132.213.7 X-SA-Exim-Rcpt-To: Justin.He@arm.com, oliver.upton@linux.dev, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, Joey.Gouly@arm.com, coltonlewis@google.com, Suzuki.Poulose@arm.com, yuzenghui@huawei.com, Catalin.Marinas@arm.com, will@kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sat, 22 Mar 2025 13:54:17 +0000, Justin He wrote: >=20 > Hi Marc, >=20 > > -----Original Message----- > > From: Marc Zyngier > > Sent: Saturday, March 22, 2025 6:08 PM > > To: Justin He > > Cc: Oliver Upton ; linux-arm- > > kernel@lists.infradead.org; kvmarm@lists.linux.dev; Joey Gouly > > ; Suzuki Poulose ; > > Zenghui Yu ; Catalin Marinas > > ; Will Deacon ; linux- > > kernel@vger.kernel.org > > Subject: Re: [PATCH] KVM: arm64: pmu: Avoid initializing KVM PMU when > > KVM is not initialised > >=20 > > On Sat, 22 Mar 2025 03:51:15 +0000, > > Jia He 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 > >=20 > > Which unintended behaviour? Other than the pointless allocation of a ti= ny > > amount of memory? Does anything really go wrong? > >=20 > Sorry for the confusion --- I should explain more clearly. > I noticed the usage of host_data_ptr in Colton Lewis's RFC patch [1]. Aft= er > 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? >=20 > [1] https://patchwork.kernel.org/project/kvm/patch/20250213180317.3205285= -6-coltonlewis@google.com/ > > > available, e.g., kernel is landed in EL1. > >=20 > > s/landed in/booted from/ > >=20 > > > > > > Signed-off-by: Jia He > > > --- > > > 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) > >=20 > > Huh: > >=20 > > 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 > >=20 > > 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=E2=80=99ll need to respin it if you're interested in the fix =F0=9F=98= =8A 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. > >=20 > > Same comment here. > >=20 > > > + */ > > > + if (!is_kvm_arm_initialised()) > >=20 > > This is definitely the wrong thing to check for, as it relies on the pr= obe > > ordering between the PMU drivers and KVM. Relying on that is not > > acceptable. > >=20 > 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. --=20 Without deviation from the norm, progress is not possible.