Peter Zijlstra <pet...@infradead.org> writes: > On Fri, Jul 20, 2018 at 10:02:10AM +0200, Vitaly Kuznetsov wrote: >> Andy Lutomirski <l...@amacapital.net> writes: >> >> > [I added PeterZ and Vitaly -- can you see any way in which this would >> > break something obscure? I don't.] >> >> Thanks for CCing me, >> >> I don't see how this can break things either. At first glance, however, >> I'm afraid we can add performance penalty to virtualized guests which >> don't use native_flush_tlb_others() (Hyper-V, KVM): we will be reloading >> CR3 without a need as we don't look at lazy mode in PV tlb flush >> functions. >> >> We can either check to switch_mm_irqs_off() that >> native_flush_tlb_others() is in use or teach PV tlb flush functions to >> look at lazy mode too. > > As Rik noted elsewhere in the thread, kvm_flush_tlb_others() ends up > calling native_tlb_flush_others() for all running vcpu threads.
Ah, right! > > The Hyper-V thing is magical, we can't really do anything about it > there. Let them worry about it. Well, we kinda know how this magic works: we just ask the hypervisor to flush TLB for us (if the particular vCPU is running) :-) Anyway, nothing stops us from duplicating the logic regarding lazy mode from native_flush_tlb_others() to hyperv_flush_tlb_others(): if TLB state is lazy omit TLB flush. -- Vitaly
