On 09.04.2025 13:37, Markus Armbruster wrote: > Alex Bennée <alex.ben...@linaro.org> writes: > >> Mario Fleischmann <mario.fleischm...@lauterbach.com> writes: >> >>> On 08.04.2025 16:37, Markus Armbruster wrote: > > [...] > >>>> 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. > > Ideally, HMP commands are human-friendly wrappers around QMP commands. > Such commands can't do anything that could be done with QMP. > > Not all the functionality of QMP needs to be exposed in HMP. Some > functionality might only exist in QMP. How much to expose is a > pragmatic "is it worth the bother?" decision. > > Certain HMP commands make no sense in QMP. Examples: > > * HMP cpu sets the default CPU. The concept doesn't exist in QMP. > > * Ad hoc debugging commands that are used only by humans, such as > sync-profile. > > * The desk calculator[*] > > My abstract mental model of MCD has it completely separate from monitors > (HMP and QMP). Just like gdbstub. > > We're considering to use QAPI/QMP as interface definition and transport > infrastructure. > > Mario's patches do that in a simple way: by "embedding" MCD in the QMP > monitor. This creates a coupling that doesn't exist in my abstract > mental model. > > We could have a separate QAPI schema for interface definition, and a > separate socket for transport. This avoids coupling. > > Obviously, we'd still want to reuse existing QMP infrastructure as much > as practical. Some of that that code is gnarly. If we're not careful, > we get some subtle coupling deep under the hood. > > Here's one possible complication. While we can have any number of QMP > monitors, we still funnel most[**] commands to the main loop thread, > where they run one after the other. If we reuse all that machinery for > MCD, we end up forcing MCD commands through the same funnel to the main > loop thread. This coupling could be undesirable.
I think now we understand each other. Let me try to rephrase: We're trying to add a QEMU "debug" monitor which is used to debug the emulated system. The debug monitor is built on the MCD API as the debug protocol and QMP as the transport protocol and runs in parallel to the QEMU monitor which is used to control the emulator. Since the QEMU monitor is also built on QMP, we can reuse as much as possible from its QMP code but have to be careful not to add any coupling that goes beyond the transport layer. If I understood you correctly, I would feel prepared to go to work and try it out. If problems come up, I would get back to you. > Before we contemplate how to press the existing QMP infrastructure into > service for MCD, we should first figure out how we'd want MCD to operate > if we started on a green field. Can we have more than one MCD > connection? There are two types of connections in MCD. mcd_open_server_f opens the connection to the MCD implementation, i.e. mcdserver, and initializes mcdserver's core database. The actual debugging is performed over core connections opened by mcd_open_core_f. Each core connection will be identified by a pointer to a mcd_core_st object in the MCD API and by an uint32_t holding a unique identifier over the RPC protocol. In homogeneous multi-core systems, we can get away with one server connection and multiple core connections. In heterogeneous systems, we need multiple server connections since most likely multiple debuggers have to be connected to QEMU simultaneously. While there are use-cases to opening multiple connections to the same core at once, I would propose to keep this is as a future option but not to include this in the initial commits since it considerably complicates things. > Which thread should execute MCD commands? Since both gdbserver and QMP monitor run in the main thread, I don't see a reason why not to run the mcdserver in there as well. > Any locking requirements? As there are no explicit locks in gdbstub.c, I assume they are enforced by QEMU's infrastructure. > Any need for asynchronous commands? No, none that I'm aware of. > [*] Which arguably makes no sense in HMP either. > > [**] Not out-of-band commands. You probably don't want to know more.
