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

[Suzuki K Poulose]

On 11/08/2026 15:44, Catalin Marinas wrote:
> On Mon, Aug 03, 2026 at 02:43:23PM +0100, Steven Price wrote:
> > If the host attempts to access granules that have been delegated for use
> > in a realm these accesses will be caught and will trigger a Granule
> > Protection Fault (GPF).
> >
> > A fault during a page walk signals a bug in the kernel and is handled by
> > oopsing the kernel. A non-page walk fault could be caused by user space
> > having access to a page which has been delegated to the kernel and will
> > trigger a SIGBUS to allow debugging why user space is trying to access a
> > delegated page.
> >
> > Reviewed-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
> > Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>
> > Signed-off-by: Steven Price <steven.price@xxxxxxx>
> > ---
> > Changes since v10:
> >   * Don't call arm64_notify_die() in do_gpf() but simply return 1.
> > Changes since v2:
> >   * Include missing "Granule Protection Fault at level -1"
> > ---
> >   arch/arm64/mm/fault.c | 28 ++++++++++++++++++++++------
> >   1 file changed, 22 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index 85e23388f9bb..ea3ae0ca7dba 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -909,6 +909,22 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
> >   	return 0;
> >   }
> >   
> > +static int do_gpf_ptw(unsigned long far, unsigned long esr, struct pt_regs *regs)
> > +{
> > +	const struct fault_info *inf = esr_to_fault_info(esr);
> > +
> > +	die_kernel_fault(inf->name, far, esr, regs);
> > +	return 0;
> > +}
> > +
> > +static int do_gpf(unsigned long far, unsigned long esr, struct pt_regs *regs)
> > +{
> > +	if (!is_el1_instruction_abort(esr) && fixup_exception(regs, esr))
> > +		return 0;
> > +
> > +	return 1;
> > +}
>
> Is there a valid case for fixup_exception() here? IOW, do we ever have a
> valid user mapping of the pages delegated to a guest? If the above is
> considered a kernel bug, I'd not silently ignore this (like return less
> bytes copied or -EFAULT to user) but rather warn, potentially
> rate-limited.

Good question. This shouldn't be a valid case. We expect the VMM to use
guest_memfd and that should prevent any mmaps and thus fixups shouldn't
be required. That said, this series doesn't enforce that the VMM uses
GMEM backed memslots for Guest RAM. We should probably do that while
mapping things in.

With that, we could drop that fixup and scream a bit.

Cheers
Suzuki

> If there is a real use-case for this, what's preventing GUP + memcpy()
> from triggering a similar fault with no fixup available?