Re: [PATCH v5 3/7] KVM: arm64: Top up stage-2 memcache for dirty logging faults

On Fri, Jul 31, 2026 at 09:23:43AM +0100, Marc Zyngier wrote:
> > FEAT_BBML3 shifts responsibility onto the implementation to reconcile
> > multihit due to mapping granularity changes. A hypervisor could choose
> > to do eager page splitting at the beginning of dirty logging and elide
> > TLBIs.
> 
> Sure. We just don't advertise BBML3. and I'm not even sure we always
> can emulate it.

Well, we'd at minimum need supporting hardware since the feature must
also exist at stage-1.

> > 
> > > I think the latent bug here is the way we always walk L1's S2 on S2
> > > fault, irrespective of the fault type, and that feels wrong. This is
> > > ignoring the fact that we already have a TLB (the shadow S2) for this
> > > mapping, and rewalk anyway. Since we now find valid permissions, we
> > > take it at face value and try to install this new translation (which
> > > could point to a different OA, and even bigger problem).
> > > 
> > > So ideally we'd simply tell the guest to bugger off, but we need to
> > > solve a few problems first:
> > > 
> > > - some permission faults are caused by the host rather than the guest
> > >   (dirty logging, HAFDBS), and we need to treat those specially.
> > > 
> > > - we need to rebuild an ESR based on the content of our TLB, not L1's
> > >   S2, which is not always easy to obtain (we have some limited TTL
> > >   caching in the shadow S2, but that's not always reliable).
> > > 
> > > All of this strongly intersects with Wei-Lin's reverse map, and
> > > Oliver's HAFDBS support.
> > > 
> > > Oliver?
> > 
> > Hmm, I'm more of the mind that we should just keep the memcache topped
> > up for any fault because clearly the prediction has gotten out of sync
> > with what happens later down the line. We're bound to screw it up again.
> > 
> > Generating faults solely based on the TLB seems to be at odds with
> > supporting FEAT_ETS* in the shadow stage-2 and practically means we
> > need to re-walk for most stage-2 aborts anyway. And as you point out, I
> > need to do this for HAFDBS dirty state updates.
> > 
> > BBML3 and ETS2/3 aren't terribly high priority but I'd rather not paper
> > over a rather straightforward KVM bug by making design decisions that
> > limit our feature set for nested.
> 
> My problem here is not the top-up of the memcache, but the fact that
> the OA may have changed in L1's S2. This potentially result in an
> inconsistent S2, and in the future a wonky reverse map. So I'm not
> advocating we paper over anything. It's exactly the opposite.

AIUI the bug is that a change in mapping granularity (but not
necessarily OA) can cause a shadow stage-2 permission fault to remap at
a finer granularity and allocate table pages. This seems like something
we will eventually have to deal with for BBML3.

OTOH, I completely agree with you about changes to the OA. We should
synthesize a TLB conflict abort and let the L1 clean up the mess.

I was actually thinking about hardening the stage-2 map path, rejecting
valid->valid conversions that result in a change of the OA. We'll want
to have that anyway as Mostafa is adding support for BBML3, that error
could be propagated as a TLB conflict abort to the L1.

Thanks,
Oliver