Re: [PATCH v4 3/4] Introduce the NVMM impl

[Maxime Villard]

Le 11/03/2020 à 19:03, Paolo Bonzini a écrit :
> On 10/03/20 20:14, Maxime Villard wrote:
>> Maybe, whpx_vcpu_kick() causes a WHvRunVpExitReasonCanceled in the
>> WHvRunVirtualProcessor() call that follows, which in turn causes "ret=1"
>> to leave the loop. That is, maybe the next WHvRunVirtualProcessor() acks
>> the cancellation and leaves without doing anything, even if the
>> cancellation was received when this function wasn't executing. So there is
>> no bad effect, given that we still end up leaving the loop, which is the
>> desired functional behavior.
> 
> Yes, that's exactly the effect, and it solves the race in the same way
> as KVM's run->immediate_exit flag.
> 
>> Looking at NVMM now, it seems to me there is the same thing. We do a
>> self-kick but we're the calling thread and know the VCPU isn't executing.
>> As a result of the self-kick the IPI handler sets
>>      qcpu->stop = true;
>> And in the next iteration of the loop, we break because this bool is set
> 
> The problem is that qcpu->stop is checked _before_ entering the
> hypervisor and not after, so there is a small race window.

Ok. I don't understand what's supposed to be the race here. If we get an
IPI between the check and the call to nvmm_vcpu_run() then we'll just do
one run and stop in the next iteration, because the IPI will have set
qcpu->stop. Is this extra iteration undesired?