From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792751301; b=sOj3ZBpKH0uGg/hWdJf9iswz+FtrSalyEH5FjpjcGtoN2eHYHQXit1s6CfaQF0b5Z5Ae D3U6eHMREbujupHipXkCSy1GifujOTfsnDcZSivCcsEdvnq3XChgiMoAOGcl10DBEZZ51 6zavMubDXAT/8DzF3j6XbY84/KHuLve1s0nbcHg3kNhO2H6ESJIN3kILVeEndf+AzQXSm L8YuNnfHvluL7dfuI01Ar9CRJ0+q1hLT49TXbpTfBbSW6xoul88ADlvUveqMjWa9INJYb MdIpOWje+F4g0tpSO0mUc3/2JJ6u25tE5hAPT73tK7Qv7wZAwHl5Urux2sfyBGsnjJA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792751301; h=Received:DKIM-Signature:Received:Date:Message-ID:From:To:Cc:Subject: In-Reply-To:References:User-Agent:MIME-Version:Content-Type: X-SA-Exim-Connect-IP:X-SA-Exim-Rcpt-To:X-SA-Exim-Mail-From: X-SA-Exim-Scanned; bh=5xxaFu/2iOxD5RMGVSNWFKVZ9uL4wsCtNZsvzOxk+fg=; b=1IQbpXDDa9dbVRB2ILgGkF2BRwhYdT7fR7rlYKSsEgZUOgFKOREU7mIbqp9A1dr9OqR4 khkUYwVfMAvRZc2hgX5HdAP57+mGMhDkOgVx74iLlBhTP2sE6iOxYeN0osWGsbCP3rTHK qGgdvqHQZbYj7JLZG1KnmkZFih/T4DRThmyLgzzT2/V330oeCXDokeYvvmD/z5cTIkyAL Sipiv0VQstKcXtAgjAUELGrHSgeKU/cOTaRc5awbPAcAGgB9AAunjBcvkFgib/OCt1Ptc /C7hXKwpnvxXlYnUyLUWG53c7f6RPrNvnjitQXuaZiElSYP8DYhd7VkCGWsgN8Kn2Eg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=XdATUmEw; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA938606A31A; Fri, 23 Oct 2026 10:28:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=XdATUmEw Received: by smtp.kernel.org (Postfix) with ESMTPSA id 834721F01825; Fri, 23 Oct 2026 10:28:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792751300; bh=5xxaFu/2iOxD5RMGVSNWFKVZ9uL4wsCtNZsvzOxk+fg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=XdATUmEwCqIkK3yOA/rtUt6Wt9lkphNipYOQtTDn4nJmriTAh/r9DtJZI9Wavn9+L egQyYa0IhRRo6LX+B1ALfojMV/jmQxpLDrD0QDXNeygBk3n4gVEy8Cgg2nheuvrT+v JaITFeF9B0C2dSPZawVWxAQVEGTqn66tCQGaqYmYTKJz5LzWylhbtez8+5pM7GjiQb h7vzg+8xoSV6IsRgaIMIUVwiJlXpGtcrLzUu51jID/+Srb8ikp8hWUQ4eLDc08ONhf iG14+4BYnjom3pS6iq4VdaN9yvyq544isEBYbtIgO5n+CEKX1VEqiwM036oN0z9oyR hv6jhhIhrdVbg== 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 1xKCVW-00000006QAz-0RQd; Fri, 23 Oct 2026 10:28:18 +0000 Date: Fri, 23 Oct 2026 11:28:17 +0100 Message-ID: <86ecdgzp6m.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Joey Gouly , Suzuki K Poulose , Zenghui Yu , Steffen Eiden , Catalin Marinas , Will Deacon , Mark Rutland , Yicong Yang , Zhou Wang , Arnd Bergmann , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] KVM: arm64: Hide FEAT_LS64_ACCDATA from guests In-Reply-To: References: <20261023070110.1833446-1-fuad.tabba@linux.dev> <20261023070110.1833446-2-fuad.tabba@linux.dev> <86fqxwzul7.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list 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: fuad.tabba@linux.dev, oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, seiden@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, yangyicong@hisilicon.com, wangzhou1@hisilicon.com, arnd@arndb.de, kvm@vger.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 Fri, 23 Oct 2026 10:08:11 +0100, Fuad Tabba wrote: > > Hi Marc, > > On Fri, 23 Oct 2026 09:31:32 +0100, Marc Zyngier wrote: > [...] > > Why settle for the least capable option? Context switching ACCDATA_EL1 > > is easy enough, can be gated on guest features, and avoid the > > userspace horror story. > > > > I'd rather see that. > > Context switching it means accessing ACCDATA_EL1 at EL2, which traps > to EL3 unless SCR_EL3.ADEn is set. booting.rst doesn't require ADEn > today, and TF-A only sets it when built with ENABLE_FEAT_LS64_ACCDATA, > which defaults to off. I couldn't care less. booting.rst is not authoritative and has absolutely no value when it comes to trap bits. Firmware could perfectly enable a feature on trap instead of catching fire. Additionally, shipping firmware that doesn't support features that the CPU advertises is a bug, and I want to see these systems burn. > On such a host, KVM traps to EL3 the first time > it switches ACCDATA_EL1 for a VM, and every VM has LS64_ACCDATA by > default. The cap leaves the register alone, and the fine-grained trap > takes priority over ADEn, so it works whatever ADEn is set to. > > Should we keep the cap as the fix for stable, and post ACCDATA support > on top? If you agree, I'd rebase your patches 3, 4 and 8 from [1], add > a booting.rst requirement for ADEn and EnAS0, and lift the cap and the > compat. No, I want this fixed by enabling ACCDATA support by default, which is what we have *already* promised to userspace, and see the fireworks. You can add an arm64.nols64 kernel option if you want, which is consistent with what we do for CNTPOFF, NV3, and other extensions that depend on FW enabling them. Thanks, M. -- Without deviation from the norm, progress is not possible.