OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
b4cc583f02
qemu-e2k/trace-events

182 lines
8.8 KiB
Plaintext
Raw Normal View History

trace: Add trace-events file for declaring trace events This patch introduces the trace-events file where trace events can be declared like so: qemu_malloc(size_t size) "size %zu" qemu_free(void *ptr) "ptr %p" These trace event declarations are processed by a new tool called tracetool to generate code for the trace events. Trace event declarations are independent of the backend tracing system (LTTng User Space Tracing, ftrace markers, DTrace). The default "nop" backend generates empty trace event functions. Therefore trace events are disabled by default. The trace-events file serves two purposes: 1. Adding trace events is easy. It is not necessary to understand the details of a backend tracing system. The trace-events file is a single location where trace events can be declared without code duplication. 2. QEMU is not tightly coupled to one particular backend tracing system. In order to support tracing across QEMU host platforms and to anticipate new backend tracing systems that are currently maturing, it is important to be flexible and not tied to one system. This commit includes fixes from Prerna Saxena <prerna@linux.vnet.ibm.com> and Blue Swirl <blauwirbel@gmail.com>. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-05-22 18:52:39 +02:00
# Trace events for debugging and performance instrumentation
#
# This file is processed by the tracetool script during the build.
#
# To add a new trace event:
#
# 1. Choose a name for the trace event. Declare its arguments and format
# string.
#
# 2. Call the trace event from code using trace_##name, e.g. multiwrite_cb() ->
# trace_multiwrite_cb(). The source file must #include "trace.h".
#
# Format of a trace event:
#
trace: Support disabled events in trace-events Sometimes it is useful to disable a trace event. Removing the event from trace-events is not enough since source code will call the trace_*() function for the event. This patch makes it easy to build without specific trace events by marking them disabled in trace-events: disable multiwrite_cb(void *mcb, int ret) "mcb %p ret %d" This builds without the multiwrite_cb trace event. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> trace: Allow bulk enabling/disabling of trace events at compile time For 'simple' trace backend, allow bulk enabling/disabling of trace events at compile time. Trace events that are preceded by 'disable' keyword are compiled in, but turned off by default. These can individually be turned on using the monitor. All other trace events are enabled by default. TODO : This could be enhanced when the trace-event namespace is partitioned into a group and an ID within that group. In such a case, marking a group as enabled would automatically enable all trace-events listed under it. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-05-24 12:32:09 +02:00
# [disable] <name>(<type1> <arg1>[, <type2> <arg2>] ...) "<format-string>"
trace: Add trace-events file for declaring trace events This patch introduces the trace-events file where trace events can be declared like so: qemu_malloc(size_t size) "size %zu" qemu_free(void *ptr) "ptr %p" These trace event declarations are processed by a new tool called tracetool to generate code for the trace events. Trace event declarations are independent of the backend tracing system (LTTng User Space Tracing, ftrace markers, DTrace). The default "nop" backend generates empty trace event functions. Therefore trace events are disabled by default. The trace-events file serves two purposes: 1. Adding trace events is easy. It is not necessary to understand the details of a backend tracing system. The trace-events file is a single location where trace events can be declared without code duplication. 2. QEMU is not tightly coupled to one particular backend tracing system. In order to support tracing across QEMU host platforms and to anticipate new backend tracing systems that are currently maturing, it is important to be flexible and not tied to one system. This commit includes fixes from Prerna Saxena <prerna@linux.vnet.ibm.com> and Blue Swirl <blauwirbel@gmail.com>. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-05-22 18:52:39 +02:00
#
rename qemu_malloc and related to glib names for coherence Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Frediano Ziglio <freddy77@gmail.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-08-31 09:25:35 +02:00
# Example: g_malloc(size_t size) "size %zu"
trace: Add trace-events file for declaring trace events This patch introduces the trace-events file where trace events can be declared like so: qemu_malloc(size_t size) "size %zu" qemu_free(void *ptr) "ptr %p" These trace event declarations are processed by a new tool called tracetool to generate code for the trace events. Trace event declarations are independent of the backend tracing system (LTTng User Space Tracing, ftrace markers, DTrace). The default "nop" backend generates empty trace event functions. Therefore trace events are disabled by default. The trace-events file serves two purposes: 1. Adding trace events is easy. It is not necessary to understand the details of a backend tracing system. The trace-events file is a single location where trace events can be declared without code duplication. 2. QEMU is not tightly coupled to one particular backend tracing system. In order to support tracing across QEMU host platforms and to anticipate new backend tracing systems that are currently maturing, it is important to be flexible and not tied to one system. This commit includes fixes from Prerna Saxena <prerna@linux.vnet.ibm.com> and Blue Swirl <blauwirbel@gmail.com>. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-05-22 18:52:39 +02:00
#
trace: Support disabled events in trace-events Sometimes it is useful to disable a trace event. Removing the event from trace-events is not enough since source code will call the trace_*() function for the event. This patch makes it easy to build without specific trace events by marking them disabled in trace-events: disable multiwrite_cb(void *mcb, int ret) "mcb %p ret %d" This builds without the multiwrite_cb trace event. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> trace: Allow bulk enabling/disabling of trace events at compile time For 'simple' trace backend, allow bulk enabling/disabling of trace events at compile time. Trace events that are preceded by 'disable' keyword are compiled in, but turned off by default. These can individually be turned on using the monitor. All other trace events are enabled by default. TODO : This could be enhanced when the trace-event namespace is partitioned into a group and an ID within that group. In such a case, marking a group as enabled would automatically enable all trace-events listed under it. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-05-24 12:32:09 +02:00
# The "disable" keyword will build without the trace event.
#
trace: Add trace-events file for declaring trace events This patch introduces the trace-events file where trace events can be declared like so: qemu_malloc(size_t size) "size %zu" qemu_free(void *ptr) "ptr %p" These trace event declarations are processed by a new tool called tracetool to generate code for the trace events. Trace event declarations are independent of the backend tracing system (LTTng User Space Tracing, ftrace markers, DTrace). The default "nop" backend generates empty trace event functions. Therefore trace events are disabled by default. The trace-events file serves two purposes: 1. Adding trace events is easy. It is not necessary to understand the details of a backend tracing system. The trace-events file is a single location where trace events can be declared without code duplication. 2. QEMU is not tightly coupled to one particular backend tracing system. In order to support tracing across QEMU host platforms and to anticipate new backend tracing systems that are currently maturing, it is important to be flexible and not tied to one system. This commit includes fixes from Prerna Saxena <prerna@linux.vnet.ibm.com> and Blue Swirl <blauwirbel@gmail.com>. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-05-22 18:52:39 +02:00
# The <name> must be a valid as a C function name.
#
# Types should be standard C types. Use void * for pointers because the trace
# system may not have the necessary headers included.
#
# The <format-string> should be a sprintf()-compatible format string.
trace: Trace qemu_malloc() and qemu_vmalloc() It is often useful to instrument memory management functions in order to find leaks or performance problems. This patch adds trace events for the memory allocation primitives. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-05-22 19:09:25 +02:00
aio: add polling mode to AioContext The AioContext event loop uses ppoll(2) or epoll_wait(2) to monitor file descriptors or until a timer expires. In cases like virtqueues, Linux AIO, and ThreadPool it is technically possible to wait for events via polling (i.e. continuously checking for events without blocking). Polling can be faster than blocking syscalls because file descriptors, the process scheduler, and system calls are bypassed. The main disadvantage to polling is that it increases CPU utilization. In classic polling configuration a full host CPU thread might run at 100% to respond to events as quickly as possible. This patch implements a timeout so we fall back to blocking syscalls if polling detects no activity. After the timeout no CPU cycles are wasted on polling until the next event loop iteration. The run_poll_handlers_begin() and run_poll_handlers_end() trace events are added to aid performance analysis and troubleshooting. If you need to know whether polling mode is being used, trace these events to find out. Note that the AioContext is now re-acquired before disabling notify_me in the non-polling case. This makes the code cleaner since notify_me was enabled outside the non-polling AioContext release region. This change is correct since it's safe to keep notify_me enabled longer (disabling is an optimization) but potentially causes unnecessary event_notifer_set() calls. I think the chance of performance regression is small here. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20161201192652.9509-4-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-12-01 20:26:42 +01:00
# aio-posix.c
run_poll_handlers_begin(void *ctx, int64_t max_ns) "ctx %p max_ns %"PRId64
run_poll_handlers_end(void *ctx, bool progress) "ctx %p progress %d"
aio: self-tune polling time This patch is based on the algorithm for the kvm.ko halt_poll_ns parameter in Linux. The initial polling time is zero. If the event loop is woken up within the maximum polling time it means polling could be effective, so grow polling time. If the event loop is woken up beyond the maximum polling time it means polling is not effective, so shrink polling time. If the event loop makes progress within the current polling time then the sweet spot has been reached. This algorithm adjusts the polling time so it can adapt to variations in workloads. The goal is to reach the sweet spot while also recognizing when polling would hurt more than help. Two new trace events, poll_grow and poll_shrink, are added for observing polling time adjustment. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20161201192652.9509-13-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-12-01 20:26:51 +01:00
poll_shrink(void *ctx, int64_t old, int64_t new) "ctx %p old %"PRId64" new %"PRId64
poll_grow(void *ctx, int64_t old, int64_t new) "ctx %p old %"PRId64" new %"PRId64
aio: add polling mode to AioContext The AioContext event loop uses ppoll(2) or epoll_wait(2) to monitor file descriptors or until a timer expires. In cases like virtqueues, Linux AIO, and ThreadPool it is technically possible to wait for events via polling (i.e. continuously checking for events without blocking). Polling can be faster than blocking syscalls because file descriptors, the process scheduler, and system calls are bypassed. The main disadvantage to polling is that it increases CPU utilization. In classic polling configuration a full host CPU thread might run at 100% to respond to events as quickly as possible. This patch implements a timeout so we fall back to blocking syscalls if polling detects no activity. After the timeout no CPU cycles are wasted on polling until the next event loop iteration. The run_poll_handlers_begin() and run_poll_handlers_end() trace events are added to aid performance analysis and troubleshooting. If you need to know whether polling mode is being used, trace these events to find out. Note that the AioContext is now re-acquired before disabling notify_me in the non-polling case. This makes the code cleaner since notify_me was enabled outside the non-polling AioContext release region. This change is correct since it's safe to keep notify_me enabled longer (disabling is an optimization) but potentially causes unnecessary event_notifer_set() calls. I think the chance of performance regression is small here. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20161201192652.9509-4-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-12-01 20:26:42 +01:00
aio: add generic thread-pool facility Add a generic thread-pool. The code is roughly based on posix-aio-compat.c, with some changes, especially the following: - use QemuSemaphore instead of QemuCond; - separate the state of the thread from the return code of the worker function. The return code is totally opaque for the thread pool; - do not busy wait when doing cancellation. A more generic threadpool (but still specific to I/O so that in the future it can use special scheduling classes or PI mutexes) can have many uses: it allows more flexibility in raw-posix.c and can more easily be extended to Win32, and it will also be used to do an msync of the persistent bitmap. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-02-23 13:23:34 +01:00
# thread-pool.c
threadpool: move globals into struct ThreadPool Move global variables into a struct so multiple thread pools can be supported in the future. This patch does not change thread-pool.h interfaces. There is still a global thread pool and it is not yet possible to create/destroy individual thread pools. Moving the variables into a struct first makes later patches easier to review. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
2013-03-07 13:41:45 +01:00
thread_pool_submit(void *pool, void *req, void *opaque) "pool %p req %p opaque %p"
thread_pool_complete(void *pool, void *req, void *opaque, int ret) "pool %p req %p opaque %p ret %d"
aio: add generic thread-pool facility Add a generic thread-pool. The code is roughly based on posix-aio-compat.c, with some changes, especially the following: - use QemuSemaphore instead of QemuCond; - separate the state of the thread from the return code of the worker function. The return code is totally opaque for the thread pool; - do not busy wait when doing cancellation. A more generic threadpool (but still specific to I/O so that in the future it can use special scheduling classes or PI mutexes) can have many uses: it allows more flexibility in raw-posix.c and can more easily be extended to Win32, and it will also be used to do an msync of the persistent bitmap. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-02-23 13:23:34 +01:00
thread_pool_cancel(void *req, void *opaque) "req %p opaque %p"
trace: Trace port IO Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-08-11 13:45:11 +02:00
# ioport.c
ioport: do not use CPU_LOG_IOPORT These messages are disabled by default; a perfect usecase for tracepoints, which in fact already exist. Add the missing information to them and stop using qemu_log_mask. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-10-16 15:08:34 +02:00
cpu_in(unsigned int addr, char size, unsigned int val) "addr %#x(%c) value %u"
cpu_out(unsigned int addr, char size, unsigned int val) "addr %#x(%c) value %u"
trace: Trace entry point of balloon request handler Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-08-11 13:46:03 +02:00
# balloon.c
# Since requests are raised via monitor, not many tracepoints are needed.
trace: enable all events Given that all events with programmatically-controlled state are disabled by default, we can delete the "disable" property from all events. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
2011-08-31 20:31:58 +02:00
balloon_event(void *opaque, unsigned long addr) "opaque %p addr %lu"
apic: convert debug printf statements to tracepoints Replace debug printf statements with tracepoints. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2010-10-20 18:41:28 +02:00
trace: Trace vm_start()/vm_stop() VM state change notifications are invoked from vm_start()/vm_stop(). Trace these state changes so we can reason about the state of the VM from trace output. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-11-16 13:20:25 +01:00
# vl.c
trace: enable all events Given that all events with programmatically-controlled state are disabled by default, we can delete the "disable" property from all events. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
2011-08-31 20:31:58 +02:00
vm_state_notify(int running, int reason) "running %d reason %d"
Add search path support for qemu data files. This patch allows to specify multiple directories where qemu should look for data files. To implement that the behavior of the -L switch is slightly different now: Instead of replacing the data directory the path specified will be appended to the data directory list. So when specifiying -L multiple times all directories specified will be checked, in the order they are specified on the command line, instead of just the last one. Additionally the default paths are always appended to the directory data list. This allows to specify a incomplete directory (such as the seabios out/ directory) via -L. Anything not found there will be loaded from the default paths, so you don't have to create a symlink farm for all the rom blobs. For trouble-shooting a tracepoint has been added, logging which blob has been loaded from which location. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 1362739344-8068-1-git-send-email-kraxel@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-03-08 11:42:24 +01:00
load_file(const char *name, const char *path) "name %s location %s"
vl: add runstate_set tracepoint This patch enables us to know RunState transition. It will be userful for investigation when the trouble occured in special event such like live migration, shutdown, suspend, and so on. Signed-off-by: Kazuya Saito <saito.kazuya@jp.fujitsu.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-03-22 09:26:59 +01:00
runstate_set(int new_state) "new state %d"
vl: add system_wakeup_request tracepoint It might be useful for tracing migration. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2014-03-06 21:03:36 +01:00
system_wakeup_request(int reason) "reason=%d"
trace: add qemu_system_powerdown_request and qemu_system_shutdown_request trace events We have the experience that the guest doesn't stop successfully though it was instructed to shut down. The root cause may be not in QEMU mostly. However, QEMU is often suspected at the beginning just because the issue occurred in virtualization environment. Therefore, we need to affirm that QEMU received the shutdown request and raised ACPI irq from "virsh shutdown" command, virt-manger or stopping QEMU process to the VM . So that we can affirm the problems was belonged to the Guset OS rather than the QEMU itself. When we stop guests by "virsh shutdown" command or virt-manger, or stopping QEMU process, qemu_system_powerdown_request() or qemu_system_shutdown_request() is called. Then the below functions in main_loop_should_exit() of Vl.c are called roughly in the following order. if (qemu_powerdown_requested()) qemu_system_powerdown() monitor_protocol_event(QEVENT_POWERDOWN, NULL) OR if(qemu_shutdown_requested()} monitor_protocol_event(QEVENT_SHUTDOWN, NULL); The tracepoint of monitor_protocol_event() already exists, but no tracepoints are defined for qemu_system_powerdown_request() and qemu_system_shutdown_request(). So this patch adds two tracepoints for the two functions. We believe that it will become much easier to isolate the problem mentioned above by these tracepoints. Signed-off-by: Yang Zhiyong <yangzy.fnst@cn.fujitsu.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-21 20:43:03 +02:00
qemu_system_shutdown_request(void) ""
qemu_system_powerdown_request(void) ""
qed: Table, L2 cache, and cluster functions This patch adds code to look up data cluster offsets in the image via the L1/L2 tables. The L2 tables are writethrough cached in memory for performance (each read/write requires a lookup so it is essential to cache the tables). With cluster lookup code in place it is possible to implement bdrv_is_allocated() to query the number of contiguous allocated/unallocated clusters. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2010-12-06 17:08:01 +01:00
spice: add chardev (v5) Adding a chardev backend for spice, where spice determines what to do with it based on the name attribute given during chardev creation. For usage by spice vdagent in conjunction with a properly named virtio-serial device, and future smartcard channel usage. Example usage: qemu -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent \ -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 v4->v5: * add tracing events * fix missing comma * fix help string to show debug is optional v3->v4: * updated commit message v1->v3 changes: (v2 had a wrong commit message) * removed spice-qemu-char.h, folded into ui/qemu-spice.h * removed dead IOCTL code * removed comment * removed ifdef CONFIG_SPICE from qemu-config.c and qemu-options.hx help. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2011-01-19 09:49:50 +01:00
# spice-qemu-char.c
trace-events: spelling fix Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20161212221759.28949-1-marcandre.lureau@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-12-12 23:17:59 +01:00
spice_vmc_write(ssize_t out, int len) "spice wrote %zd of requested %d"
trace: enable all events Given that all events with programmatically-controlled state are disabled by default, we can delete the "disable" property from all events. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
2011-08-31 20:31:58 +02:00
spice_vmc_read(int bytes, int len) "spice read %d of requested %d"
spice_vmc_register_interface(void *scd) "spice vmc registered interface %p"
spice_vmc_unregister_interface(void *scd) "spice vmc unregistered interface %p"
spice-qemu-char: add spiceport chardev Add a new spice chardev to allow arbitrary communication between the host and the Spice client via the spice server. Examples: This allows the Spice client to have a special port for the qemu monitor: ... -chardev spiceport,name=org.qemu.monitor,id=monitorport -mon chardev=monitorport v2: - remove support for chardev to chardev linking - conditionnaly compile with SPICE_SERVER_VERSION Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-12-05 16:15:34 +01:00
spice_vmc_event(int event) "spice vmc event %d"
lm32: interrupt controller model This patch adds the interrupt controller of the lm32. Because the PIC is accessed through special control registers and opcodes, there are callbacks from the lm32 translation code to this model. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
2011-02-17 23:45:07 +01:00
trace-events: Fix comments pointing to source files A few files have been renamed without updating their comment here. A few events have been added in the wrong place. Clean that up. Comments with no space after the '#' look ugly and confuse cleanup-trace-events.pl. Insert a space. scripts/cleanup-trace-events.pl is now happy again. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-id: 1411476811-24251-5-git-send-email-armbru@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-23 14:53:31 +02:00
# xen-hvm.c
trace: enable all events Given that all events with programmatically-controlled state are disabled by default, we can delete the "disable" property from all events. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
2011-08-31 20:31:58 +02:00
xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx, size %#lx"
xen: convert to MemoryListener API Signed-off-by: Avi Kivity <avi@redhat.com>
2011-12-19 11:07:50 +01:00
xen_client_set_memory(uint64_t start_addr, unsigned long size, bool log_dirty) "%#"PRIx64" size %#lx, log_dirty %i"
xen-hvm: Add trace to ioreq Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Don Slutz <dslutz@verizon.com>
2015-04-30 20:27:09 +02:00
handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p read type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
handle_ioreq_write(void *req, uint32_t type, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p write type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p pio dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) "I/O=%p pio read reg data=%#"PRIx64" port=%#"PRIx64" size=%d"
cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) "I/O=%p pio write reg data=%#"PRIx64" port=%#"PRIx64" size=%d"
cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
xen: Introduce the Xen mapcache On IA32 host or IA32 PAE host, at present, generally, we can't create an HVM guest with more than 2G memory, because generally it's almost impossible for Qemu to find a large enough and consecutive virtual address space to map an HVM guest's whole physical address space. The attached patch fixes this issue using dynamic mapping based on little blocks of memory. Each call to qemu_get_ram_ptr makes a call to qemu_map_cache with the lock option, so mapcache will not unmap these ram_ptr. Blocks that do not belong to the RAM, but usually to a device ROM or to a framebuffer, are handled in a separate function. So the whole RAMBlock can be map. Signed-off-by: Jun Nakajima <jun.nakajima@intel.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2010-08-31 17:41:25 +02:00
# xen-mapcache.c
trace: remove trailing double quotes after PRI*64 Now that format strings can end in a PRI*64 macro, remove the workarounds from the trace-events file. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2011-09-13 14:34:36 +02:00
xen_map_cache(uint64_t phys_addr) "want %#"PRIx64
xen_remap_bucket(uint64_t index) "index %#"PRIx64
trace: enable all events Given that all events with programmatically-controlled state are disabled by default, we can delete the "disable" property from all events. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
2011-08-31 20:31:58 +02:00
xen_map_cache_return(void* ptr) "%p"
Introduce qemu_put_ram_ptr This function allows to unlock a ram_ptr give by qemu_get_ram_ptr. After a call to qemu_put_ram_ptr, the pointer may be unmap from QEMU when used with Xen. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2010-09-16 14:57:49 +02:00
trace: trace monitor qmp dispatch/completion Add trace events for handle_qmp_command(), which dispatches qmp commands, and monitor_protocol_emitter(), which produces the reply to a qmp command. Also remove duplicate #include "trace/control.h". Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2011-09-23 09:23:06 +02:00
# monitor.c
handle_qmp_command(void *mon, const char *cmd_name) "mon %p cmd_name \"%s\""
monitor: Simplify event throttling The event throttling state machine is hard to understand. I'm not sure it's entirely correct. Rewrite it in a more straightforward manner: State 1: No event sent recently (less than evconf->rate ns ago) Invariant: evstate->timer is not pending, evstate->qdict is null On event: send event, arm timer, goto state 2 State 2: Event sent recently, no additional event being delayed Invariant: evstate->timer is pending, evstate->qdict is null On event: store it in evstate->qdict, goto state 3 On timer: goto state 1 State 3: Event sent recently, additional event being delayed Invariant: evstate->timer is pending, evstate->qdict is non-null On event: store it in evstate->qdict, goto state 3 On timer: send evstate->qdict, clear evstate->qdict, arm timer, goto state 2 Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1444921716-9511-3-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-10-15 17:08:31 +02:00
monitor_protocol_event_handler(uint32_t event, void *qdict) "event=%d data=%p"
Add rate limiting of RTC_CHANGE, BALLOON_CHANGE & WATCHDOG events Allow certain event types to be rate limited to avoid flooding monitor clients. The monitor_protocol_event() method is changed such that instead of immediately emitting the event to Monitor instances, it will call a new monitor_protocol_event_queue() method. This will check to see if the rate limit for the event has been exceeded, and if so schedule a timer to wakeup at the end of the rate limit period. If further events arrive before the timer fires, the previously queued event will be discarded in favour of the new event. The event will eventually be emitted when the timer fires. This logic is applied to RTC_CHANGE, BALLOON_CHANGE & WATCHDOG events, since the data associated with these events is stateless * monitor.c: Add support for rate limiting * monitor.h: Define monitor_global_init for one-time setup tasks * vl.c: Invoke monitor_global_init * trace-events: Add hooks for monitor event tracing Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Acked-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-06-14 19:12:57 +02:00
monitor_protocol_event_emit(uint32_t event, void *data) "event=%d data=%p"
monitor: Simplify event throttling The event throttling state machine is hard to understand. I'm not sure it's entirely correct. Rewrite it in a more straightforward manner: State 1: No event sent recently (less than evconf->rate ns ago) Invariant: evstate->timer is not pending, evstate->qdict is null On event: send event, arm timer, goto state 2 State 2: Event sent recently, no additional event being delayed Invariant: evstate->timer is pending, evstate->qdict is null On event: store it in evstate->qdict, goto state 3 On timer: goto state 1 State 3: Event sent recently, additional event being delayed Invariant: evstate->timer is pending, evstate->qdict is non-null On event: store it in evstate->qdict, goto state 3 On timer: send evstate->qdict, clear evstate->qdict, arm timer, goto state 2 Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1444921716-9511-3-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-10-15 17:08:31 +02:00
monitor_protocol_event_queue(uint32_t event, void *qdict, uint64_t rate) "event=%d data=%p rate=%" PRId64
hw: add OpenCores 10/100 Mbps Ethernet controller This is OpenCores Ethernet MAC + subset of National Semiconductors DP83838C PHY. OpenCores Ethernet MAC project: http://opencores.org/project,ethmac Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2011-10-16 00:56:45 +02:00
dma-helpers: Add trace events Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2011-11-24 12:15:28 +01:00
# dma-helpers.c
dma-helpers: change interface to byte-based Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-05-23 14:54:05 +02:00
dma_blk_io(void *dbs, void *bs, int64_t offset, bool to_dev) "dbs=%p bs=%p offset=%" PRId64 " to_dev=%d"
dma-helpers: Add trace events Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2011-11-24 12:15:28 +01:00
dma_aio_cancel(void *dbs) "dbs=%p"
dma_complete(void *dbs, int ret, void *cb) "dbs=%p ret=%d cb=%p"
hw: Convert from BlockDriverState to BlockBackend, mostly Device models should access their block backends only through the block-backend.h API. Convert them, and drop direct includes of inappropriate headers. Just four uses of BlockDriverState are left: * The Xen paravirtual block device backend (xen_disk.c) opens images itself when set up via xenbus, bypassing blockdev.c. I figure it should go through qmp_blockdev_add() instead. * Device model "usb-storage" prompts for keys. No other device model does, and this one probably shouldn't do it, either. * ide_issue_trim_cb() uses bdrv_aio_discard() instead of blk_aio_discard() because it fishes its backend out of a BlockAIOCB, which has only the BlockDriverState. * PC87312State has an unused BlockDriverState[] member. The next two commits take care of the latter two. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-10-07 13:59:18 +02:00
dma_blk_cb(void *dbs, int ret) "dbs=%p ret=%d"
dma-helpers: Add trace events Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2011-11-24 12:15:28 +01:00
dma_map_wait(void *dbs) "dbs=%p"
console: add some trace events Signed-off-by: Alon Levy <alevy@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2012-03-11 17:11:26 +01:00
kvm-all: add kvm_ioctl, kvm_vm_ioctl, kvm_vcpu_ioctl tracepoints This patch adds tracepoints at ioctl to kvm. Tracing these ioctl is useful for clarification whether the cause of troubles is qemu or kvm. Signed-off-by: Kazuya Saito <saito.kazuya@jp.fujitsu.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-03-29 05:27:05 +01:00
# kvm-all.c
kvm: fix traces to use %x instead of %d KVM request types are normally defined using hex constants but QEMU traces print decimal values instead, which is not very convenient. This changes the request type format from %d to %x. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-09-04 12:26:25 +02:00
kvm_ioctl(int type, void *arg) "type 0x%x, arg %p"
kvm_vm_ioctl(int type, void *arg) "type 0x%x, arg %p"
kvm_vcpu_ioctl(int cpu_index, int type, void *arg) "cpu_index %d, type 0x%x, arg %p"
kvm-all: add kvm_run_exit tracepoint This patch enable us to know exit reason of KVM_RUN. It will help us know where the trouble is caused. Signed-off-by: Kazuya Saito <saito.kazuya@jp.fujitsu.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-03-29 05:27:52 +01:00
kvm_run_exit(int cpu_index, uint32_t reason) "cpu_index %d, reason %d"
kvm: Common device control API functions Introduces two simple functions: int kvm_device_ioctl(int fd, int type, ...); int kvm_create_device(KVMState *s, uint64_t type, bool test); These functions wrap the basic ioctl-based interactions with KVM in a way similar to other KVM ioctl wrappers. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Message-id: 1392687720-26806-4-git-send-email-christoffer.dall@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2014-02-26 18:20:00 +01:00
kvm_device_ioctl(int fd, int type, void *arg) "dev fd %d, type 0x%x, arg %p"
kvm: make one_reg helpers available for everyone s390x introduced helper functions for getting/setting one_regs with commit 860643bc. However, nothing about these is s390-specific. Alexey Kardashevskiy had already posted a general version, so let's merge the two patches and massage the code a bit. CC: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-05-09 10:06:46 +02:00
kvm_failed_reg_get(uint64_t id, const char *msg) "Warning: Unable to retrieve ONEREG %" PRIu64 " from KVM: %s"
kvm_failed_reg_set(uint64_t id, const char *msg) "Warning: Unable to set ONEREG %" PRIu64 " to KVM: %s"
kvm-all: add trace events for kvm irqchip ops These will help us monitoring irqchip route activities more easily. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-14 07:56:35 +02:00
kvm_irqchip_commit_routes(void) ""
kvm_irqchip_add_msi_route(int virq) "Adding MSI route virq=%d"
kvm_irqchip_update_msi_route(int virq) "Updating MSI route virq=%d"
kvm-all: add kvm_run_exit tracepoint This patch enable us to know exit reason of KVM_RUN. It will help us know where the trouble is caused. Signed-off-by: Kazuya Saito <saito.kazuya@jp.fujitsu.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-03-29 05:27:52 +01:00
trace: add some tcg tracing support This adds a couple of tcg specific trace-events which are useful for tracing execution though tcg generated blocks. It's been tested with lttng user space tracing but is generic enough for all systems. The tcg events are: * translate_block - when a subject block is translated * exec_tb - when a translated block is entered * exec_tb_exit - when we exit the translated code * exec_tb_nocache - special case translations Of course we can only trace the entrance to the first block of a chain as each block will jump directly to the next when it can. See the -d nochain patch to allow more complete tracing at the expense of performance. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-08-01 18:08:57 +02:00
# TCG related tracing (mostly disabled by default)
# cpu-exec.c
disable exec_tb(void *tb, uintptr_t pc) "tb:%p pc=0x%"PRIxPTR
disable exec_tb_nocache(void *tb, uintptr_t pc) "tb:%p pc=0x%"PRIxPTR
tcg: Clean up from 'next_tb' The value returned from tcg_qemu_tb_exec() is the value passed to the corresponding tcg_gen_exit_tb() at translation time of the last TB attempted to execute. It is a little confusing to store it in a variable named 'next_tb'. In fact, it is a combination of 4-byte aligned pointer and additional information in its two least significant bits. Break it down right away into two variables named 'last_tb' and 'tb_exit' which are a pointer to the last TB attempted to execute and the TB exit reason, correspondingly. This simplifies the code and improves its readability. Correct a misleading documentation comment for tcg_qemu_tb_exec() and fix logging in cpu_tb_exec(). Also rename a misleading 'next_tb' in another couple of places. Signed-off-by: Sergey Fedorov <serge.fdrv@gmail.com> Signed-off-by: Sergey Fedorov <sergey.fedorov@linaro.org> Signed-off-by: Richard Henderson <rth@twiddle.net>
2016-04-21 14:58:23 +02:00
disable exec_tb_exit(void *last_tb, unsigned int flags) "tb:%p flags=%x"
trace: add some tcg tracing support This adds a couple of tcg specific trace-events which are useful for tracing execution though tcg generated blocks. It's been tested with lttng user space tracing but is generic enough for all systems. The tcg events are: * translate_block - when a subject block is translated * exec_tb - when a translated block is entered * exec_tb_exit - when we exit the translated code * exec_tb_nocache - special case translations Of course we can only trace the entrance to the first block of a chain as each block will jump directly to the next when it can. See the -d nochain patch to allow more complete tracing at the expense of performance. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-08-01 18:08:57 +02:00
# translate-all.c
translate_block(void *tb, uintptr_t pc, uint8_t *tb_code) "tb:%p, pc:0x%"PRIxPTR", tb_code:%p"
memory: add tracepoints for MMIO reads/writes This is quite handy to debug softmmu targets. Reviewed-by: Andreas Faerber <afaerber@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 1375016242-32651-1-git-send-email-pbonzini@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-28 14:57:22 +02:00
# memory.c
trace: include CPU index in trace_memory_region_*() Knowing which CPU performed an action is essential for understanding SMP guest behavior. However, cpu_physical_memory_rw() may be executed by a machine init function, before any VCPUs are running, when there is no CPU running ('current_cpu' is NULL). In this case, store -1 in the trace record as the CPU index. Trace analysis tools may need to be aware of this special case. Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> Message-id: 1456949575-1633-1-git-send-email-hollis_blanchard@mentor.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-03-02 21:12:54 +01:00
memory_region_ops_read(int cpu_index, void *mr, uint64_t addr, uint64_t value, unsigned size) "cpu %d mr %p addr %#"PRIx64" value %#"PRIx64" size %u"
memory_region_ops_write(int cpu_index, void *mr, uint64_t addr, uint64_t value, unsigned size) "cpu %d mr %p addr %#"PRIx64" value %#"PRIx64" size %u"
memory_region_subpage_read(int cpu_index, void *mr, uint64_t offset, uint64_t value, unsigned size) "cpu %d mr %p offset %#"PRIx64" value %#"PRIx64" size %u"
memory_region_subpage_write(int cpu_index, void *mr, uint64_t offset, uint64_t value, unsigned size) "cpu %d mr %p offset %#"PRIx64" value %#"PRIx64" size %u"
trace: separate MMIO tracepoints from TB-access tracepoints Memory accesses to code which has previously been translated into a TB show up in the MMIO path, so that they may invalidate the TB. It's extremely confusing to mix those in with device MMIOs, so split them into their own tracepoint. Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1456949575-1633-2-git-send-email-hollis_blanchard@mentor.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-03-02 21:12:55 +01:00
memory_region_tb_read(int cpu_index, uint64_t addr, uint64_t value, unsigned size) "cpu %d addr %#"PRIx64" value %#"PRIx64" size %u"
memory_region_tb_write(int cpu_index, uint64_t addr, uint64_t value, unsigned size) "cpu %d addr %#"PRIx64" value %#"PRIx64" size %u"
memory: Don't use memcpy for ram_device regions With a vfio assigned device we lay down a base MemoryRegion registered as an IO region, giving us read & write accessors. If the region supports mmap, we lay down a higher priority sub-region MemoryRegion on top of the base layer initialized as a RAM device pointer to the mmap. Finally, if we have any quirks for the device (ie. address ranges that need additional virtualization support), we put another IO sub-region on top of the mmap MemoryRegion. When this is flattened, we now potentially have sub-page mmap MemoryRegions exposed which cannot be directly mapped through KVM. This is as expected, but a subtle detail of this is that we end up with two different access mechanisms through QEMU. If we disable the mmap MemoryRegion, we make use of the IO MemoryRegion and service accesses using pread and pwrite to the vfio device file descriptor. If the mmap MemoryRegion is enabled and results in one of these sub-page gaps, QEMU handles the access as RAM, using memcpy to the mmap. Using either pread/pwrite or the mmap directly should be correct, but using memcpy causes us problems. I expect that not only does memcpy not necessarily honor the original width and alignment in performing a copy, but it potentially also uses processor instructions not intended for MMIO spaces. It turns out that this has been a problem for Realtek NIC assignment, which has such a quirk that creates a sub-page mmap MemoryRegion access. To resolve this, we disable memory_access_is_direct() for ram_device regions since QEMU assumes that it can use memcpy for those regions. Instead we access through MemoryRegionOps, which replaces the memcpy with simple de-references of standard sizes to the host memory. With this patch we attempt to provide unrestricted access to the RAM device, allowing byte through qword access as well as unaligned access. The assumption here is that accesses initiated by the VM are driven by a device specific driver, which knows the device capabilities. If unaligned accesses are not supported by the device, we don't want them to work in a VM by performing multiple aligned accesses to compose the unaligned access. A down-side of this philosophy is that the xp command from the monitor attempts to use the largest available access weidth, unaware of the underlying device. Using memcpy had this same restriction, but at least now an operator can dump individual registers, even if blocks of device memory may result in access widths beyond the capabilities of a given device (RTL NICs only support up to dword). Reported-by: Thorsten Kohfeldt <thorsten.kohfeldt@gmx.de> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
2016-10-31 16:53:03 +01:00
memory_region_ram_device_read(int cpu_index, void *mr, uint64_t addr, uint64_t value, unsigned size) "cpu %d mr %p addr %#"PRIx64" value %#"PRIx64" size %u"
memory_region_ram_device_write(int cpu_index, void *mr, uint64_t addr, uint64_t value, unsigned size) "cpu %d mr %p addr %#"PRIx64" value %#"PRIx64" size %u"
memory: add tracepoints for MMIO reads/writes This is quite handy to debug softmmu targets. Reviewed-by: Andreas Faerber <afaerber@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 1375016242-32651-1-git-send-email-pbonzini@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-28 14:57:22 +02:00
trace: [all] Add "guest_mem_before" event The event is described in "trace-events". Note that the "MO_AMASK" flag is not traced, since it does not seem to affect the visible semantics of instructions. [s/inline inline/inline/ to fix clang build. --Stefan] Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 146549350711.18437.726780393247474362.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-06-09 19:31:47 +02:00
### Guest events, keep at bottom
trace: Add event "guest_cpu_enter" Signals the hot-plugging of a new virtual (guest) CPU. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147428971313.15111.18023030883528426840.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-19 14:55:13 +02:00
## vCPU
# Hot-plug a new virtual (guest) CPU
#
trace: Add missing execution mode of guest events Add missing execution mode documentation for the 'guest_cpu_enter' and 'guest_cpu_reset' events. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147566900921.7708.656450813307396468.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-05 14:03:29 +02:00
# Mode: user, softmmu
trace: Add event "guest_cpu_enter" Signals the hot-plugging of a new virtual (guest) CPU. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147428971313.15111.18023030883528426840.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-19 14:55:13 +02:00
# Targets: all
vcpu guest_cpu_enter(void)
trace: Add event "guest_cpu_exit" Signals the hot-unplugging of a virtual (guest) CPU. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 148278748597.1404.10546320797997984932.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-12-26 22:24:46 +01:00
# Hot-unplug a virtual (guest) CPU
#
# Mode: user, softmmu
# Targets: all
vcpu guest_cpu_exit(void)
trace: Add event "guest_cpu_reset" Signals the reset of the state a virtual (guest) CPU. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147428971851.15111.8799439252178273840.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-19 14:55:18 +02:00
# Reset the state of a virtual (guest) CPU
#
trace: Add missing execution mode of guest events Add missing execution mode documentation for the 'guest_cpu_enter' and 'guest_cpu_reset' events. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147566900921.7708.656450813307396468.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-10-05 14:03:29 +02:00
# Mode: user, softmmu
trace: Add event "guest_cpu_reset" Signals the reset of the state a virtual (guest) CPU. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147428971851.15111.8799439252178273840.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-19 14:55:18 +02:00
# Targets: all
vcpu guest_cpu_reset(void)
trace: [all] Add "guest_mem_before" event The event is described in "trace-events". Note that the "MO_AMASK" flag is not traced, since it does not seem to affect the visible semantics of instructions. [s/inline inline/inline/ to fix clang build. --Stefan] Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 146549350711.18437.726780393247474362.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-06-09 19:31:47 +02:00
# @vaddr: Access' virtual address.
# @info : Access' information (see below).
#
# Start virtual memory access (before any potential access violation).
#
# Does not include memory accesses performed by devices.
#
# Access information can be parsed as:
#
# struct mem_info {
# uint8_t size_shift : 2; /* interpreted as "1 << size_shift" bytes */
# bool sign_extend: 1; /* sign-extended */
# uint8_t endianness : 1; /* 0: little, 1: big */
# bool store : 1; /* wheter it's a store operation */
# };
#
trace: Document the execution mode of guest events Explicitly state in which execution mode (user, softmmu, all) are guest events available for tracing. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147456962135.11114.6146034359114598596.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-22 20:40:21 +02:00
# Mode: user, softmmu
trace: [all] Add "guest_mem_before" event The event is described in "trace-events". Note that the "MO_AMASK" flag is not traced, since it does not seem to affect the visible semantics of instructions. [s/inline inline/inline/ to fix clang build. --Stefan] Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 146549350711.18437.726780393247474362.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-06-09 19:31:47 +02:00
# Targets: TCG(all)
disable vcpu tcg guest_mem_before(TCGv vaddr, uint8_t info) "info=%d", "vaddr=0x%016"PRIx64" info=%d"
trace: [*-user] Add events to trace guest syscalls in syscall emulation mode Adds two events to trace syscalls in syscall emulation mode (*-user): * guest_user_syscall: Emitted before the syscall is emulated; contains the syscall number and arguments. * guest_user_syscall_ret: Emitted after the syscall is emulated; contains the syscall number and return value. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 146651712411.12388.10024905980452504938.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-06-21 15:52:04 +02:00
# @num: System call number.
# @arg*: System call argument value.
#
# Start executing a guest system call in syscall emulation mode.
#
trace: Document the execution mode of guest events Explicitly state in which execution mode (user, softmmu, all) are guest events available for tracing. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147456962135.11114.6146034359114598596.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-22 20:40:21 +02:00
# Mode: user
trace: [*-user] Add events to trace guest syscalls in syscall emulation mode Adds two events to trace syscalls in syscall emulation mode (*-user): * guest_user_syscall: Emitted before the syscall is emulated; contains the syscall number and arguments. * guest_user_syscall_ret: Emitted after the syscall is emulated; contains the syscall number and return value. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 146651712411.12388.10024905980452504938.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-06-21 15:52:04 +02:00
# Targets: TCG(all)
disable vcpu guest_user_syscall(uint64_t num, uint64_t arg1, uint64_t arg2, uint64_t arg3, uint64_t arg4, uint64_t arg5, uint64_t arg6, uint64_t arg7, uint64_t arg8) "num=0x%016"PRIx64" arg1=0x%016"PRIx64" arg2=0x%016"PRIx64" arg3=0x%016"PRIx64" arg4=0x%016"PRIx64" arg5=0x%016"PRIx64" arg6=0x%016"PRIx64" arg7=0x%016"PRIx64" arg8=0x%016"PRIx64
# @num: System call number.
# @ret: System call result value.
#
# Finish executing a guest system call in syscall emulation mode.
#
trace: Document the execution mode of guest events Explicitly state in which execution mode (user, softmmu, all) are guest events available for tracing. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 147456962135.11114.6146034359114598596.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-09-22 20:40:21 +02:00
# Mode: user
trace: [*-user] Add events to trace guest syscalls in syscall emulation mode Adds two events to trace syscalls in syscall emulation mode (*-user): * guest_user_syscall: Emitted before the syscall is emulated; contains the syscall number and arguments. * guest_user_syscall_ret: Emitted after the syscall is emulated; contains the syscall number and return value. Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu> Message-id: 146651712411.12388.10024905980452504938.stgit@fimbulvetr.bsc.es Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-06-21 15:52:04 +02:00
# Targets: TCG(all)
disable vcpu guest_user_syscall_ret(uint64_t num, uint64_t ret) "num=0x%016"PRIx64" ret=0x%016"PRIx64
Reference in New Issue Copy Permalink