Re: [PATCH 0/5] trace: inroduce qmp: trace namespace

12.10.2021 14:49, Markus Armbruster wrote: > Vladimir Sementsov-Ogievskiy <vsementsov(a)virtuozzo.com&gt; writes: > > > Hi all! > > > > We have handle_qmp_command and qmp_command_repond trace points to trace > > qmp commands. They are very useful to debug problems involving > > management tools like libvirt. > > > > But tracing all qmp commands is too much. > > > > Here I suggest a kind of tracing namespace. Formally this series adds a > > trace points called qmp:<some-command> for every command, which may be > > enabled in separate like > > > > --trace qmp:drive-backup > > > > or by pattern like > > > > --trace qmp:block-job-* > > > > or similarly with help of qmp command trace-event-set-state. > > > > This also allows to enable tracing of some qmp commands permanently > > (by downstream patch or in libvirt xml). For example, I'm going to > > enable tracing of block job comamnds and blockdev-* commands in > > Virtuozzo. Qemu logs are often too empty (for example, in comparison > > with Libvirt), logging block jobs is not too much but will be very > > helpful. > > What exactly is traced? Peeking at PATCH 5... looks like it's input > that makes it to qmp_dispatch() and command responses, but not events. > > Fine print on "input that makes it to qmp_dispatch()": > > * You trace right before we execute the command, not when we receive, > parse and enqueue input. > > * Corollary: input with certain errors is not traced. > > * You don't trace the input text, you trace the unparsed parse tree. > > All fine, I presume. > > Existing tracepoints in monitor/qmp.c, and what information they send > (inessential bits omitted for clarity): > > * handle_qmp_command > > Handling a QMP command: unparsed parse tree > > Fine print, safe to ignore: > > - Out-of-band commands will be executed right away, in-band commands > will be queued. Tracepoints monitor_qmp_in_band_enqueue and > monitor_qmp_in_band_dequeue provide insight into that. > > - This also receives and queues parse errors, without tracing them. > Tracepoint monitor_qmp_err_in_band traces them as they are dequeued. > > * monitor_qmp_cmd_in_band > > About to execute in-band command: command ID, if any > > * monitor_qmp_cmd_out_of_band > > About to execute out-of-band command: command ID, if any > > * monitor_qmp_respond > > About to send command response or event: QObject > > For input, --trace qmp:* is like --trace handle_qmp_command, except it > traces late rather than early. > > For output, --trace qmp:* is like --trace monitor_qmp_respond less > events. > > The main improvement over existing tracepoints seems to be the ability > to filter on command names. > > To get that, you overload the @name argument of QMP command > trace-event-set-state. In addition to the documented meaning "Event > name pattern", it also has an alternate, undocumented meaning "QMP > command name pattern". The "undocumented" part is easy enough to fix. > However, QMP heavily frowns on argument values that need to be parsed. Still, pattern is parsed anyway, as pattern. But yes, this patch adds rather specific and tricky logic, which a lot more than just a pattern to search through the list. Another possible way is to update QAPI code generator to insert a personal trace point for each qmp command.. That seems more complicated to implement, but I can try.