On 08.04.2025 16:37, Markus Armbruster wrote: > Alex Bennée <alex.ben...@linaro.org> writes: > >> Markus Armbruster <arm...@redhat.com> writes: >> >>> Alex Bennée <alex.ben...@linaro.org> writes: >>> >>>> 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: >>> >>> [...] >>> >>>>>>> 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. >>> >>> Yes. >>> >>> "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. MCD is specifically designed for debugging multi-core SoCs and therefore currently only supported in system emulation. 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?
