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. Paolo
