From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39A38606A329 for ; Fri, 23 Oct 2026 10:28:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=iJMwED3r; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=XdATUmEw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=5xxaFu/2iOxD5RMGVSNWFKVZ9uL4wsCtNZsvzOxk+fg=; b=iJMwED3rf8qjqNRo0vwwoyRG7r xzYo7wKFmORA6r0yh0f5JsHQxIy7Xyr0AAwhuJ//i6dUsYzm30LknDc2V8rY8GstBi3RtCfnY0sTv 4M2/2jnLeGwPdHsp78UbtsJ5zOpZ4dmNeCV1b+Fs47MFUNGKJ+QmUYQzIxzF+J+YKdCVEn11tZTfZ pAFtyXF89iB1LFq5NvujDE2cnBLWwweDWmfjjGRMciLlGUke60IpNqjfv2f5cC6m/+Hj+EwrjbMxh wRgj05qw4RNYkPZC4PjAAV3RfzcqvsfrNPe0PdHx+U8N45o2rk+PjCK7JgBduqE1Km1vnMK9jwFQZ GyxK2yhA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xKCVa-0000000G9xy-3fA6; Fri, 23 Oct 2026 10:28:22 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xKCVZ-0000000G9xi-3353 for linux-arm-kernel@lists.infradead.org; Fri, 23 Oct 2026 10:28:21 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id D565B602BA; Fri, 23 Oct 2026 10:28:20 +0000 (UTC) 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-Archived-By: 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 X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 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.