On Tue, Jan 09, 2024 at 05:20:45PM -0800, Sean Christopherson wrote: > Retry page faults without acquiring mmu_lock if the resolved gfn is covered > by an active invalidation. Contending for mmu_lock is especially > problematic on preemptible kernels as the mmu_notifier invalidation task > will yield mmu_lock (see rwlock_needbreak()), delay the in-progress Is it possible fault-in task avoids contending mmu_lock by using _trylock()? Like: while (!read_trylock(&vcpu->kvm->mmu_lock)) cpu_relax(); if (is_page_fault_stale(vcpu, fault)) goto out_unlock; r = kvm_tdp_mmu_map(vcpu, fault); out_unlock: read_unlock(&vcpu->kvm->mmu_lock) > invalidation, and ultimately increase the latency of resolving the page > fault. And in the worst case scenario, yielding will be accompanied by a > remote TLB flush, e.g. if the invalidation covers a large range of memory > and vCPUs are accessing addresses that were already zapped. This case covers all usage of mmu_invalidate_retry_gfn(), is it? Should we also consider vmx_set_apic_access_page_addr()? Thanks, Yilun
