Re: [PATCH 22/22] HACK: KVM: arm64: nv: Set the dirty state for CMOs that fetch for write

[Oliver Upton <oupton@kernel.org>]

On Wed, Jul 01, 2026 at 11:16:20AM +0100, Wei-Lin Chang wrote:
> Hi Oliver,
> 
> On Tue, Jun 23, 2026 at 11:42:01AM -0700, Oliver Upton wrote:
> > From: Oliver Upton <oliver.upton@linux.dev>
> > 
> > Cache maintenance instructions that fetch for write do not set the dirty
> > state on descriptors, effectively passing the permission check and
> > leaving the descriptor in a writable-clean state. While this may make
> > some sense as the literal write has already occurred, there is no way to
> > correctly represent a "writable, but only for CMOs" permission in the
> > shadow stage-2 in such a way that the next genuine write generates a
> > permission fault.
> > 
> > A possible alternative would be to treat CMOs using writable-clean
> > translations as NOPs, relying on FWB to force everything coherent on the
> > CPU. This mostly works but will lead to breakage for VMs that have
> > assigned devices performing non-coherent DMA.
> > 
> > Another option would be to set HCR_EL2.TPCP and do full trap+emulate of
> > CMOs. And yes, dear reader, that would suck.
> > 
> > Just do the obvious thing instead and mark the descriptor as dirty for
> > CMOs. Maybe we can get an architectural relaxation if we're lucky...
> 
> This is interesting... So the problem is that when a CMO that require
> write permission is run by a nested guest, and the guest stage-2 is
> still in the writable-clean state (which means the shadow mapping must
> not have W) the instruction gets trapped and KVM gets in an awkard
> position.
> 
> If we keep the guest s2 writable-clean and shadow mapping RO -> guest
> can't make progress unless we emulate the instruction, but if we make
> the guest s2 writable-dirty and shadow mapping RW -> not architectural
> as of now. Treating it as a NOP also comes with problems as you said.
> 
> Am I understanding this correctly?

Yep, it's exactly as you've put it. We need both FWB and fully coherent
DMA to safely treat the CMO as a NOP and full CMO emulation is the line in
the sand for me :)

KVM could potentially detect the presence of noncoherent DMA (see x86's
kvm_arch_[un]register_dma()), but devices can be assigned long after
we've computed the vCPU feature set so no chance of limiting FEAT_HAFDBS
to situations where the stars align.

Thanks,
Oliver