Re: [PATCH 3/5] KVM: x86: hyperv: simplistic HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST,SPACE} implementation

[Vitaly Kuznetsov]

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