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
