Re: [PATCH v16 07/45] arm64: mm: Handle Granule Protection Faults (GPFs)

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:

quoted

On Thu, Aug 13, 2026 at 07:40:41PM +0530, Pavan Kondeti wrote:

quoted

On Thu, Aug 13, 2026 at 11:11:03AM +0100, Will Deacon wrote:

quoted

On Wed, Aug 12, 2026 at 02:51:29PM +0100, Catalin Marinas wrote:

quoted

On Wed, Aug 12, 2026 at 06:12:09PM +0530, Pavan Kondeti wrote:

quoted

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/ (local)

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/ (local)

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