On 11.03.2020 22:21, Maxime Villard wrote: > Le 11/03/2020 à 21:42, Paolo Bonzini a écrit : >> On 11/03/20 21:14, Maxime Villard wrote: >>>> The problem is that qcpu->stop is checked _before_ entering the >>>> hypervisor and not after, so there is a small race window. >>> Ok. I don't understand what's supposed to be the race here. If we get an >>> IPI between the check and the call to nvmm_vcpu_run() then we'll just do >>> one run and stop in the next iteration, because the IPI will have set >>> qcpu->stop. Is this extra iteration undesired? >> >> 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, 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. > > For now this issue is unimportant and no Qemu change is required. > > Kamil, please also drop the XXX in > /* XXX Needed, otherwise infinite loop. */ > It's not a bug. >
OK. I will do it. > Thanks, > Maxime >
