On Sat, 2024-10-05 at 22:26 +0200, Ilya Leoshkevich wrote: > On Sat, 2024-10-05 at 12:51 -0700, Richard Henderson wrote: > > On 9/25/24 00:43, Ilya Leoshkevich wrote: > > > On Tue, 2024-09-24 at 13:46 +0200, Richard Henderson wrote: > > > > On 9/23/24 18:12, Ilya Leoshkevich wrote: > > > > > Hi, > > > > > > > > > > On reporting a breakpoint in a non-non-stop mode, GDB remotes > > > > > must > > > > > stop > > > > > all threads. Currently qemu-user doesn't do that, breaking > > > > > the > > > > > debugging session for at least two reasons: concurrent access > > > > > to > > > > > the > > > > > GDB socket, and an assertion within GDB [1]. > > > > > > > > > > This series fixes this by importing pause_all_vcpus() from > > > > > qemu- > > > > > system. > > > > > This in turn requires introducing BQL and a few stubs to > > > > > qemu- > > > > > user. > > > > > > > > I would have expected you to reuse (some portion of) > > > > start_exclusive, > > > > which is already > > > > part of qemu-user. Is there a reason you chose a solution > > > > which > > > > requires... > > > > > > > > > replay: Add replay_mutex_{lock,unlock}() stubs for qemu- > > > > > user > > > > > qemu-timer: Provide qemu_clock_enable() stub for qemu- > > > > > user > > > > > cpu: Use BQL in qemu-user > > > > > > > > all sorts of other infrastructure? > > > > > > > > > > > > r~ > > > > > > I don't think start_exclusive() would protect the gdb socket from > > > concurrent accesses (e.g., if two threads are simultaneously > > > stopped). > > > > Of course it would, otherwise "exclusive" has no meaning. > > All other cpus are blocked in exclusive_idle(). > > > > Importantly, no cpus are blocked in syscalls, where the kernel can > > modify memory behind > > gdbstub's back (e.g. read). I think considering "in_syscall" to be > > "paused" a mistake. > > > > > > r~ > > 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?