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?