Re: [PATCH 00/18] Stop all qemu-cpu threads on a breakpoint

[Richard Henderson <richard.henderson@linaro.org>]

On 10/5/24 13:35, Ilya Leoshkevich wrote:
>> How can we handle the long-running syscalls?
>> Just waiting sounds unsatisfying.
>> Sending a reserved host signal may alter the guest's behaviour if a
>> syscall like pause() is interrupted.
>> What do you think about SIGSTOP-ping the "in_syscall" threads?
>> A quick experiment shows that it should be completely invisible to
>> the
>> guest - the following program continues to run after SIGSTOP/SIGCONT:
>>
>> #include <sys/syscall.h>
>> #include <unistd.h>
>> int main(void) { syscall(__NR_pause); };
> 
> Hmm, no, that won't work: SIGSTOP would stop all threads.
> 
> So I wonder if reserving a host signal for interrupting "in_syscall"
> threads would be an acceptable tradeoff?

Could work, yes.  We already steal SIGRTMIN for guest abort (to distinguish from host 
abort), and remap guest __SIGRTMIN to host SIGRTMIN+1.  Grabbing SIGRTMIN+1 should work 
ok, modulo the existing problem of presenting the guest with an incomplete set of signals.

I've wondered from time to time about multiplexing signals in this space, but I think that 
runs afoul of having a consistent mapping for interprocess signaling.


r~