aboutsummaryrefslogtreecommitdiff
path: root/scripts/tracetool
AgeCommit message (Collapse)Author
2023-11-19tracetool: avoid invalid escape in Python stringMarc-André Lureau
This is an error in Python 3.12; fix it by using a raw string literal. Cc: <qemu-stable@nongnu.org> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231108105649.60453-1-marcandre.lureau@redhat.com> (cherry picked from commit 4d96307c5b4fac40c6ca25f38318b4b65d315de0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2022-04-01trace: fix compilation with lttng-ust >= 2.13Marc-André Lureau
On Fedora 36, with lttng-ust 2.13.1, compilation fails with: In file included from trace/trace-ust-all.h:49085, from trace/trace-ust-all.c:13: /usr/include/lttng/tracepoint-event.h:67:10: error: #include expects "FILENAME" or <FILENAME> 67 | #include LTTNG_UST_TRACEPOINT_INCLUDE | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ In lttng-ust commit 41858e2b6e8 ("Fix: don't do macro expansion in tracepoint file name") from 2012, starting from lttng-ust 2.1, the API was changed to expect TRACEPOINT_INCLUDE to be defined as a string. In lttng-ust commit d2966b4b0b2 ("Remove TRACEPOINT_INCLUDE_FILE macro"), in 2021, the compatibility macro was removed. Use the "new" API from 2012, and bump the version requirement to 2.1 to fix compilation with >= 2.13. According to repology, all distributions we support have >= 2.1 (centos 8 has oldest with 2.8.1 afaict) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220328084717.367993-2-marcandre.lureau@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-02-09tracing: excise the tcg related from tracetoolAlex Bennée
Now we have no TCG trace events and no longer handle them in the code we can remove the handling from the tracetool to generate them. vcpu tracing is still available although the existing syscall event is an exercise in redundancy (plugins and -strace can also get the information). Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Luis Vilanova <vilanova@imperial.ac.uk> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220204204335.1689602-21-alex.bennee@linaro.org>
2021-03-09scripts/tracetool: Replace the word 'whitelist'Philippe Mathieu-Daudé
Follow the inclusive terminology from the "Conscious Language in your Open Source Projects" guidelines [*] and replace the words "whitelist" appropriately. [*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20210303184644.1639691-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-02-01trace: make the 'log' backend timestamp configurableStefan Hajnoczi
Timestamps in tracing output can be distracting. Make it possible to control tid/timestamp printing with -msg timestamp=on|off. The default is no tid/timestamps. Previously they were always printed. Suggested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210125113507.224287-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-01tracetool: also strip %l and %ll from systemtap format stringsDaniel P. Berrangé
All variables are 64-bit and so %l / %ll are not required, and the latter is actually invalid: $ sudo stap -e 'probe begin{printf ("BEGIN")}' -I . parse error: invalid or missing conversion specifier saw: operator ',' at ./qemu-system-x86_64-log.stp:15118:101 source: printf("%d@%d vhost_vdpa_set_log_base dev: %p base: 0x%x size: %llu refcnt: %d fd: %d log: %p\n", pid(), gettimeofday_ns(), dev, base, size, refcnt, fd, log) ^ Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Laurent Vivier <lvivier@redhat.com> Message-id: 20210106130239.1004729-1-berrange@redhat.com [Fixed "simiarly" typo found by Laurent Vivier <lvivier@redhat.com> --Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-01tracetool: fix "PRI" macro decodingLaurent Vivier
macro is not reset after use, so the format decoded is always the one of the first "PRI" in the format string. For instance: vhost_vdpa_set_config(void *dev, uint32_t offset, uint32_t size, \ uint32_t flags) "dev: %p offset: %"PRIu32" \ size: %"PRIu32" flags: 0x%"PRIx32 generates: printf("%d@%d vhost_vdpa_set_config dev: %p offset: %u size: %u \ flags: 0x%u\n", pid(), gettimeofday_ns(), dev, offset, \ size, flags) for the "flags" parameter, we can see a "0x%u" rather than a "0x%x" because the first macro was "PRIu32" (for offset). In the loop, macro becomes "PRIu32PRIu32PRIx32", and c_macro_to_format() returns always macro[3] ('u' in this case). This patch resets macro after the format has been decoded. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20210105191721.120463-3-lvivier@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-01-04tracetool: show trace-events filename/lineno in fmt string errorsStefan Hajnoczi
The compiler encounters trace event format strings in generated code. Format strings are error-prone and therefore clear compiler errors are important. Use the #line directive to show the trace-events filename and line number in format string errors: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/cpp/Line-Control.html For example, if the cpu_in trace event's %u is changed to %p the following error is reported: trace-events:29:18: error: format ‘%p’ expects argument of type ‘void *’, but argument 7 has type ‘unsigned int’ [-Werror=format=] Line 29 in trace-events is where cpu_in is defined. This works for any trace-events file in the QEMU source tree and the correct path is displayed. Unfortunately there does not seem to be a way to set the column, so "18" is not the right character on that line. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200827142915.108730-5-stefanha@redhat.com>
2021-01-04tracetool: add input filename and line number to EventStefan Hajnoczi
Store the input filename and line number in Event. A later patch will use this to improve error messages. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200827142915.108730-4-stefanha@redhat.com>
2021-01-04tracetool: add out_lineno and out_next_lineno to out()Stefan Hajnoczi
Make the output file line number and next line number available to out(). A later patch will use this to improve error messages. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200827142915.108730-3-stefanha@redhat.com>
2021-01-04tracetool: add output filename command-line argumentStefan Hajnoczi
The tracetool.py script writes to stdout. This means the output filename is not available to the script. Add the output filename to the command-line so that the script has access to the filename. This also simplifies the tracetool.py invocation. It's no longer necessary to use meson's custom_build(capture : true) to save output. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200827142915.108730-2-stefanha@redhat.com>
2020-11-11scripts/tracetool: silence SystemTap dtrace(1) long long warningsStefan Hajnoczi
SystemTap's dtrace(1) prints the following warning when it encounters long long arguments: Warning: /usr/bin/dtrace:trace/trace-dtrace-hw_virtio.dtrace:76: syntax error near: probe vhost_vdpa_dev_start Warning: Proceeding as if --no-pyparsing was given. Use the uint64_t and int64_t types, respectively. This works with all host CPU 32- and 64-bit data models (ILP32, LP64, and LLP64) that QEMU supports. Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20201020094043.159935-1-stefanha@redhat.com Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-09-17scripts/: fix some comment spelling errorszhaolichang
I found that there are many spelling errors in the comments of qemu, so I used the spellcheck tool to check the spelling errors and finally found some spelling errors in the scripts folder. Signed-off-by: zhaolichang <zhaolichang@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200917075029.313-5-zhaolichang@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-09-09scripts/tracetool: Use void pointer for vcpuRoman Bolshakov
dtrace on macOS complains that CPUState * is used for a few probes: dtrace: failed to compile script trace-dtrace-root.dtrace: line 130: syntax error near "CPUState" A comment in scripts/tracetool/__init__.py mentions that: We only want to allow standard C types or fixed sized integer types. We don't want QEMU specific types as we can't assume trace backends can resolve all the typedefs Fixes: 3d211d9f4dbee ("trace: Add 'vcpu' event property to trace guest vCPU") Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-id: 20200717093517.73397-3-r.bolshakov@yadro.com Cc: Cameron Esfahani <dirty@apple.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-09-09scripts/tracetool: Fix dtrace generation for macOSRoman Bolshakov
dtrace USDT is fully supported since OS X 10.6. There are a few peculiarities compared to other dtrace flavors. 1. It doesn't accept empty files. 2. It doesn't recognize bool type but accepts C99 _Bool. 3. It converts int8_t * in probe points to char * in header files and introduces [-Wpointer-sign] warning. Cc: Cameron Esfahani <dirty@apple.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20200717093517.73397-2-r.bolshakov@yadro.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-08-21libqemuutil, qapi, trace: convert to mesonPaolo Bonzini
This shows how to do some "computations" in meson.build using its array and dictionary data structures, and also a basic usage of the sourceset module for conditional compilation. Notice the new "if have_system" part of util/meson.build, which fixes a bug in the old build system was buggy: util/dbus.c was built even for non-softmmu builds, but the dependency on -lgio was lost when the linking was done through libqemuutil.a. Because all of its users required gio otherwise, the bug was hidden. Meson instead propagates libqemuutil's dependencies down to its users, and shows the problem. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-21trace: switch position of headers to what Meson requiresPaolo Bonzini
Meson doesn't enjoy the same flexibility we have with Make in choosing the include path. In particular the tracing headers are using $(build_root)/$(<D). In order to keep the include directives unchanged, the simplest solution is to generate headers with patterns like "trace/trace-audio.h" and place forwarding headers in the source tree such that for example "audio/trace.h" includes "trace/trace-audio.h". This patch is too ugly to be applied to the Makefiles now. It's only a way to separate the changes to the tracing header files from the Meson rewrite of the tracing logic. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-30tracetool: carefully define SDT_USE_VARIADICStefan Hajnoczi
The dtrace backend defines SDT_USE_VARIADIC as a workaround for a conflict with a LTTng UST header file, which requires SDT_USE_VARIADIC to be defined. LTTng UST <lttng/tracepoint.h> breaks if included after generated dtrace headers because SDT_USE_VARIADIC will already be defined: #ifdef LTTNG_UST_HAVE_SDT_INTEGRATION #define SDT_USE_VARIADIC <-- error, it's already defined #include <sys/sdt.h> Be more careful when defining SDT_USE_VARIADIC. This fixes the build when both the dtrace and ust tracers are enabled at the same time. Fixes: 27e08bab94f7c6ebe0b75938c98c394c969e3fd8 ("tracetool: work around ust <sys/sdt.h> include conflict") Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20200729153926.127083-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-07-07tracetool: work around ust <sys/sdt.h> include conflictStefan Hajnoczi
Both the dtrace and ust backends may include <sys/sdt.h> but LTTng Userspace Tracer 2.11 and later requires SDT_USE_VARIADIC to be defined before including the header file. This is a classic problem with C header files included from different parts of a program. If the same header is included twice within the same compilation unit then the first inclusion determines the macro environment. Work around this by defining SDT_USE_VARIADIC in the dtrace backend too. It doesn't hurt and fixes a missing STAP_PROBEV() compiler error when the ust backend is enabled together with the dtrace backend. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20200625140757.237012-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-06-24scripts/tracetool: Update maintainer email addressPhilippe Mathieu-Daudé
There is an effort in progress to generate a QEMU Python package. As I'm not sure this old email is still valid, update it to not produce package with broken maintainer email. Patch created mechanically by running: $ sed -i 's,\(__email__ *= "\)stefanha@linux.vnet.ibm.com",\1stefanha@redhat.com",' \ $(git grep -l 'email.*stefanha@linux.vnet.ibm.com') Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200511082816.696-1-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-02-07scripts/tracetool: Remove shebang headerPhilippe Mathieu-Daudé
Patch created mechanically by running: $ chmod 644 $(git grep -lF '#!/usr/bin/env python' \ | xargs grep -L 'if __name__.*__main__') $ sed -i "/^#\!\/usr\/bin\/\(env\ \)\?python.\?$/d" \ $(git grep -lF '#!/usr/bin/env python' \ | xargs grep -L 'if __name__.*__main__') Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200130163232.10446-9-philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-28trace: add mmu_index to mem_infoAlex Bennée
We are going to re-use mem_info later for plugins and will need to track the mmu_idx for softmmu code. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2019-10-15trace: avoid "is" with a literal Python 3.8 warningsStefan Hajnoczi
The following statement produces a SyntaxWarning with Python 3.8: if len(format) is 0: scripts/tracetool/__init__.py:459: SyntaxWarning: "is" with a literal. Did you mean "=="? Use the conventional len(x) == 0 syntax instead. Reported-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010122154.10553-1-stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-09-18trace: Forbid event format ending with newline characterPhilippe Mathieu-Daudé
Event format ending with newlines confuse the trace reports. Forbid them. Add a check to refuse new format added with trailing newline: $ make [...] GEN hw/misc/trace.h Traceback (most recent call last): File "scripts/tracetool.py", line 152, in <module> main(sys.argv) File "scripts/tracetool.py", line 143, in main events.extend(tracetool.read_events(fh, arg)) File "scripts/tracetool/__init__.py", line 367, in read_events event = Event.build(line) File "scripts/tracetool/__init__.py", line 281, in build raise ValueError("Event format can not end with a newline character") ValueError: Error at hw/misc/trace-events:121: Event format can not end with a newline character Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190916095121.29506-3-philmd@redhat.com Message-Id: <20190916095121.29506-3-philmd@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-08-16trace: Do not include qom/cpu.h into generated trace.hMarkus Armbruster
docs/devel/tracing.txt explains "since many source files include trace.h, [the generated trace.h use] a minimum of types and other header files included to keep the namespace clean and compile times and dependencies down." Commit 4815185902 "trace: Add per-vCPU tracing states for events with the 'vcpu' property" made them all include qom/cpu.h via control-internal.h. qom/cpu.h in turn includes about thirty headers. Ouch. Per-vCPU tracing is currently not supported in sub-directories' trace-events. In other words, qom/cpu.h can only be used in trace-root.h, not in any trace.h. Split trace/control-vcpu.h off trace/control.h and trace/control-internal.h. Have the generated trace.h include trace/control.h (which no longer includes qom/cpu.h), and trace-root.h include trace/control-vcpu.h (which includes it). The resulting improvement is a bit disappointing: in my "build everything" tree, some 1100 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h) depend on a trace.h, and about 600 of them no longer depend on qom/cpu.h. But more than 1300 others depend on trace-root.h. More work is clearly needed. Left for another day. Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-8-armbru@redhat.com>
2019-08-16trace: Eliminate use of TARGET_FMT_plxMarkus Armbruster
hw/tpm/trace-events uses TARGET_FMT_plx formats with uint64_t arguments. That's wrong, TARGET_FMT_plx takes hwaddr. Since hwaddr happens to be uint64_t, it works anyway. Messed up in commit ec427498da5, v2.12.0. Clean up by replacing TARGET_FMT_plx with its macro expansion. scripts/tracetool/format/log_stap.py (commit 62dd1048c0b, v4.0.0) has a special case for TARGET_FMT_plx. Delete it. Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20190812052359.30071-7-armbru@redhat.com>
2019-06-12Include qemu-common.h exactly where neededMarkus Armbruster
No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]
2019-06-10cpu: Replace ENV_GET_CPU with env_cpuRichard Henderson
Now that we have both ArchCPU and CPUArchState, we can define this generically instead of via macro in each target's cpu.h. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-03-22trace: avoid SystemTap dtrace(1) warnings on empty filesStefan Hajnoczi
target/hppa/trace-events only contains disabled events, resulting in a trace-dtrace.dtrace file that says "provider qemu {}". SystemTap's dtrace(1) tool prints a warning when processing this input file. This patch avoids the error by emitting an empty file instead of "provider qemu {}" when there are no enabled trace events. Fixes: 23c3d569f44284066714ff7c46bc4f19e630583f ("target/hppa: add TLB trace events") Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 20190321170831.6539-3-stefanha@redhat.com Message-Id: <20190321170831.6539-3-stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-01-24trace: add ability to do simple printf logging via systemtapDaniel P. Berrangé
The dtrace systemtap trace backend for QEMU is very powerful but it is also somewhat unfriendly to users who aren't familiar with systemtap, or who don't need its power right now. stap -e "....some strange script...." The 'log' backend for QEMU by comparison is very crude but incredibly easy to use: $ qemu -d trace:qio* ...some args... 23266@1547735759.137292:qio_channel_socket_new Socket new ioc=0x563a8a39d400 23266@1547735759.137305:qio_task_new Task new task=0x563a891d0570 source=0x563a8a39d400 func=0x563a86f1e6c0 opaque=0x563a89078000 23266@1547735759.137326:qio_task_thread_start Task thread start task=0x563a891d0570 worker=0x563a86f1ce50 opaque=0x563a891d9d90 23273@1547735759.137491:qio_task_thread_run Task thread run task=0x563a891d0570 23273@1547735759.137503:qio_channel_socket_connect_sync Socket connect sync ioc=0x563a8a39d400 addr=0x563a891d9d90 23273@1547735759.138108:qio_channel_socket_connect_fail Socket connect fail ioc=0x563a8a39d400 This commit introduces a way to do simple printf style logging of probe points using systemtap. In particular it creates another set of tapsets, one per emulator: /usr/share/systemtap/tapset/qemu-*-log.stp These pre-define probe functions which simply call printf() on their arguments. The printf() format string is taken from the normal trace-events files, with a little munging to the format specifiers to cope with systemtap's more restrictive syntax. With this you can now do $ stap -e 'probe qemu.system.x86_64.log.qio*{}' 22806@1547735341399856820 qio_channel_socket_new Socket new ioc=0x56135d1d7c00 22806@1547735341399862570 qio_task_new Task new task=0x56135cd66eb0 source=0x56135d1d7c00 func=0x56135af746c0 opaque=0x56135bf06400 22806@1547735341399865943 qio_task_thread_start Task thread start task=0x56135cd66eb0 worker=0x56135af72e50 opaque=0x56135c071d70 22806@1547735341399976816 qio_task_thread_run Task thread run task=0x56135cd66eb0 We go one step further though and introduce a 'qemu-trace-stap' tool to make this even easier $ qemu-trace-stap run qemu-system-x86_64 'qio*' 22806@1547735341399856820 qio_channel_socket_new Socket new ioc=0x56135d1d7c00 22806@1547735341399862570 qio_task_new Task new task=0x56135cd66eb0 source=0x56135d1d7c00 func=0x56135af746c0 opaque=0x56135bf06400 22806@1547735341399865943 qio_task_thread_start Task thread start task=0x56135cd66eb0 worker=0x56135af72e50 opaque=0x56135c071d70 22806@1547735341399976816 qio_task_thread_run Task thread run task=0x56135cd66eb0 This tool is clever in that it will automatically change the SYSTEMTAP_TAPSET env variable to point to the directory containing the right set of probes for the QEMU binary path you give it. This is useful if you have QEMU installed in /usr but are trying to test and trace a binary in /home/berrange/usr/qemu-git. In that case you'd do $ qemu-trace-stap run /home/berrange/usr/qemu-git/bin/qemu-system-x86_64 'qio*' And it'll make sure /home/berrange/usr/qemu-git/share/systemtap/tapset is used for the trace session The 'qemu-trace-stap' script takes a verbose arg so you can understand what it is running $ qemu-trace-stap run /home/berrange/usr/qemu-git/bin/qemu-system-x86_64 'qio*' Using tapset dir '/home/berrange/usr/qemu-git/share/systemtap/tapset' for binary '/home/berrange/usr/qemu-git/bin/qemu-system-x86_64' Compiling script 'probe qemu.system.x86_64.log.qio* {}' Running script, <Ctrl>-c to quit ...trace output... It can enable multiple probes at once $ qemu-trace-stap run qemu-system-x86_64 'qio*' 'qcrypto*' 'buffer*' By default it monitors all existing running processes and all future launched proceses. This can be restricted to a specific PID using the --pid arg $ qemu-trace-stap run --pid 2532 qemu-system-x86_64 'qio*' Finally if you can't remember what probes are valid it can tell you $ qemu-trace-stap list qemu-system-x86_64 ahci_check_irq ahci_cmd_done ahci_dma_prepare_buf ahci_dma_prepare_buf_fail ahci_dma_rw_buf ahci_irq_lower ...snip... Or list just those matching a prefix pattern $ qemu-trace-stap list -v qemu-system-x86_64 'qio*' Using tapset dir '/home/berrange/usr/qemu-git/share/systemtap/tapset' for binary '/home/berrange/usr/qemu-git/bin/qemu-system-x86_64' Listing probes with name 'qemu.system.x86_64.log.qio*' qio_channel_command_abort qio_channel_command_new_pid qio_channel_command_new_spawn qio_channel_command_wait qio_channel_file_new_fd ...snip... Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20190123120016.4538-5-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-01-24trace: forbid use of %m in trace event format stringsDaniel P. Berrangé
The '%m' format instructs glibc's printf()/syslog() implementation to insert the contents of strerror(errno). Since this is a glibc extension it should generally be avoided in QEMU due to need for portability to a variety of platforms. Even though vfio is Linux-only code that could otherwise use "%m", it must still be avoided in trace-events files because several of the backends do not use the format string and so this error information is invisible to them. The errno string value should be given as an explicit trace argument instead, making it accessible to all backends. This also allows it to work correctly with future patches that use the format string with systemtap's simple printf code. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20190123120016.4538-4-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-01-24trace: enforce that every trace-events file has a final newlineDaniel P. Berrangé
When generating the trace-events-all file, the build system simply concatenates all the individual trace-events files. If any one of those files does not have a final newline, the printf format string will have the contents of the first line of the next file appended to it, which is usually a '#' comment. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20190123120016.4538-3-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-01-17scripts: Remove unused python importsPhilippe Mathieu-Daudé
Reported-by: LGTM code review Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20181108143422.15955-1-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-12-12tracetool: Include thread id information in log backendFabiano Rosas
Currently the log backend prints the process id of QEMU at the start of each output line, but since threads share the same PID there is no clear distinction between their outputs. Having the thread id present in the log makes it easier to see when output comes from different threads. E.g.: 12423@1538597569.672527:qemu_mutex_lock waiting on mutex 0x1103ee60 (/root/qemu/util/main-loop.c:236) ... 12430@1538597569.503928:qemu_mutex_unlock released mutex 0x1103ee60 (/root/qemu/cpus.c:1238) 12431@1538597569.503937:qemu_mutex_locked taken mutex 0x1103ee60 (/root/qemu/cpus.c:1257) ^here In the above, 12423 is the main process id and 12430 & 12431 are the two vcpu threads. (qemu) info cpus * CPU #0: thread_id=12430 CPU #1: thread_id=12431 Suggested-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-06-29trace: Fix format string for the struct timeval members casted to size_tPhilippe Mathieu-Daudé
This fixes when using GCC with -Wformat-signedness: migration/trace.h: In function ‘_nocheck__trace_dirty_bitmap_load_success’: migration/trace.h:6368:24: error: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 3 has type ‘long unsigned int’ [-Werror=format=] qemu_log("%d@%zd.%06zd:dirty_bitmap_load_success " "" "\n", ~~^ %ld migration/trace.h:6370:18: (size_t)_now.tv_sec, (size_t)_now.tv_usec ~~~~~~~~~~~~~~~~~~~ migration/trace.h:6368:30: error: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 4 has type ‘long unsigned int’ [-Werror=format=] qemu_log("%d@%zd.%06zd:dirty_bitmap_load_success " "" "\n", ~~~~^ %06ld migration/trace.h:6370:39: (size_t)_now.tv_sec, (size_t)_now.tv_usec ~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-06-27trace: forbid floating point typesStefan Hajnoczi
Only one existing trace event uses a floating point type. Unfortunately float and double cannot be supported since SystemTap does not have floating point types. Remove float and double from the whitelist and document this limitation. Update the migrate_transferred trace event to use uint64_t instead of double. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-id: 20180621150254.4922-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-12trace: only permit standard C types and fixed size integer typesDaniel P. Berrangé
Some trace backends will compile code based on the declared trace events. It should not be assumed that the backends can resolve any QEMU specific typedefs. So trace events should restrict their argument types to the standard C types and fixed size integer types. Any complex pointer types can be declared as "void *" for purposes of trace events, since nothing will be dereferencing these pointer arguments. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20180308155524.5082-3-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-12trace: include filename when printing parser error messagesDaniel P. Berrangé
Improves error messages from: ValueError: Error on line 72: need more than 1 value to unpack To ValueError: Error at /home/berrange/src/virt/qemu/trace-events:72: need more than 1 value to unpack Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180306154650.24075-1-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-12log-for-trace.h: Split out parts of log.h used by trace.hPeter Maydell
A persistent build problem we see is where a source file accidentally omits the #include of log.h. This slips through local developer testing because if you configure with the default (log) trace backend trace.h will pull in log.h for you. Compilation fails only if some other backend is selected. To make this error cause a compile failure regardless of the configured trace backend, split out the parts of log.h that trace.h requires into a new log-for-trace.h header. Since almost all manual uses of the log.h functions will use constants or functions which aren't in log-for-trace.h, this will let us catch missing #include "qemu/log.h" more consistently. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180213140029.8308-1-peter.maydell@linaro.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-02-19tracetool: For ust trace bool type as ctf_integerJon Emil Jahren
Previously functions having arguments of type bool was not traced properly. The bool arguments were missing from the trace. Signed-off-by: Jon Emil Jahren <jonemilj@gmail.com> Message-id: 20180129041648.30884-3-jonemilj@gmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-02-19tracetool: Update argument format regex to non-greedy starJon Emil Jahren
Using the greedy star matching, arguments like "...%"PRIx64 caused issues for functions with multiple PRI formats. The issue was only seen with the ust backend, as it is the only one using the format regex. The result for many functions was that the arguments coming after the greedy star end was left out of the tracepoint, and in some cases some of the arguments that was traced had the wrong format. Signed-off-by: Jon Emil Jahren <jonemilj@gmail.com> Message-id: 20180129041648.30884-2-jonemilj@gmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-01-29tracetool: report error on foo() instead of foo(void)Stefan Hajnoczi
C functions with no arguments must be declared foo(void) instead of foo(). The tracetool argument list parser has never accepted an empty argument list. This patch adds a clear error message for this error case. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180110202553.31889-4-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-01-29tracetool: clarify that "formats" means "format strings"Stefan Hajnoczi
The terminology used by tracetool is not consistent with C sprintf or docs/devel/tracing.txt. The word "formats" is sometimes used to mean "format strings". This patch clarifies comments and error messages that contain this word. Note that the error message lines are longer than 80 characters but I have not wrapped them to aid grepping. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180110202553.31889-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-01-29tracetool: prefix parse errors with line numbersStefan Hajnoczi
Include the file line number in the message that is printed when trace-events parse errors are raised. [Use enumerate(fobj, 1) to avoid having to increment a 0-based index later, as suggested by Eric Blake. --Stefan] Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180110202553.31889-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-08-15trace: use static event ID mapping in simpletrace.stpStefan Hajnoczi
This is a partial revert of commit 7f1b588f20d027730676e627713ae3bbf6baab04 ("trace: emit name <-> ID mapping in simpletrace header"), which broke the SystemTap flight recorder because event mapping records may not be present in the ring buffer when the trace is analyzed. This means simpletrace.py --no-header does not know the event ID mapping needed to pretty-print the trace. Instead of numbering events dynamically, use a static event ID mapping as dictated by the event order in the trace-events-all file. The simpletrace.py script also uses trace-events-all so the next patch will fix the simpletrace.py --no-header option to take advantage of this knowledge. Cc: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170815084430.7128-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-08-01trace: add TRACE_<event>_BACKEND_DSTATE()Stefan Hajnoczi
QEMU keeps track of trace event enabled/disabled state and provides monitor commands to inspect and modify the "dstate". SystemTap and LTTng UST maintain independent enabled/disabled states for each trace event, the other backends rely on QEMU dstate. Introduce a new per-event macro that combines backend-specific dstate like this: #define TRACE_MY_EVENT_BACKEND_DSTATE() ( \ QEMU_MY_EVENT_ENABLED() || /* SystemTap */ \ tracepoint_enabled(qemu, my_event) /* LTTng UST */ || \ false) This will be used to extend trace_event_get_state() in the next patch. [Daniel Berrange pointed out that QEMU_MY_EVENT_ENABLED() must be true by default, not false. This way events will fire even if the DTrace implementation does not implement the SystemTap semaphores feature. Ubuntu Precise uses lttng-ust-dev 2.0.2 which does not have tracepoint_enabled(), so we need a compatibility wrapper to keep Travis builds passing. --Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20170731140718.22010-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> fixup! trace: add TRACE_<event>_BACKEND_DSTATE()
2017-08-01trace: ensure unique function / variable names per .stp fileDaniel P. Berrange
The simpletrace compatibility code for systemtap creates a function and some global variables for mapping to event ID numbers. We generate multiple -simpletrace.stp files though, one per target and systemtap considers functions & variables to be globally scoped, not per file. So if trying to use the simpletrace compat probes, systemtap will complain: # stap -e 'probe qemu.system.arm.simpletrace.visit_type_str { print( "hello")}' semantic error: conflicting global variables: identifier 'event_name_to_id_map' at /usr/share/systemtap/tapset/qemu-aarch64-simpletrace.stp:3:8 source: global event_name_to_id_map ^ identifier 'event_name_to_id_map' at /usr/share/systemtap/tapset/qemu-system-arm-simpletrace.stp:3:8 source: global event_name_to_id_map ^ WARNING: cross-file global variable reference to identifier 'event_name_to_id_map' at /usr/share/systemtap/tapset/qemu-system-arm-simpletrace.stp:3:8 from: identifier 'event_name_to_id_map' at /usr/share/systemtap/tapset/qemu-aarch64-simpletrace.stp:8:21 source: if (!([name] in event_name_to_id_map)) { ^ WARNING: cross-file global variable reference to identifier 'event_next_id' at /usr/share/systemtap/tapset/qemu-system-arm-simpletrace.stp:4:8 from: identifier 'event_next_id' at :9:38 source: event_name_to_id_map[name] = event_next_id ^ We already have a string used to prefix probe names, so just replace '.' with '_' to get a function / variable name prefix Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170728133657.5525-1-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-07-17trace: [tcg, trivial] Re-align generated codeLluís Vilanova
Last patch removed a nesting level in generated code. Re-align all code generated by backends to be 4-column aligned. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-id: 149915824586.6295.17820926011082409033.stgit@frigg.lan Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-07-17trace: [tcg] Do not generate TCG code to trace dynamically-disabled eventsLluís Vilanova
If an event is dynamically disabled, the TCG code that calls the execution-time tracer is not generated. Removes the overheads of execution-time tracers for dynamically disabled events. As a bonus, also avoids checking the event state when the execution-time tracer is called from TCG-generated code (since otherwise TCG would simply not call it). Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-id: 149915799921.6295.13067154430923434035.stgit@frigg.lan Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-08trace: disallow more than 10 arguments per trace eventDaniel P. Berrange
The UST trace backend can only cope with upto 10 arguments. To ensure we don't exceed the limit when UST is not compiled in, disallow more than 10 arguments upfront. This prevents the case where: commit 0fc8aec7de64f2bf83a274a2a38b938ce03425d2 Author: Zhang Chen <zhangchen.fnst@cn.fujitsu.com> Date: Tue Apr 18 10:20:20 2017 +0800 COLO-compare: Optimize tcp compare trace event Optimize two trace events as one, adjust print format make it easy to read. rename trace_colo_compare_pkt_info_src/dst to trace_colo_compare_tcp_info. regressed the fix done in commit 2dfe5113b11ce0ddb08176ebb54ab7ac4104b413 Author: Alex Bennée <alex.bennee@linaro.org> Date: Fri Oct 28 14:25:59 2016 +0100 net: split colo_compare_pkt_info into two trace events It seems there is a limit to the number of arguments a UST trace event can take and at 11 the previous trace command broke the build. Split the trace into a src pkt and dst pkt trace to fix this. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20161028132559.8324-1-alex.bennee@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Now we get an immediate fail even when UST is disabled: GEN net/trace.h Traceback (most recent call last): File "/home/berrange/src/virt/qemu/scripts/tracetool.py", line 154, in <module> main(sys.argv) File "/home/berrange/src/virt/qemu/scripts/tracetool.py", line 145, in main events.extend(tracetool.read_events(fh)) File "/home/berrange/src/virt/qemu/scripts/tracetool/__init__.py", line 307, in read_events event = Event.build(line) File "/home/berrange/src/virt/qemu/scripts/tracetool/__init__.py", line 244, in build event = Event(name, props, fmt, args) File "/home/berrange/src/virt/qemu/scripts/tracetool/__init__.py", line 196, in __init__ "argument count" % name) ValueError: Event 'colo_compare_tcp_info' has more than maximum permitted argument count Makefile:96: recipe for target 'net/trace.h-timestamp' failed Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20170426153900.21066-1-berrange@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-23 14:49:19 +0000