# By Markus Armbruster
# Via Stefan Hajnoczi
* stefanha/tracing:
trace-events: Fix up source file comments
trace-events: Drop unused events
milkymist-minimac2: Fix minimac2_read/_write tracepoints
slavio_misc: Fix slavio_led_mem_readw/_writew tracepoints
cleanup-trace-events.pl: New
Message-id: 1374119369-26496-1-git-send-email-stefanha@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Simple script to drop unused events and fix up source file comments.
The next few commits put it to use.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
In qmp-marshal.c the dealloc visitor calls use the same errp
pointer of the input visitor calls. This means that if any of
the input visitor calls fails, then the dealloc visitor will
return early, before freeing the object's memory.
Here's an example, consider this code:
int qmp_marshal_input_block_passwd(Monitor *mon, const QDict *qdict, QObject **ret)
{
[...]
char * device = NULL;
char * password = NULL;
mi = qmp_input_visitor_new_strict(QOBJECT(args));
v = qmp_input_get_visitor(mi);
visit_type_str(v, &device, "device", errp);
visit_type_str(v, &password, "password", errp);
qmp_input_visitor_cleanup(mi);
if (error_is_set(errp)) {
goto out;
}
qmp_block_passwd(device, password, errp);
out:
md = qapi_dealloc_visitor_new();
v = qapi_dealloc_get_visitor(md);
visit_type_str(v, &device, "device", errp);
visit_type_str(v, &password, "password", errp);
qapi_dealloc_visitor_cleanup(md);
[...]
return 0;
}
Consider errp != NULL when the out label is reached, we're going
to leak device and password.
This patch fixes this by always passing errp=NULL for dealloc
visitors, meaning that we always try to free them regardless of
any previous failure. The above example would then be:
out:
md = qapi_dealloc_visitor_new();
v = qapi_dealloc_get_visitor(md);
visit_type_str(v, &device, "device", NULL);
visit_type_str(v, &password, "password", NULL);
qapi_dealloc_visitor_cleanup(md);
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
If 'data' for a command definition isn't a dict, but a string, it is
taken as a (struct) type name and the fields of this struct are directly
used as parameters.
This is useful for transactionable commands that can use the same type
definition for both the transaction action and the arguments of the
standalone command.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
The code that interprets the read JSON expression and appends types to
the respective global variables was duplicated. We can avoid that by
splitting off the part that reads from the file.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Everything else needs to match the executable name, which is
TARGET_NAME.
Before:
$ sh4eb-linux-user/qemu-sh4eb --help
usage: qemu-sh4 [options] program [arguments...]
Linux CPU emulator (compiled for sh4 emulation)
After:
$ sh4eb-linux-user/qemu-sh4eb --help
usage: qemu-sh4eb [options] program [arguments...]
Linux CPU emulator (compiled for sh4eb emulation)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1370349928-20419-5-git-send-email-pbonzini@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
TARGET_ARCH is generally wrong to use, there are better variables
provided in config-target.mak. The right one is usually TARGET_NAME
(previously TARGET_ARCH2), but for bsd-user we can also use TARGET_ABI_DIR
for consistency with linux-user.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1370349928-20419-4-git-send-email-pbonzini@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We may want to include a driver in the whitelist for read only tasks
such as diagnosing or exporting guest data (with libguestfs as a good
example). This patch introduces a readonly whitelist option, and for
backward compatibility, the old configure option --block-drv-whitelist
is now an alias to rw whitelist.
Drivers in readonly list is only permitted to open file readonly, and
returns -ENOTSUP for RW opening.
E.g. To include vmdk readonly, and others read+write:
./configure --target-list=x86_64-softmmu \
--block-drv-rw-whitelist=qcow2,raw,file,qed \
--block-drv-ro-whitelist=vmdk
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
With the introduction of native list types, we now have types such as
int64List where the 'value' field is not a pointer, but the actual
64-bit value.
On 32-bit architectures, this can lead to situations where 'next' field
offset in GenericList does not correspond to the 'next' field in the
types that we cast to GenericList when using the visit_next_list()
interface, causing issues when we attempt to traverse linked list
structures of these types.
To fix this, pad the 'value' field of GenericList and other
schema-defined/native *List types out to 64-bits.
This is less memory-efficient for 32-bit architectures, but allows us to
continue to rely on list-handling interfaces that target GenericList to
simply visitor implementations.
In the future we can improve efficiency by defaulting to using native C
array backends to handle list of non-pointer types, which would be more
memory efficient in itself and allow us to roll back this change.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Currently we assume non-list types when generating visitor routines for
union types. This is broken, since values like ['Type'] need to mapped
to 'TypeList'.
We already have a type_name() function to handle this that we use for
generating struct visitors, so use that here as well.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Amos Kong <akong@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
This patch adds a ftrace tracing backend which sends trace event to
ftrace marker file. You can effectively compare qemu trace data and
kernel(especially, kvm.ko when using KVM) trace data.
The ftrace backend is restricted to Linux only.
To try out the ftrace backend:
$ ./configure --trace-backend=ftrace
$ make
if you use KVM, enable kvm events in ftrace:
# sudo echo 1 > /sys/kernel/debug/tracing/events/kvm/enable
After running qemu by root user, you can get the trace:
# cat /sys/kernel/debug/tracing/trace
Signed-off-by: Eiichi Tsukata <eiichi.tsukata.xh@hitachi.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This adds reporting of VMCS shadowing, #VE, IA32_SMBASE, unrestricted
VMWRITE and fixes the range of the MSEG revision ID.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Parse the Basic VMX Information MSR and add the bit for the new posted
interrupts.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Python may otherwise decide to to read larger chunks, applying the seek
only on the software buffer. This will return results from the wrong
MSRs.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Gleb Natapov <gleb@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>
Uses tracetool to generate a backend-independent tracing event description
(struct TraceEvent).
The values for such structure are generated with the non-public "events"
backend ("events-c" frontend).
The generation of the defines to check if an event is statically enabled is also
moved to the "events" backend ("events-h" frontend).
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Public backends are those printed by "--list-backends" and thus considered valid
by the configure script.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Placing the config-devices.mak.d file alongside the config-devices.mak
file in *-softmmu/ lead to it getting included into through
*-softmmu/Makefile in addition to ./Makefile, leading to confusion.
Instead, emit it to ./%-config-devices.mak.d, where it is included.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
This reverts commit 23bf49b5ec.
While *-softmmu/config-devices.mak.d is included through *.d pattern via
Makefile.target, the make_devices_config.sh call these dependencies are
for is in ./Makefile. Therefore revert to original behavior.
This should unbreak pci.mak dependencies not propagating.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Make it handle multiple include statements in a file:
(1) The printf needs a space so the include files will be separated.
(2) Also $f can contain multiple failes, so redirection will not work
and we have to use cat to process all files.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
