Currently simpletrace assumes that events are given IDs
starting from 0, based on the order in which they appear
in the trace-events file, with no gaps. When the
trace-events file is split up, this assumption becomes
problematic.
To deal with this, extend the simpletrace format so that
it outputs a table of event name <-> ID mappings. That
will allow QEMU to assign arbitrary IDs to events without
breaking simpletrace parsing.
The v3 simple trace format was
FILE HEADER
EVENT TRACE RECORD 0
EVENT TRACE RECORD 1
...
EVENT TRACE RECORD N
The v4 simple trace format is now
FILE HEADER
EVENT MAPPING RECORD 0
EVENT MAPPING RECORD 1
...
EVENT MAPPING RECORD M
EVENT TRACE RECORD RECORD 0
EVENT TRACE RECORD RECORD 1
...
EVENT TRACE RECORD N
Although this shows all the mapping records being emitted
upfront, this is not required by the format. While the main
simpletrace backend will emit all mappings at startup,
the systemtap simpletrace.stp script will emit the mappings
at first use. eg
FILE HEADER
...
EVENT MAPPING RECORD 0
EVENT TRACE RECORD RECORD 0
EVENT TRACE RECORD RECORD 1
EVENT MAPPING RECORD 1
EVENT TRACE RECORD RECORD 2
...
EVENT TRACE RECORD N
This is more space efficient given that most trace records
only include a subset of events.
In modifying the systemtap simpletrace code, a 'begin' probe
was added to emit the trace event header, so you no longer
need to add '--no-header' when running simpletrace.py for
systemtap generated trace files.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-12-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The TraceEventID and TraceEventVCPUID enums constants are
no longer actually used for anything critical.
The TRACE_EVENT_COUNT limit is used to determine the size
of the TraceEvents array, and can be removed if we just
NULL terminate the array instead.
The TRACE_VCPU_EVENT_COUNT limit is used as a magic value
for marking non-vCPU events, and also for declaring the
size of the trace dstate mask in the CPUState struct.
The former usage can be replaced by a dedicated constant
TRACE_EVENT_VCPU_NONE, defined as (uint32_t)-1. For the
latter usage, we can simply define a constant for the
number of VCPUs, avoiding the need for the full enum.
The only other usages of the enum values can be replaced
by accesing the id/vcpu_id fields via the named TraceEvent
structs.
Reviewed-by: Lluís Vilanova <vilanova@ac.upc.edu>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1475588159-30598-11-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1454089805-5470-16-git-send-email-peter.maydell@linaro.org
This is cleaner, and improves error reporting with -daemonize.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-id: 1452174932-28657-4-git-send-email-den@openvz.org
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
On Windows, getpid() always returns an int value, but pid_t (which is
expected by the format string) is either a 32 bit or a 64 bit value.
Without a type cast (or a modified format string), the compiler prints
a warning when building for 64 bit Windows and the resulting trace_file_name
will include a wrong pid:
trace/simple.c:332:9: warning:
format ‘%lld’ expects argument of type ‘long long int’,
but argument 2 has type ‘int’ [-Wformat=]
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Thread API changed in glib-2.31 significantly. Before that version,
conditionals and mutexes were only allocated dynamically, using
_new()/_free() interface. in 2.31 and up, they're allocated statically
as regular variables, and old interface is deprecated.
(Note: glib docs says the new interface is available since version
2.32, but it was actually introduced in version 2.31).
Create the new interface using old primitives, by providing non-opaque
definitions of the base types (GCond and GMutex) using GOnces.
Replace #ifdeffery around GCond and GMutex in trace/simple.c and
coroutine-gthread.c too because it does not work anymore with the new
glib-compat.h.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[Use GOnce to support lazy initialization; introduce CompatGMutex
and CompatGCond. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Adds support to compile QEMU with multiple tracing backends at the same time.
For example, you can compile QEMU with:
$ ./configure --enable-trace-backends=ftrace,dtrace
Where 'ftrace' can be handy for having an in-flight record of events, and 'dtrace' can be later used to extract more information from the system.
This patch allows having both available without recompiling QEMU.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
It is useful to know the QEMU process ID when working with traces from
multiple VMs. Although the trace filename may contain the pid, tools
that aggregate traces or even trace globally need somewhere to record
the pid.
There is a reserved field in the trace event header struct that we can
use.
It is not necessary to bump the simpletrace file format version number
because it has already been incremented for the QEMU 2.1 release cycle
in commit "trace: [simple] Bump up log version number".
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The following tracetool cleanup changes the event numbering policy.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
glib versions prior to 2.31.0 require an explicit g_thread_init() call
to enable multi-threading.
Failure to initialize threading causes glib to take single-threaded code
paths without synchronization. For example, the g_slice allocator will
crash due to race conditions.
Fix this for all QEMU tool programs (qemu-nbd, qemu-io, qemu-img) by
moving the g_thread_init() call from vl.c:main() into a new
osdep.c:thread_init() constructor function.
thread_init() has __attribute__((constructor)) and is automatically
invoked by the runtime during startup.
We can now drop the "simple" trace backend's g_thread_init() call since
thread_init() already called it.
Note that we must keep coroutine-gthread.c's g_thread_init() call which
is located in a constructor function. There is no guarantee for
constructor function ordering so thread_init() may only be called later.
Reported-by: Mario de Chenno <mario.dechenno@unina2.it>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The GStaticMutex API was deprecated in glib 2.32. We cannot switch over
to GMutex unconditionally since we would drop support for older glib
versions. But the deprecated API warnings during build are annoying so
use static GMutex when possible.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The header is not necessary, given that the simple backend does not define any
inlined tracing routines.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The backend is forced to dump event numbers using 64 bits, as TraceEventID is
an enum.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
g_thread_create() was deprecated in favor of g_thread_new() and
g_cond_new() was deprecated in favor of GCond initialization. If the
host has glib 2.31 or newer, avoid using the deprecated functions.
This patch solves compiler warnings that are generated when glib's
deprecated functions are used.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1360676045-9204-3-git-send-email-stefanha@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Juan reported that RHEL 6.4 hosts give compiler warnings because we use
unsigned int while glib prototypes use volatile gint in trace/simple.c.
trace/simple.c:223: error: pointer targets in passing argument 1 of 'g_atomic_int_compare_and_exchange' differ in signedness
These variables are only accessed with glib atomic int functions so
let's play it by the book and use volatile gint.
Reported-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1360676045-9204-2-git-send-email-stefanha@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The GLib Reference Manual says:
It is very important that all accesses to a particular integer or
pointer be performed using only this API and that different sizes
of operation are not mixed or used on overlapping memory
regions. Never read or assign directly from or to a value --
always use this API.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Harsh Prateek Bora <harsh@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
We use atomic operations to keep track of dropped events.
Inconveniently, GLib supports only int and void * atomics, but the
counter dropped_events is uint64_t. Can't stop commit 62bab732: a
quick (gint *)&dropped_events bludgeons the compiler into submission.
That cast is okay only when int is exactly 64 bits wide, which it
commonly isn't.
If int is even wider, we clobber whatever follows dropped_events. Not
worth worrying about, as none of the machines that interest us have
such morbidly obese ints.
That leaves the common case: int narrower than 64 bits.
Harmless on little endian hosts: we just don't access the most
significant bits of dropped_events. They remain zero.
On big endian hosts, we use only the most significant bits of
dropped_events as counter. The least significant bits remain zero.
However, we write out the full value, which is the correct counter
shifted left a bunch of places.
Fix by changing the variables involved to int.
There's another, equally suspicious-looking (gint *)&trace_idx
argument to g_atomic_int_compare_and_exchange(), but that one casts
unsigned *, so it's okay. But it's also superfluous, because GLib's
atomic int operations work just fine for unsigned. Drop it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
asprintf is not available for all hosts. g_strdup_printf is
more portable and simplifies the code because if does not
need error handling.
The static variable does not need an explicit assignment to be NULL.
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Declaring a TraceRecord on the stack works fine. No need for a
uint8_t array and pointer aliasing.
Signed-off-by: Harsh Prateek Bora <harsh@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
The buffer argument is void* so it is not necessary to cast.
Signed-off-by: Harsh Prateek Bora <harsh@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
The TraceRecordHeader is really the header for the entire trace log
file. It's not per-record header so make this obvious by renaming it.
Signed-off-by: Harsh Prateek Bora <harsh@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Existing simpletrace backend allows to trace at max 6 args and does not
support strings. This newer tracelog format gets rid of fixed size records
and therefore allows to trace variable number of args including strings.
Sample trace with strings:
v9fs_version 0.000 tag=0xffff id=0x64 msize=0x2000 version=9P2000.L
v9fs_version_return 6.705 tag=0xffff id=0x64 msize=0x2000 version=9P2000.L
Signed-off-by: Harsh Prateek Bora <harsh@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Going forward with simpletrace v2 variable size trace records, we cannot
have a generic function to print trace event info and therefore this
interface becomes invalid.
As per Stefan Hajnoczi:
"This command is only available from the human monitor. It's not very
useful because it historically hasn't been able to pretty-print events
or show them in the right order (we use a ringbuffer but it prints
them out from index 0).
Therefore, I don't think we're under any obligation to keep this
command around. No one has complained about it's limitations - I
think this is a sign that no one has used it. I'd be okay with a
patch that removes it."
Ref: http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01268.html
Signed-off-by: Harsh Prateek Bora <harsh@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
This patch makes trace_thread_create() to use its function arg to
initialize thread. The other choice is to make this a function to use
void arg, but i prefer this way.
Signed-off-by: Jun Koi <junkoi2004@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
since commit f9b29ca03 included in release 2.31 (docs below say 2.32 but
that is not correct) and onwards g_thread_init is deprecated and calling
it is not required:
http://developer.gnome.org/glib/unstable/glib-Deprecated-Thread-APIs.html#g-thread-init
g_thread_init has been deprecated since version 2.32 and should not be
used in newly-written code. This function is no longer necessary. The
GLib threading system is automatically initialized at the start of your
program.
Fixes bulid failure when warnings are treated as errors on fedora 17.
I only tested the change to vl.c, and copy pasted to the two other
locations (couldn't decide if a wrapper for calling g_thread_init is
uglier).
Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
A basic wildcard matching is supported in both the monitor command
"trace-event" and the events list file. That means you can enable/disable
the events having a common prefix in a batch. For example, virtio-blk trace
events could be enabled using:
trace-event virtio_blk_* on
Signed-off-by: Mark Wu <wudxw@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
For Windows portability the simple trace backend must use the 'b' file
open mode. This prevents the stdio library from mangling 0x0a/0x0d
newline characters.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Convert the simple trace backend to glib so that it works under Windows.
We cannot use pthread directly but glib provides portable abstractions.
Also use glib atomics instead of newish gcc builtins which may not be
supported on Windows toolchains.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
The "-trace events" argument can be used to provide a file with a list of trace
event names that will be enabled prior to starting execution, thus providing
early tracing.
This saves the user from manually toggling event states through the monitor
interface or whichever backend-specific interface.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Generalize the 'st_print_trace_events' and 'st_change_trace_event_state' into
backend-specific 'trace_print_events' and 'trace_event_set_state' (respectively)
in the "trace/control.h" file.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
A default implementation for backend-specific routines is provided in
"trace/default.c", which backends can override by setting "trace_default=no" in
"configure".
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
