On 11/03/20 22:21, Maxime Villard wrote: >> 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
How do you ensure that a guest with interrupts off exits promptly? > , 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. You can also do what KVM did until a few years ago: swap the signal mask atomically when you enter the hypervisor (e.g. unmasking SIGUSR1---this has to be done in the kernel) and when you leave it. Then in QEMU you keep SIGUSR1 masked and "eat" it with sigwaitinfo. > For now this issue is unimportant and no Qemu change is required. If you say so. Paolo
