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 7357F37F757; Wed, 21 Jan 2026 16:20:44 +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=1769012444; cv=none; b=G4Rt76zdL6kJczs5tQ+TSEmV65WUD8bY51qvZIqfQvHw/+b1YTWcqKTv6LVCXF8KfAEZcjUJ2Z1EDBJDKHHynOW3ZoZKMDIlpqMbNcBs9GGdPjzL1q8SV+J+m0C6x65ZOgXqglYZ7UlB0jsr6YtUcIBib1OkWt1QV8EiZXN4LhA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769012444; c=relaxed/simple; bh=1zrLB9YYiuSPiB+hTb+W3k1yLnlV8BF5PevPGnV9vcs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SZzqopF9Vk5EoULr1awQL68uyjOcF4w8VVdtGH2zRHLuf4UcDm+FSmV00AacglkYNq1wYwx7XkBIZ2+OKuxWfJ5eKXTLYlF86n5fF7V0hZ1ZzHkOxEAIpM+T9f1dKgA/NIYlinY0uz0edSY9YP7TNzbnyoErEaxD8StA7HHuJuE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QISwPij8; 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="QISwPij8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0DF4C4CEF1; Wed, 21 Jan 2026 16:20:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769012443; bh=1zrLB9YYiuSPiB+hTb+W3k1yLnlV8BF5PevPGnV9vcs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QISwPij8Wrto3Bs19w6vqe3S2S5wUbzZBIkAYoW3q5GKX1oPPXFRUPe1kitED+Afh P+qH1izc6yuCkE0EYlusxPbZ7hCHHqf21r/qBEdXvqXF7UAgd857zey6uVJ4Xgt/MW MHMDvGAh7sXRHkbMW23lVMUlAD63w1vI8ZhNW+nG3uarIrZdYR0P6xaGU2GzL7GNZg cXkfdI3oNMKE4jw8heAnjacEfhDglbXo4tELdNeXigasbn2JhCOYWFkj90bCGBAPGe 9slvHJrZgYXFftd3CHOiTy1JaF86l5T1y3z2zhubcNAzg1QVOy2RVW+DMnR6EoBJqZ MUA+ohMHg8Qrw== Date: Wed, 21 Jan 2026 16:20:36 +0000 From: Will Deacon To: Yeoreum Yun Cc: Mark Rutland , Marc Zyngier , catalin.marinas@arm.com, broonie@kernel.org, oliver.upton@linux.dev, miko.lenczewski@arm.com, kevin.brodsky@arm.com, ardb@kernel.org, suzuki.poulose@arm.com, lpieralisi@kernel.org, yangyicong@hisilicon.com, scott@os.amperecomputing.com, joey.gouly@arm.com, yuzenghui@huawei.com, pbonzini@redhat.com, shuah@kernel.org, arnd@arndb.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v11 RESEND 9/9] arm64: armv8_deprecated: apply FEAT_LSUI for swpX emulation. Message-ID: References: <86ms3knl6s.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Jan 21, 2026 at 02:51:10PM +0000, Yeoreum Yun wrote: > > On Tue, Jan 20, 2026 at 05:59:47PM +0000, Yeoreum Yun wrote: > > > On second thought, while a CPU that implements LSUI is unlikely to > > > support AArch32 compatibility, > > > I don't think LSUI requires the absence of AArch32. > > > These two are independent features (and in fact our FVP reports/supports both). > > > > Did you have to configure the FVP specially for this or that a "default" > > configuration? > > > > > Given that, I'm not sure a WARN is really necessary. > > > Would it be sufficient to just drop the patch for swpX instead? > > > > Given that the whole point of LSUI is to remove the PAN toggling, I think > > we should make an effort to make sure that we don't retain PAN toggling > > paths at runtime that could potentially be targetted by attackers. If we > > drop the SWP emulation patch and then see that we have AArch32 at runtime, > > we should forcefully disable the SWP emulation but, since we don't actually > > think we're going to see this in practice, the WARN seemed simpler. > > TBH, I missed the FVP configuration option clusterX.max_32bit_el, which > can disable AArch32 support by setting it to -1 (default: 3). > Given this, I think it’s reasonable to emit a WARN when LSUI is enabled and > drop the SWP emulation path under that condition. I'm asking about the default value. If Arm are going to provide models that default to having both LSUI and AArch32 EL0 supported, then the WARN is just going to annoy people. Please can you find out whether or not that's the case? Will