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

[Pavan Kondeti]

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.

Thanks,
Pavan