From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4BD58C5B572 for ; Fri, 14 Aug 2026 09:20:23 +0000 (UTC) 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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3GfUKH11AfQHejJ7o/IeV7XbwvaLVJlzCrEGN3jgUP0=; b=3Kh+81B6D8Cjve3M88C8Tavtbf CPCP1MQOQmyLAWZ2WkziC9fAcZHwYwGp6hqaU0Aj2Tv7DL80dInx83AkdyLqyZjo5mhLKcw5/YhCO pJU1/0hipsmh2eyuaUzE9I9/E2P+OEGRa1F4P+xNU/tR/GRzkMeqgtL9avd9Yq8O6j/TLNkv5FzMf u1NmLSXwqzcSOgbYYPIhodKM4r/YDf836qkF/Cf7m1wdC9fQPBXN9OsQp+wf75/s0txDlvnh86Hz7 w6CpO7vYSXW1ESABTYf3dEDkmZWoc7GpifYDnvM0mytsWOE52IUhv2eDwl/QJS0mxFug7GHG69Etf 0GzG9srw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wuo5E-00000002MDy-2Y2z; Fri, 14 Aug 2026 09:20:12 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wuo5D-00000002MDh-3Jcu for linux-arm-kernel@lists.infradead.org; Fri, 14 Aug 2026 09:20:11 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 1BEAA43482; Fri, 14 Aug 2026 09:20:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AD271F000E9; Fri, 14 Aug 2026 09:20:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786699211; bh=3GfUKH11AfQHejJ7o/IeV7XbwvaLVJlzCrEGN3jgUP0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=TvQTrO+SmL7RinwxMpbttiEvOpXt9zDTZxkvtlUxOZjcLL4NHrneI0broiwqNDQrr CaZU/68ULhUFz4/Bqgk1JM+ig4OtzIxV3PzNfK7YLbrbIfMNc1NipmQyawUCOuX2W/ twyLGbVHEACVjS4/9FgbH/AdQLNsVN/KzEPozqHBISqXYrIvOtA8KQ6U5BSQaBAJFv tjLmCt/3AEzW98AzwTfb1aRi2fSGd5HdDqEFO9hQpcMvYsbKovMmmhCEGmdSI20/8y fFCv4MYrJswLv8gpGIKfbOvu/SZmm357QvvWPoLXLYvwTWaSB1JxingLliz3KRf5K/ w41hkFHJ6PGiQ== Date: Fri, 14 Aug 2026 10:20:02 +0100 From: Will Deacon To: Pavan Kondeti Cc: Catalin Marinas , Suzuki K Poulose , Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev, Marc Zyngier , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve , WeiLin.Chang@arm.com, Lorenzo Pieralisi Subject: Re: [PATCH v16 07/45] arm64: mm: Handle Granule Protection Faults (GPFs) Message-ID: References: <20260803134403.80630-1-steven.price@arm.com> <20260803134403.80630-8-steven.price@arm.com> <7d4e5920-aa20-40cd-954e-037631bd0d6c@quicinc.com> <8db602b8-7fd3-4c11-8fbd-3b8251648eb8@quicinc.com> <5b557560-7664-4336-9e5f-86de8dcd6d90@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b557560-7664-4336-9e5f-86de8dcd6d90@quicinc.com> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 14, 2026 at 02:15:39PM +0530, Pavan Kondeti wrote: > On Thu, Aug 13, 2026 at 04:28:04PM +0100, Will Deacon wrote: > > On Thu, Aug 13, 2026 at 07:40:41PM +0530, Pavan Kondeti wrote: > > > On Thu, Aug 13, 2026 at 11:11:03AM +0100, Will Deacon wrote: > > > > On Wed, Aug 12, 2026 at 02:51:29PM +0100, Catalin Marinas wrote: > > > > > On Wed, Aug 12, 2026 at 06:12:09PM +0530, Pavan Kondeti wrote: > > > > > > There is a valid case for fixup_exception() to be needed here in GPF > > > > > > handling. > > > > > > > > > > > > -000 |load_unaligned_zeropad(inline) > > > > > > -000 |hash_name(inline) > > > > > > -000 |link_path_walk() > > > > > > -001 |path_lookupat() > > > > > > -002 |filename_lookup() > > > > > > -003 |vfs_statx() > > > > > > -004 |vfs_fstatat() > > > > > > > > > > > > We observed this in Android running Gunyah when the page is mapped in > > > > > > EL1 but unmapped at EL2. path_lookupat() can actually handle this > > > > > > via fixup_exeption() when a word load crosses the page boundary. > > > > > > However, Gunyah injects a Synchronous External Abort and we have > > > > > > a downstream patch [1] that adds fixup_exception() in do_sea(). pKVM > > > > > > injects [2] such faults back to EL1 and fixup_exception() is taken care. > > > > > > > > > > Ah, good point, completely forgot about load_unaligned_zeropad(). Since > > > > > we don't unmap the linear map for delegated pages, we'll need the > > > > > fixup_exception(). And I guess warning in this case is not desirable > > > > > either. We could limit it to EX_TYPE_KACCESS_ERR_ZERO and > > > > > EX_TYPE_LOAD_UNALIGNED_ZEROPAD, though not sure it's worth it. > > > > > > > > Alternatively, I think the series to unmap guest memory from the linear > > > > map would solve that for gmem: > > > > > > > > https://lore.kernel.org/all/20260410151746.61150-1-kalyazin@amazon.com/ > > > > > > > > > > Thanks Will for sharing this information. > > > > > > There are use cases outside gmem like FF-A lend to Secure Partition. > > > we may not be enforcing all such memory to be unmapped at EL1, correct? > > > > If you leave the cacheable linear alias of memory intact across an > > NS -> S transition, then you're in for a bad time [1]. > > > > Will > > > > [1] https://lore.kernel.org/all/20221114110329.68413-1-manivannan.sadhasivam@linaro.org/ > > Thanks for the reply. In the above case, XPU does not like the speculative fetches. I am > not sure if there is a hard requirement for unmap of FF_A memory lent to secure > partition managed under Root with GPT. If it's not unmapped, then you can get speculative reads on the NS side which will probably trigger aborts at the TZ memory firewall logic. I agree that's different for the GPT, but gmem is growing that support for other architectures and it would solve the load_unaligned_zeropad() problem on arm64. Some folks also seem to want it for addressing the possibility of CPU side-channels, but that's a bit more belt and braces imo. Vincent looped you in on the thread with Thierry where there is an ongoing effort to address this for TZ. Will