Mario Fleischmann <mario.fleischm...@lauterbach.com> writes: > 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: <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
