>> + 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