Re: [PATCH] KVM: selftests: Always run vCPU thread with blocked SIG_IPI
On Tue, Apr 20, 2021 at 06:24:50PM +0200, Paolo Bonzini wrote: > On 20/04/21 17:32, Peter Xu wrote: > > On Tue, Apr 20, 2021 at 10:37:39AM -0400, Peter Xu wrote: > > > On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote: > > > > The main thread could start to send SIG_IPI at any time, even before > > > > signal > > > > blocked on vcpu thread. Therefore, start the vcpu thread with the > > > > signal > > > > blocked. > > > > > > > > Without this patch, on very busy cores the dirty_log_test could fail > > > > directly > > > > on receiving a SIGUSR1 without a handler (when vcpu runs far slower > > > > than main). > > > > > > > > Reported-by: Peter Xu > > > > Cc: sta...@vger.kernel.org > > > > Signed-off-by: Paolo Bonzini > > > > > > Yes, indeed better! :) > > > > > > Reviewed-by: Peter Xu > > > > I just remembered one thing: this will avoid program quits, but still we'll > > get > > the signal missing. > > In what sense the signal will be missing? As long as the thread exists, the > signal will be accepted (but not delivered because it is blocked); it will > then be delivered on the first KVM_RUN. Ah right.. Thanks, -- Peter Xu
Re: [PATCH] KVM: selftests: Always run vCPU thread with blocked SIG_IPI
On 20/04/21 17:32, Peter Xu wrote: On Tue, Apr 20, 2021 at 10:37:39AM -0400, Peter Xu wrote: On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote: The main thread could start to send SIG_IPI at any time, even before signal blocked on vcpu thread. Therefore, start the vcpu thread with the signal blocked. Without this patch, on very busy cores the dirty_log_test could fail directly on receiving a SIGUSR1 without a handler (when vcpu runs far slower than main). Reported-by: Peter Xu Cc: sta...@vger.kernel.org Signed-off-by: Paolo Bonzini Yes, indeed better! :) Reviewed-by: Peter Xu I just remembered one thing: this will avoid program quits, but still we'll get the signal missing. In what sense the signal will be missing? As long as the thread exists, the signal will be accepted (but not delivered because it is blocked); it will then be delivered on the first KVM_RUN. Paolo From that pov I slightly prefer the old patch. However not a big deal so far as only dirty ring uses SIG_IPI, so there's always ring full which will just delay the kick. It's just we need to remember this when we extend IPI to non-dirty-ring tests as the kick is prone to be lost then. Thanks,
Re: [PATCH] KVM: selftests: Always run vCPU thread with blocked SIG_IPI
On Tue, Apr 20, 2021 at 10:37:39AM -0400, Peter Xu wrote: > On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote: > > The main thread could start to send SIG_IPI at any time, even before signal > > blocked on vcpu thread. Therefore, start the vcpu thread with the signal > > blocked. > > > > Without this patch, on very busy cores the dirty_log_test could fail > > directly > > on receiving a SIGUSR1 without a handler (when vcpu runs far slower than > > main). > > > > Reported-by: Peter Xu > > Cc: sta...@vger.kernel.org > > Signed-off-by: Paolo Bonzini > > Yes, indeed better! :) > > Reviewed-by: Peter Xu I just remembered one thing: this will avoid program quits, but still we'll get the signal missing. From that pov I slightly prefer the old patch. However not a big deal so far as only dirty ring uses SIG_IPI, so there's always ring full which will just delay the kick. It's just we need to remember this when we extend IPI to non-dirty-ring tests as the kick is prone to be lost then. Thanks, -- Peter Xu
Re: [PATCH] KVM: selftests: Always run vCPU thread with blocked SIG_IPI
On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote: > The main thread could start to send SIG_IPI at any time, even before signal > blocked on vcpu thread. Therefore, start the vcpu thread with the signal > blocked. > > Without this patch, on very busy cores the dirty_log_test could fail directly > on receiving a SIGUSR1 without a handler (when vcpu runs far slower than > main). > > Reported-by: Peter Xu > Cc: sta...@vger.kernel.org > Signed-off-by: Paolo Bonzini Yes, indeed better! :) Reviewed-by: Peter Xu -- Peter Xu
