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

[Marc Zyngier <maz@kernel.org>]

On Thu, 25 Jun 2026 20:34:46 +0100,
Oliver Upton <oupton@kernel.org> wrote:
> 
> On Thu, Jun 25, 2026 at 04:43:34PM +0100, Marc Zyngier wrote:
> > 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.
> 
> While not _directly_ related, this does seem at odds with the
> implications of R_JCXVS.
> 
> I.e. when HD is set, the PTW can speculatively fetch the S2 translation for
> write before knowing if the S1 descriptor is actually subject to an
> update per R_HDTRB.

I agree that this is a bit odd, and has a taste of speculative writes
(always a good idea... not!).

> 
> It obviously all still fits together (permission checks are later down
> the line), just weird is all. Anyway...
> 
> > 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 still need to account for host-induced permission faults, e.g. dirty
> tracking or an RO memslot getting mapped into the L2. So I think we
> still need to evaluate R+W before forwarding to the L1.

Hmm. I had forgotten about this indeed. Ultimately, we need to keep
track of why a S2 entry is RO in the L1 IPA space. We can either use
more SW bits in the PTE (not that many left), or wait until Wei-Lin is
done with his reverse + direct map tracking structure.

> Looking ahead to HAFDBS, for this to work we will need to use a liberal
> interpretation of R_JCXVS at the time of the initial translation fault
> and always walk with intent for write.

Yeah, I'm not too precious about that, and we might as well take
advantage of the architecture.

> 
> Basically, there seems to be a subtle difference arising between writes
> as observed from the nested MMU and writes as observed at the virtual
> endpoint (memslot). Funny how something as straightforward as the access
> flag can be so headache inducing :)

Well, you knew NV was just a sorry hack, didn't you? ;-) It's just
another case of "SW will sort it out eventually...".

> 
> > - 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?
> 
> All aboard :) I've just been staring at dirty state crap for too long. I
> really like the unsupported atomic fault over our current behavior of
> injecting an SEA.
> 
> I'll fold all of this into v3.

Sounds good. Thank you!

	M.

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