Re: [PATCH v2 18/28] KVM: arm64: nv: Emulate CMOs via writable-clean translations as NOPs

[Oliver Upton <oupton@kernel.org>]

On Wed, Nov 04, 2026 at 03:03:46PM +0000, Leonardo Bras wrote:
> > +		/*
> > +		 * Plug your nose for a moment.
> > +		 *
> > +		 * Writable-clean translations are shadowed using a read-only
> > +		 * mapping so KVM can set the dirty state on the L1 descriptor
> > +		 * before installing a writable mapping.
> > +		 *
> > +		 * Certain cache maintenance instructions require a write
> > +		 * permission check but leave the translation in a writable-clean
> > +		 * state, meaning KVM is on the hook to emulate CMOs that use a
> > +		 * writable-clean translation.
> > +		 *
> > +		 * "Emulate" the CMO as a NOP, as KVM only exposes FEAT_HAFDBS
> > +		 * when FEAT_S2FWB is present and the I-cache is coherent.
> > +		 */
> > +		if (kvm_vcpu_dabt_is_cm(vcpu) && trans->writable && !trans->dirty) {
> > +			kvm_incr_pc(vcpu);
> > +			return -EAGAIN;
> > +		}
> > +
> >  		forward_fault = ((write_fault && !trans->writable) ||
> >  				 (!write_fault && !trans->readable));
> >  	}
> 
> Maybe it's just to messy or plain wrong, but could we make the descriptor 
> WC, then run the said DC instruction, then make it RO again?
> 
> I mean, maybe I got it wrong, but if we can't enable HAFDBS for the 
> nested guest, as updating a shadow PTE from WC->WD would require us to 
> take a fault to update the PTE inside the guest hypervisor, we could have 
> the PTE as WC without risking it to be promoted to WD by hardware.
> 
> I am probably missing something.

The writable-clean state is nonexistent when VTCR_EL2.HD=0 in the direct
permission model. So we have no way to construct a translation in the
stage-2 that satisfies our requirements.

The other way to do this would likely involve halting all vCPUs in the
VM and attempting to single-step which has a near 100% chance of blowing
up in our face.

Thanks,
Oliver