Re: [PATCH v16 07/45] arm64: mm: Handle Granule Protection Faults (GPFs)
Will Deacon <[email protected]>
| Newsgroups | dev.linux.lists.kvmarm,dev.linux.lists.linux-coco,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