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

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

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:
>>> Mario Fleischmann <mario.fleischmann@lauterbach.com> writes:
>>> 
>>>> Thanks a lot for the response, I really appreciate your time.
>>>>
>>>> On 07.04.2025 14:33, Markus Armbruster wrote:
>>>>
>>>>> Mario Fleischmann <mario.fleischmann@lauterbach.com> writes:
>>>>>
>>>>>> This patch series introduces support for the Multi-Core Debug (MCD) API, a
>>>>>> commonly used debug interface by emulators. The MCD API, defined through a
>>>>>> header file, consists of 54 functions for implementing debug and trace.
>>>>>> However, since it is a header-file-only interface, MCD does not specify a
>>>>>> communication protocol. We get around this limitation by following a remote
>>>>>> procedure call approach using QMP. The client stub corresponding to this
>>>>>> implementation can be found at https://gitlab.com/lauterbach/mcdrefsrv
>>>>>>
>>>>>> This series is the successor to:
>>>>>> "[PATCH v5 00/18] first version of mcdstub"
>>>>>> (https://patchew.org/QEMU/20231220162555.19545-1-nicolas.eder@lauterbach.com/)
>>>>>>
>>>>>> * Architecture-independent MCD implementation
>>>>>> * QMP instead of custom TCP protocol
>>>>>
>>>>> Rationale?  There must be pros and cons.
>>>>
>>>> Assuming you're referring to the protocol of the previous patch series:
>>>> The previous TCP protocol only supported a subset of MCD. As the 
>>>> implementation progresses, the protocol eventually needs to be extended, 
>>>> possibly resulting in backwards compatibility problems.
>>>> Following an RPC approach and keeping the communication layer as close 
>>>> to the MCD API as possible results in a larger protocol at first, but 
>>>> does not need to be changed afterwards.
>>>> By directly mapping MCD functions onto QMP commands, the complexity in 
>>>> the server and client stubs can be minimized.
>>>>
>>>> Assuming you're referring to the QMP choice:
>>>> QMP is being described as the "protocol which allows applications to 
>>>> control a QEMU instance".
>>>> It provides a RPC framework which automatically (de)serializes methods 
>>>> and their parameters, even inside QTests.
>>>> The whole interface is automatically documented.
>>> 
>>> Let's see whether I understand.
>>> 
>>> MCD is an established C interface.
>>> 
>>> Your goal is to provide remote MCD for QEMU, i.e. the client uses the
>>> MCD C interface, and the interface's implementation talks to an MCD
>>> server integrated into QEMU via some remote transport.
>>> 
>>> The previous version connects the two with a bespoke protocol via TCP.
>>> The client software translates between the C interface and this
>>> protocol.  QEMU implements the protocol's server side.  Designing and
>>> maintaining a protocol is expensive.
>>> 
>>> This versions makes two changes:
>>> 
>>> 1. Instead of layering a protocol on top of MCD, you use MCD directly.
>>> This eliminates protocol design and maintenance.  Moreover, translation
>>> becomes straightforward marshaling / unmarshaling for the transport.
>>> 
>>> 2. You use QMP as a transport.  This gets you marshaling / unmarshaling
>>> for free.  It also provides some useful infrastructure for tests,
>>> documentation and such.
>>> 
>>> Fair?
>>
>> Couldn't have put it better myself.
>>
<snip>
>>> What about providing the MCD interface as a separate QMP-like protocol?
>>> It gets its own QAPI schema, just like for qemu-ga.  Simplifies
>>> compiling it out when not needed.
>>>
>>> It gets its own socket, just like the GDB stub.  Might reduce
>>> interference between debugging and QMP.
>>> 
>>> Thoughts?  Alex, Philippe, care to chime in?
>>
>> Sound reasonable to me. Keeping in mind the size of generated QAPI code,
>> an option to `./configure [...] --enable-mcd` is definitely advisable.
>
> Alex, Philippe?

When I spoke to Mario at DVCon last year I liked the idea of re-using
QMP instead of inventing yet another RPC interface for QEMU. QMP
certainly has nicer properties than the gdbstub which has a very
"organic" and "serial" feel to it.

Are you suggesting we re-use the machinery but use an entirely separate
socket with just the MCD namespace in it? I don't see that being a
problem as long as we can test it properly in the CI.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro