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

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

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~