| 4725398f | 17-Jun-2014 |
Michael Ellerman <mpe@ellerman.id.au> |
kvm_stat: Add powerpc support
Add support for powerpc platforms. We use uname -m, which allows us to
detect ppc, ppc64 and ppc64le/el.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-of
kvm_stat: Add powerpc support
Add support for powerpc platforms. We use uname -m, which allows us to
detect ppc, ppc64 and ppc64le/el.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| a15d5642 | 17-Jun-2014 |
Michael Ellerman <mpe@ellerman.id.au> |
kvm_stat: Abstract ioctl numbers
Unfortunately ioctl numbers are platform specific, so abstract them out
of the code so they can be overridden. As it happens x86 and s390 share
the same values, so n
kvm_stat: Abstract ioctl numbers
Unfortunately ioctl numbers are platform specific, so abstract them out
of the code so they can be overridden. As it happens x86 and s390 share
the same values, so nothing needs to change yet.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 4d4103ff | 17-Jun-2014 |
Michael Ellerman <mpe@ellerman.id.au> |
kvm_stat: Rework platform detection
The current platform detection is a little bit messy. We look for lines
in /proc/cpuinfo starting with 'flags' OR 'vendor-id', and scan both
for values we know wi
kvm_stat: Rework platform detection
The current platform detection is a little bit messy. We look for lines
in /proc/cpuinfo starting with 'flags' OR 'vendor-id', and scan both
for values we know will only occur in one or the other. We also keep
scanning once we've found a value, which could be a feature, but isn't
in this case.
We'd also like to add another platform, powerpc, which will just make it
worse. So clean it up in preparation.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 27d318a8 | 17-Jun-2014 |
Michael Ellerman <mpe@ellerman.id.au> |
kvm_stat: Fix the non-x86 exit reasons
In kvm_stat we have a dictionary of exit reasons for s390. Firstly these
are not s390 specific, they are the generic exit reasons. So rename the
dictionary to
kvm_stat: Fix the non-x86 exit reasons
In kvm_stat we have a dictionary of exit reasons for s390. Firstly these
are not s390 specific, they are the generic exit reasons. So rename the
dictionary to reflect that, and add it separately to filters[].
Secondly, the values are defined using hex, but in the kernel header
they are decimal. That means values above 9 in kvm_stat are incorrect.
While we're there, fix the whitespace to match the rest of the file.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| c6561586 | 22-Oct-2014 |
Paolo Bonzini <pbonzini@redhat.com> |
get_maintainer.pl: restrict cases where it falls back to --git
The list emitted by --git-fallback often leads inexperienced contributors
to add pointless CCs. While not discouraging usage of --git-
get_maintainer.pl: restrict cases where it falls back to --git
The list emitted by --git-fallback often leads inexperienced contributors
to add pointless CCs. While not discouraging usage of --git-fallback,
we want to:
1) disable the fallback if only some files lack a maintainer
$ scripts/get_maintainer.pl -f util/cutils.c hw/ide/core.c
Kevin Wolf <kwolf@redhat.com> (odd fixer:IDE)
Stefan Hajnoczi <stefanha@redhat.com> (odd fixer:IDE)
This behavior is taken even if --git-fallback is specified.
2) warn the contributors about what we're doing, asking them to use their
common sense:
$ scripts/get_maintainer.pl -f util/cutils.c
get_maintainer.pl: No maintainers found, printing recent contributors.
get_maintainer.pl: Do not blindly cc: them on patches! Use common sense.
Luiz Capitulino <lcapitulino@redhat.com> (commit_signer:1/2=50%)
...
$
Explicitly disabling the fallback will not result in the warning message:
$ scripts/get_maintainer.pl -f util/cutils.c --no-git-fallback
$ echo $?
0
(Returning 1 would break usage of scripts/get_maintainer.pl as a cccmd
for git-send-email).
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| cee2dedb | 18-Sep-2014 |
Michael Roth <mdroth@linux.vnet.ibm.com> |
qapi: add visit_start_union and visit_end_union
In some cases an input visitor might bail out on filling out a
struct for various reasons, such as missing fields when running
in strict mode. In the
qapi: add visit_start_union and visit_end_union
In some cases an input visitor might bail out on filling out a
struct for various reasons, such as missing fields when running
in strict mode. In the case of a QAPI Union type, this may lead
to cases where the .kind field which encodes the union type
is uninitialized. Subsequently, other visitors, such as the
dealloc visitor, may use this .kind value as if it were
initialized, leading to assumptions about the union type which
in this case may lead to segfaults. For example, freeing an
integer value.
However, we can generally rely on the fact that the always-present
.data void * field that we generate for these union types will
always be NULL in cases where .kind is uninitialized (at least,
there shouldn't be a reason where we'd do this purposefully).
So pass this information on to Visitor implementation via these
optional start_union/end_union interfaces so this information
can be used to guard against the situation above. We will make
use of this information in a subsequent patch for the dealloc
visitor.
Cc: qemu-stable@nongnu.org
Reported-by: Fam Zheng <famz@redhat.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
show more ...
|
| 88ed34ff | 23-Sep-2014 |
Markus Armbruster <armbru@redhat.com> |
cleanup-trace-events.pl: Tighten search for trace event call
The script can get fooled too easily. For instance, it finds
trace_megasas_io_read_start when looking for trace_megasas_io_read,
and inc
cleanup-trace-events.pl: Tighten search for trace event call
The script can get fooled too easily. For instance, it finds
trace_megasas_io_read_start when looking for trace_megasas_io_read,
and incorrectly concludes that event megasas_io_read is used.
Supply -w to git-grep to tighten the search.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-id: 1411476811-24251-2-git-send-email-armbru@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
| f9bbba95 | 23-Sep-2014 |
Stefan Hajnoczi <stefanha@redhat.com> |
trace: tighten up trace-events regex to fix bad parse
Use \w for properties and trace event names since they are both drawn
from [a-zA-Z0-9_] character sets.
The .* for matching properties was too
trace: tighten up trace-events regex to fix bad parse
Use \w for properties and trace event names since they are both drawn
from [a-zA-Z0-9_] character sets.
The .* for matching properties was too aggressive and caused the
following failure with foo(int rc) "(this is a test)":
Traceback (most recent call last):
File "scripts/tracetool.py", line 139, in <module>
main(sys.argv)
File "scripts/tracetool.py", line 134, in main
binary=binary, probe_prefix=probe_prefix)
File "scripts/tracetool/__init__.py", line 334, in generate
events = _read_events(fevents)
File "scripts/tracetool/__init__.py", line 262, in _read_events
res.append(Event.build(line))
File "scripts/tracetool/__init__.py", line 225, in build
return Event(name, props, fmt, args, arg_fmts)
File "scripts/tracetool/__init__.py", line 185, in __init__
% ", ".join(unknown_props))
ValueError: Unknown properties: foo(int, rc)
Cc: Lluís Vilanova <vilanova@ac.upc.edu>
Reported-by: Eric Auger <eric.auger@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1411468626-20450-1-git-send-email-stefanha@redhat.com
show more ...
|
| 73735f72 | 27-Aug-2014 |
Stefan Hajnoczi <stefanha@redhat.com> |
trace: avoid Python 2.5 all() in tracetool
Red Hat Enterprise Linux 5 ships Python 2.4.3. The all() function was
added in Python 2.5 so we cannot use it.
Signed-off-by: Stefan Hajnoczi <stefanha@r
trace: avoid Python 2.5 all() in tracetool
Red Hat Enterprise Linux 5 ships Python 2.4.3. The all() function was
added in Python 2.5 so we cannot use it.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Benoît Canet <benoit.canet@nodalink.com>
show more ...
|