qemu-devel
[Top][All Lists]
Advanced

[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: Tue, 10 Mar 2020 11:15:40 +0100
User-agent: Mozilla/5.0 (X11; NetBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 10.03.2020 07:45, Maxime Villard wrote:
> Le 02/03/2020 à 20:35, Paolo Bonzini a écrit :
>>
>>
>> Il lun 2 mar 2020, 20:28 Maxime Villard <address@hidden 
>> <mailto:address@hidden>> ha scritto:
>>
>>
>>     >> +        nvmm_vcpu_pre_run(cpu);
>>     >> +
>>     >> +        if (atomic_read(&cpu->exit_request)) {
>>     >> +            qemu_cpu_kick_self();
>>     >> +        }
>>     >> +
>>     >
>>     > This is racy without something like KVM's immediate_exit mechanism.
>>     > This should be fixed in NVMM.
>>
>>     I don't immediately see how this is racy.
>>
>>
>> You can get an IPI signal immediately after reading cpu->exit_request.
>>
>>     It reproduces the existing
>>     logic found in whpx-all.c, and if there is a real problem it can be
>>     fixed in a future commit along with WHPX.
>>
>>
>> It's buggy there too and it has to be fixed in the hypervisor so it can't be 
>> done at the same time I'm both. KVM does it right by having a flag 
>> ("immediate_exit") that is set by the signal handler and checked by the 
>> hypervisor.
>>
>> An earlier version of KVM instead atomically unblocked the signal while 
>> executing the guest, and then ate it with a sigwaitinfo after exiting back 
>> to userspace.
>>
>> You don't have to fix it immediately, but adding a FIXME would be a good 
>> idea.
>>
>> Paolo
>
> Kamil, please add /* FIXME: possible race here */ before the atomic_read().
>
> Thanks
>

I will do it and submit a new patchset revision.



reply via email to

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