Re: [PATCH 00/16] Add Multi-Core Debug (MCD) API support

["Alex Bennée" <alex.bennee@linaro.org>]

Mario Fleischmann <mario.fleischmann@lauterbach.com> writes:

> On 08.04.2025 16:37, Markus Armbruster wrote:
>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>> 
>>> Markus Armbruster <armbru@redhat.com> writes:
>>>
>>>> Alex Bennée <alex.bennee@linaro.org> writes:
>>>>
>>>>> Markus Armbruster <armbru@redhat.com> writes:
>>>>>
>>>>>> Mario Fleischmann <mario.fleischmann@lauterbach.com> writes:
>>>>>>
>>>>>>> Apologies for the line wrapping in yesterday's answer. Should be fixed now.
>>>>>>>
>>>>>>> On 08.04.2025 09:00, Markus Armbruster wrote:
<snip>
>>>>
>>>> "Keep them separate" is only a gut feeling, though.  While I pay
>>>> attention to my gut feelings, I know they can be wrong.  I am soliciting
>>>> opinions.
>>>
>>> I forgot to add isn't the flexibility of the QMP API something we need
>>> to handle for single binary anyway?
>> 
>> I have no idea :)
>
> Alex, thanks for chiming in! By "single binary", I assume you mean user
> space emulation? In that case, could you elaborate whether and how it's
> a concern related to MCD? Maybe I'm missing something here.

Not directly, it was aimed at Markus. As we work towards a single binary
build we have to consider how the QMP API is going to be presented when
the binary could run a number of different targets. Markus and Philippe
have discussed it before but I forget the details.

> MCD is
> specifically designed for debugging multi-core SoCs and therefore
> currently only supported in system emulation.

Eventually we hope to get to the position QEMU can emulation a
heterogeneous SoC so having multiple architectures under one binary will
present potential issues for debugging. 

> For user-space debugging,
> I don't see any reason why not to use GDB's remote serial protocol.
>
>> Evolving a target-dependent interface into a target-independent
>> interface without breaking compatibility is always a bother.
>> 
>> It's likely more of a bother when the interface is binary.  Textual
>> interfaces tend to have less target-dependence.
>> 
>> Designing a target-independent interface is probably easier than
>> evolving it compatibly from a target-dependent one.
>
> Like the gdbstub, the MCD implementation does not have any
> target-specific dependencies. This is also a change compared to the last
> patch set and something I wanted to point out with
>
>> Architecture-independent MCD implementation
>
> But, again, maybe I'm missing something.
>
>> QMP is textual, and it's designed for certain kinds of compatible
>> evolution.  Using QAPI/QMP for a debugging interface may be a perfectly
>> sensible idea.  I don't know enough about debugging interfaces to judge.
>
> Even though MCD is a very stable API (developed in 2008, functions
> haven't changed since then), as you've already pointed out, it's bold to
> assume that it will never change in the future. For that reason, MCD
> provides the mcd_initialize_f function which can be used to communicate
> the requested and implemented API versions. As long as that function
> stays serializable over the RPC layer, evolution should be possible.
>
>> Use of QAPI/QMP does not imply use of the QMP monitor.  We can keep the
>> monitor and the debugging interface separate even though both are based
>> on QAPI/QMP.
>> 
>> The monitor code is gnarly, I'm afraid.  It supports multiple monitors,
>> but they are not fully independent for historical reasons, chiefly
>> implied mutual exclusion for commands.  Adding a QAPI/QMP-based
>> debugging interface without undue coupling to monitors may pose a few
>> technical problems.  One way to find out.
>
> If I understand you correctly, when QAPI-MCD runs on a separate socket
> without using a monitor, it's still coupled to the monitor code
> internally? Does this have an influence on the either the usage of a
> monitor or the MCD interface or is it rather an implementation detail?

An implementation detail - we should try and avoid needless coupling if
we can though.

AFAIK not all monitor commands map to QMP equivalents but I'm not sure
if that's true the other way around - can you do everything you can over
QMP under HMP? If you don't have to then that implies we can over a
separate schema on a debug socket that doesn't need monitor bits tied
in.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro