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

Will Deacon <[email protected]>
Newsgroups dev.linux.lists.linux-coco,dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.kvm,org.kernel.vger.linux-kernel
Message-ID <an2YN7kxB7bjCd2s@willie-the-truck>
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/[email protected]/

but I can't tell whether that's still being actively pursued.

Will
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.