Markus Armbruster <arm...@redhat.com> writes: > Mario Fleischmann <mario.fleischm...@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.fleischm...@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.fleischm...@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.e...@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
