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 <m...@m00nbsd.net >> <mailto:m...@m00nbsd.net>> 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.
