Re: [PATCH v2 1/2] KVM: arm64: Only consider S1PTW a write fault if HA is set

[Marc Zyngier <maz@kernel.org>]

On Wed, 24 Jun 2026 22:00:43 +0100,
Oliver Upton <oupton@kernel.org> wrote:
> 
> On Wed, Jun 24, 2026 at 08:40:24PM +0000, sashiko-bot@kernel.org wrote:
> > > +	/*
> > > +	 * The architecture sucks; assume that the S1PTW fetched for write if
> > > +	 * HA is enabled at stage-1. Note that hardware updates to dirty state
> > > +	 * and table AF are predicated on HA=1 (DDI0487 M.a D24.2.194; R_SNVTX).
> > > +	 */
> > > +	if (kvm_vcpu_abt_iss1tw(vcpu))
> > > +		return effective_tcr_ha(vcpu);
> > 
> > [Severity: High]
> > Does unconditionally treating S1PTW faults as writes when HA is enabled break
> > guests that use pre-populated page tables in read-only memslots?
> > 
> > If a guest populates its page tables with the Access Flag already set, places
> > them in an RO memslot, and enables HA in its TCR, the hardware only needs read
> > access during a walk.

Correct, this is a consequence of R_HDTRB.

> > However, if a translation fault occurs,
> > kvm_is_write_fault() will unconditionally evaluate to true because of
> > effective_tcr_ha().
> > 
> > This will cause kvm_handle_guest_abort() to see a write fault on an RO memslot
> > and inject a spurious Synchronous External Abort (SEA) into the guest, even
> > though the hardware only needed to read the page table. Could we retain the
> > conditional check for permission faults to avoid this?
> 
> Gah, I tested with QEMU+EDK2 for this exact purpose but did so on an
> implementation without HAFDBS.

I've been chewing on that one for a bit, and came up with the
following argument:

- We're missing one of Read or Write because of L1's doing, and L1
  needs to do *something* about it. We don't need to find out about HA
  in the guest, we just need to forward the fault (and it is probably
  enough to check that we're in a nested context).

- We have checked that HA==1, derived from that that we need R+W, and
  we're missing the Write permission because the page is marked RO
  (assuming that KVM still maps with Read permission by default):

  - either it is "opportunistically" RO (dirty tracking, page never
    written to), and we flip it to RW, rince, repeat.

  - or it is hard-wired to RO at the memslot level, and the only
    possibility is that the PTW is trying to perform an atomic access
    (as per R_HDTRB), which we should be able to reject with an
    "Unsupported atomic hardware update fault".

Thoughts?

	M.

-- 
Without deviation from the norm, progress is not possible.