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 2042B1DF24A; Sat, 22 Mar 2025 10:07:47 +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=1742638068; cv=none; b=HT8kRIKIHwgzSTXmcyfecK7nyPehz5G5asjKg0o00CIkiuogZsEyHzzVjv6Y3LH4M6xsET6+tV8SSAlKgFFtRnUA2TdXwpOfgwBKY4h1IgAXLz8KZpj00c+AsRisgZQUrgHnihRHAycpTD5pTxsBcnMOblZmHM28EzXc7puNezc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742638068; c=relaxed/simple; bh=RemAJ98qk9adr7lvTcdySe4M7YgnmGqhjiD4BGm3wo4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=CEPc6+u7rAftMMa+x4eds907zC4dLGFd6ewQ25gluQeSzflGgQud7kVaNZVPkcbMAkFW+4G+taD/F/gnPP4/rIr+jI+KGd6/HtGzuXpzgnNHIUMLKvE4wkzfXW5QfZmqKs1lD7TuStCctVlgM5fDf0mOwdLYpAZKrZSPMXfWGUY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rGTUlR0D; 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="rGTUlR0D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D066C4CEDD; Sat, 22 Mar 2025 10:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742638067; bh=RemAJ98qk9adr7lvTcdySe4M7YgnmGqhjiD4BGm3wo4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rGTUlR0DBGANLOmnA6NHW1Y1bgLDLKJEDHWCWqS0/IK0LoF0WSVsUkF2xWvfimEK7 XGkbiNYl8WnVMwGiSnRLHqAMbD+4s24jHHNw7LPJLrMLCk6TLXlotlictHZguvZgMY dS2EEdPwPvQF94BWsWBROmxrC+vYXV+vkaDZmpEIW86DOHx1yrT5BZ9MY4qG0oF7LS v5skvrPutBlSauAPQjUNRwPHhylvsRPMYZfqGkNxuju3vy6XWKt3/xPw5lE2Vz1cf5 JjWeIQNnFa/TsqJef9xPV598dvM0EGzYSDl0doU3yyc6EUFFYn1Df6aBExe/WqxSTM QH+pXJPcUQ83A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1tvvlZ-00G4QT-7M; Sat, 22 Mar 2025 10:07:45 +0000 Date: Sat, 22 Mar 2025 10:07:44 +0000 Message-ID: <867c4hml8v.wl-maz@kernel.org> From: Marc Zyngier To: Jia He Cc: Oliver Upton , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, Joey Gouly , Suzuki K 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: <20250322035115.118048-1-justin.he@arm.com> References: <20250322035115.118048-1-justin.he@arm.com> 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 (aarch64-unknown-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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 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, 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 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 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 > --- > 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.