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 DD3A92E8DEA; Wed, 8 Oct 2025 10:46:58 +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=1759920419; cv=none; b=o/If7S9ghjvMnQpmftQpVtT6PhL7pIDxw+GDuVq4LQaZvm0XhfXCZ7GdpBEGXTKeGotdIkYioOmyN3ioTdUvpyRGxeB5yKJIZh+fvQGCt/VD4qnOutCjFTeWHpgg1rm9I5j+biivO5G1m+5fVNnOvGblyjdipBhLHhAdv26tNao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759920419; c=relaxed/simple; bh=0Zfd3JxG/MTE4sDHQ96evynt+Sey4zJnf0P/n9lbvOU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=gN1SxKb00/DzZhmfHKX08K2CNm+IKm1cxVZavPxmIsTPlQHFQlN/8XvI1qe2oArSj8Hz7y+1nIoO6EQc6lWDn8ZdAvHSEQHUJ8gXuHbzkZY19LuSqLvfwLUPsS0wopZ1we/9EpDraPxVS6mnUnOlhalWGl4635S/5CSUpahmH+A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XG8n+htW; 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="XG8n+htW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76FFCC4CEF4; Wed, 8 Oct 2025 10:46:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759920418; bh=0Zfd3JxG/MTE4sDHQ96evynt+Sey4zJnf0P/n9lbvOU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XG8n+htWjrOEkpSmgMN4IruinvuWQMwSD8FNAFO/gGncG9Rtz+UsPsWbvupvfUFal aF3pVD5rIjq8/qA0z4lH8qW/rfFxonQajk4nGiKcN1R5wYLACiqvqyJ6gUWnX6vRCg +csuqh4gLbPBpjtaEcUCYGfVrkP5ftsoIJfchdoOF8qJRBut5sDu7lT7fKduZBF2vD lC2+5rvGuSCGxHJlNsXUbRvNCA0WjThiPim3QDvmp1oXEQK09X6CV5VNN6rBfP9vE6 OvBP9tOdFxpi63q45YmLS2Z2SAJ3QVIyjRokKcWYDwiEDL0gwFLuGWwi5IwMDsyS5I +SLu5GeSAxfNg== 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.98.2) (envelope-from ) id 1v6RhA-0000000CKEh-0xjF; Wed, 08 Oct 2025 10:46:56 +0000 Date: Wed, 08 Oct 2025 11:46:55 +0100 Message-ID: <861pndzn4w.wl-maz@kernel.org> From: Marc Zyngier To: Mukesh Ojha , Oliver Upton Cc: joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Check cpu_has_spe() before initializing PMSCR_EL1 in VHE In-Reply-To: References: <20251007182356.2813920-1-mukesh.ojha@oss.qualcomm.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org 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: mukesh.ojha@oss.qualcomm.com, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, 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 Tue, 07 Oct 2025 19:31:45 +0100, Oliver Upton wrote: > > Hi Mukesh, > > I find it a bit odd to refer to cpu_has_spe() in the shortlog, which > doesn't exist prior to this patch. > > On Tue, Oct 07, 2025 at 11:53:56PM +0530, Mukesh Ojha wrote: > > commit efad60e46057 ("KVM: arm64: Initialize PMSCR_EL1 when in VHE") > > initializes PMSCR_EL1 to 0 which is making the boot up stuck when KVM > > runs in VHE mode and reverting the change is fixing the issue. > > > > [ 2.967447] RPC: Registered tcp NFSv4.1 backchannel transport module. > > [ 2.974061] PCI: CLS 0 bytes, default 64 > > [ 2.978171] Unpacking initramfs... > > [ 2.982889] kvm [1]: nv: 568 coarse grained trap handlers > > [ 2.988573] kvm [1]: IPA Size Limit: 40 bits > > > > Lets guard the change with cpu_has_spe() check so that it only affects > > the cpu which has SPE feature supported. > > This could benefit from being spelled out a bit more. In both cases we > check for the presence of FEAT_SPE, however I believe the issue you > observe is EL3 hasn't delegated ownership of the Profiling Buffer to > Non-secure nor does it reinject an UNDEF in response to the sysreg trap. > > I agree that the change is correct but the rationale needs to be clear. To me, this smells a lot more like some sort of papering over a firmware bug. Why isn't SPE available the first place? M. -- Without deviation from the norm, progress is not possible.