Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> writes: > Radim Krčmář <rkrcmar@xxxxxxxxxx> writes: > >> 2018-04-02 18:10+0200, Vitaly Kuznetsov: >>> + if (vcpu != current_vcpu) >>> + kvm_vcpu_kick(vcpu); >> >> The spec says that >> >> "This call guarantees that by the time control returns back to the >> caller, the observable effects of all flushes on the specified virtual >> processors have occurred." >> >> Other KVM code doesn't assume that kvm_vcpu_kick() and a delay provides >> that guarantee; kvm_make_all_cpus_request waits for the target CPU to >> exit before saying that TLB has been flushed. >> >> I am leaning towards the safer variant here as well. (Anyway, it's a >> good time to figure out if we really need it.) > > Ha, it depends on how we define "observable effects" :-) > > I think kvm_vcpu_kick() is enough as the corresponding vCPU can't > actually observe old mapping after being kicked (even if we didn't flush > yet we're not running). Or do you see any possible problem with such > definition? > Oh, now I see it myself -- native_smp_send_reschedule() only does apic->send_IPI() so this is indeed unsafe. We need something like kvm_make_all_cpus_request() with a mask (and, to make it fast, we'll probably have to pre-allocate these). Will do in v2, thanks! -- Vitaly