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.
How much data would you expect to flow in practical usage? QMP isn't
designed for bulk transfer...
According to ifstat, the expected data rate in practical usage is around
KB/s in KB/s out
100 100
I fully understand your concern and agree that a JSON-based
protocol does not result in the lowest data rate.
If the data rate is the highest priority: *Before* the QMP supported was
implemented, the MCD interface was built on a custom RPC framework,
generated with the code generator at:
https://gitlab.com/lauterbach/mcdrefsrv/-/tree/main/codegen
The resulting header file was basically a set of functions capable of
serializing MCD's function arguments into a byte stream and vice-versa:
https://gitlab.com/lauterbach/mcdrefsrv/-/blob/df754cef7f19ece2d00b6ce4e307ba37e91e5dcb/include/mcd_rpc.h
The QMP support was added because of the advantages listed above and in
order to evade yet another custom communication protocol.
As a user of the MCD interface, I haven't noticed any negative impact of
the increased data rate in realistic debugging scenarios, even when
trying to drive the data rate up. If that would have been the case, I
would have sent this patch request with our custom RPC protocol.
qemu-system-<arch> [options] -qmp tcp::1235,server=on,wait=off
* Architecture-independent QTest test suite
V=1 QTEST_QEMU_BINARY="./qemu-system-<arch> [options]" tests/qtest/mcd-test
* Architecture-specific tests can be found at the client stub
[...]
qapi/mcd.json | 2366 ++++++++++++++++++++++
This is *massive*. By non-blank, non-comment lines, it's the second
largest module in qapi/, almost 9% of the entire schema. It's larger
than the entire QEMU guest agent QAPI schema. The QAPI generator
generates some 280KiB of C code for it.
I understand your point and I think it touches on the point made above
regarding MCD's complexity:
mcd/mcd_api.h | 3963 +++++++++++++++++++++++++++++++++++++
I hope that we agree that RPC is generally the right approach to
implement MCD. As far as the implementation is concerned, I'm open to
any suggestion you have. I've always avoided to introduce any
unnecessary external dependencies.
Best regards,
Mario
