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?
