[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Maxime Villard
Subject: Re: [PATCH v4 3/4] Introduce the NVMM impl
Date: Wed, 11 Mar 2020 21:14:39 +0100

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]