[PATCH] KVM: arm64: Don't livelock when AT can't resolve a fault IPA
Will Deacon
will at kernel.org
Mon Nov 2 11:27:41 PST 2026
On Mon, Nov 02, 2026 at 03:57:51PM +0000, Fuad Tabba wrote:
> On Mon, 02 Nov 2026 14:17:10 +0000, Will Deacon <will at kernel.org> wrote:
> > On Mon, Nov 02, 2026 at 02:09:25PM +0000, Marc Zyngier wrote:
> > > On Mon, 02 Nov 2026 13:59:12 +0000,
> > > Will Deacon <will at kernel.org> wrote:
> [...]
> > > > > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> [...]
> > > > > static inline bool kvm_hyp_handle_memory_fault(struct kvm_vcpu *vcpu,
> > > > > u64 *exit_code)
> > > > > {
> > > > > - if (!__populate_fault_info(vcpu))
> > > > > + if (!__populate_fault_info(vcpu)) {
> > > >
> > > > Presumably we need a barrier (DSB?) here, to ensure that the TLBI happens
> > > > after the AT instruction?
>
> I don't think the TLBI requires a barrier before it, because it
> doesn't matter if the AT's walk allocates entries after the TLBI.
> Anything it allocates matches memory, and the stage-2 descriptor the
> AT faulted on has AF clear, so that descriptor can't be cached:
I'm not sure that's relevant. The S1PTW case described by Ard in the
first part of his cover letter could look like this:
1. vCPU takes an S2 permission fault on VA 0x1000
-> The permission faulting entry is in the TLB
2. Another vCPU unmaps a S1 page-table page used to translate 0x1000 from S2
3. EL2 does an AT S1E1R on 0x1000 as part of handling (1)
-> Due to the uarch, this always walks the page-tables
4. The S1PTW from (3) faults at S2 because of (2)
-> The AT fails
If we invalidate the TLB after step (4), then we will see the S1PTW
fault upon retrying the access that originally caused a permission fault
in (1). Without barriers, however, this invalidation could float up
between steps (1) and (2) and wouldn't be effective.
Now, having written it out, I think we would eventually resolve that by
replaying the faulting instruction a second time, but it feels odd to me
that we wouldn't just prevent this race once we know that the AT has
failed.
Will
More information about the linux-arm-kernel
mailing list