[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: Kamil Rytarowski
Subject: Re: [PATCH v4 3/4] Introduce the NVMM impl
Date: Wed, 11 Mar 2020 22:22:20 +0100
User-agent: Mozilla/5.0 (X11; NetBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 11.03.2020 22:21, Maxime Villard wrote:
> Le 11/03/2020 à 21:42, Paolo Bonzini a écrit :
>> On 11/03/20 21:14, Maxime Villard wrote:
>>>> 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?
>> Yes, you don't know how long that run would take.  I don't know about
>> NVMM but for KVM it may even never leave if the guest is in HLT state.
> Ok, I see, thanks.
> In NVMM the runs are short, the syscalls are fast, and pending signals
> cause returns to userland. Therefore, in practice, it's not a big problem,
> because (1) the window is small and (2) if we have a miss it's not going
> to take long to come back to Qemu.
> I see a quick kernel change I can make to reduce 95% of the window
> already in the current state. The remaining 5% will need a new
> nvmm_vcpu_kick() function.
> For now this issue is unimportant and no Qemu change is required.
> Kamil, please also drop the XXX in
>     /* XXX Needed, otherwise infinite loop. */
> It's not a bug.

OK. I will do it.

> Thanks,
> Maxime

reply via email to

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