Use the new object_initialize_child() and sysbus_init_child_obj() to
fix the issue.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Suggested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael Clark <mjc@sifive.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Use the new object_initialize_child() and sysbus_init_child_obj() to
fix the issue.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Suggested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael Clark <mjc@sifive.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Use the new object_initialize_child() and sysbus_init_child_obj() to
fix the issue.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Suggested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael Clark <mjc@sifive.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
The '-trace' and '--trace' spellings are only both supported in qemu
binary, while for qemu-nbd or qemu-img only '--trace' spelling is
supported. So for the consistency of trace option invocation, we
should use double-dash spelling in our documentation.
This's also mentioned in
https://wiki.qemu.org/BiteSizedTasks#Consistent_option_usage_in_documentation
.
Signed-off-by: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1530674247-31200-1-git-send-email-baiyaowei@cmss.chinamobile.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Throttle groups consist of members sharing one throttling state
(including bps/iops limits). Round-robin scheduling is used to ensure
fairness. If a group member already has a timer pending then other
groups members do not schedule their own timers. The next group member
will have its turn when the existing timer expires.
A hang may occur when a group member leaves while it had a timer
scheduled. Although the code carefully removes the group member from
the round-robin list, it does not schedule the next member. Therefore
remaining members continue to wait for the removed member's timer to
expire.
This patch schedules the next request if a timer is pending.
Unfortunately the actual bug is a race condition that I've been unable
to capture in a test case.
Sometimes drive2 hangs when drive1 is removed from the throttling group:
$ qemu ... -drive if=none,id=drive1,cache=none,format=qcow2,file=data1.qcow2,iops=100,group=foo \
-device virtio-blk-pci,id=virtio-blk-pci0,drive=drive1 \
-drive if=none,id=drive2,cache=none,format=qcow2,file=data2.qcow2,iops=10,group=foo \
-device virtio-blk-pci,id=virtio-blk-pci1,drive=drive2
(guest-console1)# fio -filename /dev/vda 4k-seq-read.job
(guest-console2)# fio -filename /dev/vdb 4k-seq-read.job
(qmp) {"execute": "block_set_io_throttle", "arguments": {"device": "drive1","bps": 0,"bps_rd": 0,"bps_wr": 0,"iops": 0,"iops_rd": 0,"iops_wr": 0}}
Reported-by: Nini Gu <ngu@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20180704145410.794-1-stefanha@redhat.com
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1535914
Cc: Alberto Garcia <berto@igalia.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Usually, when baselining two CPU models, whereby one of them has base
CPU features disabled (e.g. z14-base,msa=off), we fallback to an older
model that did not have these features in the base model. We always try to
create a "sane" CPU model (as far as possible), and one part of it is that
removing base features is no good and to be avoided.
Now, if we disable base features that were part of a z900, we're out of
luck. We won't find a CPU model and QEMU will segfault. This is a
scenario that should never happen in real life, but it can be used to
crash QEMU.
So let's properly report an error if we baseline e.g.:
{ "execute": "query-cpu-model-baseline",
"arguments" : { "modela": { "name": "z14-base", "props": {"esan3" : false}},
"modelb": { "name": "z14"}} }
Instead of segfaulting.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20180718092330.19465-1-david@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
QEMU options have a single dash (but also work as double dash for
convenience and compatibility). Most options are listed with single
dash in command line help but some were listed with two dashes.
Normalize these to have the same format as the others.
Left --preconfig as that is mentioned as double dash everywhere so I
assume that is the preferred form for that.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Acked-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20180716193312.A5BA17456B9@zero.eik.bme.hu>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
No callers of get_opt_value() pass in a NULL for the "value" parameter,
so the check is redundant.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180514171913.17664-4-berrange@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Tested-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The multiboot code parses the initrd_filename twice, first to count how
many entries there are, and second to process each entry. This changes
the first loop to store the parse module names in a list, and the second
loop can now use these names. This avoids having to pass NULL to the
get_opt_value() method which means it can safely assume a non-NULL param.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180514171913.17664-3-berrange@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Tested-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The logic for parsing the multiboot initrd modules was messed up in
commit 950c4e6c94
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Mon Apr 16 12:17:43 2018 +0100
opts: don't silently truncate long option values
Causing the length to be undercounter, and the number of modules over
counted. It also passes NULL to get_opt_value() which was not robust
at accepting a NULL value.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180514171913.17664-2-berrange@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Tested-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
QEMU currently crashes when e.g. doing something like this:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'xlnx,zynqmp'}}" \
"{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" \
| aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
Use the new object_initialize_child() and sysbus_init_child_obj()
functions to get the refernce counting of the child objects right, so
that they are properly cleaned up when the parent gets destroyed.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-18-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
aux_create_slave() calls qdev_init_nofail() which in turn "realizes"
the corresponding object. This is unlike qdev_create(), and it is wrong
because qdev_init_nofail() must not be called from an instance_init
function. Move qdev_init_nofail() and the subsequent aux_map_slave into
the caller's realize function.
There are two more bugs that needs to be fixed here, too, where the
objects are created but not added as children. Therefore when
you call object_unparent on them, nothing happens.
In particular dpcd and edid give you an infinite loop in bus_unparent,
because device_unparent is not called and does not remove them from
the list of devices on the bus.
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-17-git-send-email-thuth@redhat.com
[thuth: Added Paolo's fixup for the dpcd and edid unparenting]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Running QEMU with valgrind indicates a problem here:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'fsl,imx31'}}" \
"{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==26172== Invalid read of size 8
==26172== at 0x6191FA: qdev_print (qdev-monitor.c:686)
==26172== by 0x6191FA: qbus_print (qdev-monitor.c:719)
[...]
Use the new sysbus_init_child_obj() to make sure that the objects are
cleaned up correctly when the parent gets destroyed.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-12-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Running QEMU with valgrind indicates a problem here:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'fsl,imx25'}}" \
"{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==26724== Invalid read of size 8
==26724== at 0x6190DA: qdev_print (qdev-monitor.c:686)
==26724== by 0x6190DA: qbus_print (qdev-monitor.c:719)
[...]
Use the new sysbus_init_child_obj() to make sure that the objects are
cleaned up correctly when the parent gets destroyed.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-11-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Running QEMU with valgrind indicates a problem here:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'fsl,imx7'}}" \
"{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==27284== Invalid read of size 8
==27284== at 0x618F7A: qdev_print (qdev-monitor.c:686)
==27284== by 0x618F7A: qbus_print (qdev-monitor.c:719)
==27284== by 0x452B38: handle_hmp_command (monitor.c:3446)
[...]
Use the new sysbus_init_child_obj() and object_initialize_child() to make
sure that the objects are removed correctly when the parent gets destroyed.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-10-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Running QEMU with valgrind indicates a problem here:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'fsl,imx6'}}" \
"{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==32417== Invalid read of size 8
==32417== at 0x618A7A: qdev_print (qdev-monitor.c:686)
==32417== by 0x618A7A: qbus_print (qdev-monitor.c:719)
==32417== by 0x452B38: handle_hmp_command (monitor.c:3446)
[...]
Use the new sysbus_init_child_obj() and object_initialize_child() to make
sure that the objects are removed correctly when the parent gets destroyed.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-9-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Running QEMU with valgrind indicates a problem here:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'a9mpcore_priv'}}" \
"{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==30996== Invalid read of size 8
==30996== at 0x6185DA: qdev_print (qdev-monitor.c:686)
==30996== by 0x6185DA: qbus_print (qdev-monitor.c:719)
==30996== by 0x452B38: handle_hmp_command (monitor.c:3446)
[...]
Use the new sysbus_init_child_obj() function to make sure that the objects
are cleaned up correctly when the parent gets destroyed.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-8-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Valgrind currently reports a problem when running QEMU like this:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'msf2-soc'}}" \
"{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==23097== Invalid read of size 8
==23097== at 0x6192AA: qdev_print (qdev-monitor.c:686)
==23097== by 0x6192AA: qbus_print (qdev-monitor.c:719)
[...]
Use the new sysbus_init_child_obj() function to make sure that the child
objects are cleaned up correctly when the parent gets destroyed.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-7-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
There is a memory management problem when introspecting the a15mpcore_priv
device. It can be seen with valgrind when running QEMU like this:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'a15mpcore_priv'}}"\
"{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
"package": "build-all"}, "capabilities": []}}
{"return": {}}
{"return": [{"name": "num-cpu", "type": "uint32"}, {"name": "num-irq",
"type": "uint32"}, {"name": "a15mp-priv-container[0]", "type":
"child<qemu:memory-region>"}]}
==24978== Invalid read of size 8
==24978== at 0x618EBA: qdev_print (qdev-monitor.c:686)
==24978== by 0x618EBA: qbus_print (qdev-monitor.c:719)
[...]
Use the new sysbus_init_child_obj() function to make sure that we get
the reference counting of the child objects right.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-6-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
QEMU currently crashes when introspecting the "iotkit" device and
runnint "info qtree" afterwards, e.g. when running QEMU like this:
echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
"'arguments':{'typename':'iotkit'}}" "{'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
Use the new functions object_initialize_child() and sysbus_init_child_obj()
to make sure that all objects get cleaned up correctly when the instances
are destroyed.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-5-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When trying to "device_add bcm2837" on a machine that is not suitable for
this device, you can quickly crash QEMU afterwards, e.g. with "info qtree":
echo "{'execute':'qmp_capabilities'} {'execute':'device_add', " \
"'arguments':{'driver':'bcm2837'}} {'execute': 'human-monitor-command', " \
"'arguments': {'command-line': 'info qtree'}}" | \
aarch64-softmmu/qemu-system-aarch64 -M integratorcp,accel=qtest -S -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
"package": "build-all"}, "capabilities": []}}
{"return": {}}
{"error": {"class": "GenericError", "desc": "Device 'bcm2837' can not be
hotplugged on this machine"}}
Segmentation fault (core dumped)
The qdev_set_parent_bus() from instance_init adds a link to the child devices
which is not valid anymore after the bcm2837 instance has been destroyed.
Unfortunately, the child devices do not get destroyed / unlinked correctly
because both object_initialize() and object_property_add_child() increase
the reference count of the child objects by one, but only one reference
is dropped when the parent gets removed. So let's use the new functions
object_initialize_child() and sysbus_init_child_obj() instead to create
the objects, which will take care of creating the child objects with the
correct reference count of one.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-4-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A lot of functions are initializing an object and attach it immediately
afterwards to the system bus. Provide a common function for this, which
also uses object_initialize_child() to make sure that the reference
counter is correctly initialized to 1 afterwards.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-3-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A lot of code is using the object_initialize() function followed by a call
to object_property_add_child() to add the newly initialized object as a child
of the current object. Both functions increase the reference counter of the
new object, but many spots that call these two functions then forget to drop
one of the superfluous references. So the newly created object is often not
cleaned up correctly when the parent is destroyed. In the worst case, this
can cause crashes, e.g. because device objects are not correctly removed from
their parent_bus.
Since this is a common pattern between many code spots, let's introduce a
new function that takes care of calling all three required initialization
functions, first object_initialize(), then object_property_add_child() and
finally object_unref(). And since the function does a similar job like
object_new_with_props(), also allow to set additional properties via
varargs, and use user_creatable_complete() to make sure that the functions
can be used similarly.
And while we're at object.h, also fix some copy-n-paste errors in the
comments there ("to store the area" --> "to store the error").
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-id: 1531745974-17187-2-git-send-email-thuth@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The file descriptor for /sys/power/state was never closed. Reported
by Coverity.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
'driver' is leaked when the loop is not broken.
Leak introduced by commit 743c71d03c,
spotted by ASAN.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
* accel/tcg: Use correct test when looking in victim TLB for code
* bcm2835_aux: Swap RX and TX interrupt assignments
* hw/arm/bcm2836: Mark the bcm2836 / bcm2837 devices with user_creatable = false
* hw/intc/arm_gic: Fix handling of GICD_ITARGETSR
* hw/intc/arm_gic: Check interrupt number in gic_deactivate_irq()
* aspeed: Implement write-1-{set, clear} for AST2500 strapping
* target/arm: Fix LD1W and LDFF1W (scalar plus vector)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJbTMoMAAoJEDwlJe0UNgzeuUcQAIN8zicyj69ef1Ax0wNvLKFQ
LYuLNkTuO8OHYGt/BlvsRJzZVMuESwQzc9Hx62+zhALLgNOwK4kBwthw5HDRzNFH
XTaOj1uHejjFas2AT6PiIZqvupOJyX8ns7aQJL+OHyR0JrTVg7Ig4itWw3ePpIl2
mga8JUBf3Mxf7i1DpWDmtWs++CaXQg7fDjSDziAdeO5qyu17TLv+twyoFhynlhe1
q9EKm/Qmei09DnYizFrj525E7fEDfT3y9tv/QadO0vOwPdxAs1MQLs6ypEGTK5wR
mkJnfTIls/Q6Pl6JebezmkGJ6r30A7IPDwwg2vaEAbB7DM0spkF7LZJrynu8IwLF
XACcYfJbbFFUgdDFKce9BTkS9FyC99erot7F5OlqgCFhr4+A69MEKLxQSiQMqeo3
Q4JzO1aqqWyxkx8xJDJun98P7XcNefwnFizhr3NQm6UWs2miB+E03LiQumYA4ra0
Y5mqDm1LgBquDnS50sbA45oBpjLRmR/29LIKz5WYG5J7FclrnxFFhzWqt2kdoMJN
QmOMzlzS4Z55Jym4CdNs7ZCRroL6vELXQwjXOVOjp2fdPcGl295v7dOFPqj1V0eB
7CQZmxGUV2OzLOsBSHiUq6t1snXzmNVd269sL7vUkdcO0od27cIJbrGDToSb4OnA
3zk5U0r/mF+kfd7AU55x
=eKFb
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180716' into staging
target-arm queue:
* accel/tcg: Use correct test when looking in victim TLB for code
* bcm2835_aux: Swap RX and TX interrupt assignments
* hw/arm/bcm2836: Mark the bcm2836 / bcm2837 devices with user_creatable = false
* hw/intc/arm_gic: Fix handling of GICD_ITARGETSR
* hw/intc/arm_gic: Check interrupt number in gic_deactivate_irq()
* aspeed: Implement write-1-{set, clear} for AST2500 strapping
* target/arm: Fix LD1W and LDFF1W (scalar plus vector)
# gpg: Signature made Mon 16 Jul 2018 17:38:36 BST
# gpg: using RSA key 3C2525ED14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
# gpg: aka "Peter Maydell <pmaydell@gmail.com>"
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>"
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20180716:
accel/tcg: Assert that tlb fill gave us a valid TLB entry
accel/tcg: Use correct test when looking in victim TLB for code
bcm2835_aux: Swap RX and TX interrupt assignments
hw/arm/bcm2836: Mark the bcm2836 / bcm2837 devices with user_creatable = false
hw/intc/arm_gic: Fix handling of GICD_ITARGETSR
hw/intc/arm_gic: Check interrupt number in gic_deactivate_irq()
aspeed: Implement write-1-{set, clear} for AST2500 strapping
target/arm: Fix LD1W and LDFF1W (scalar plus vector)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In commit 4b1a3e1e34 we added a check for whether the TLB entry
we had following a tlb_fill had the INVALID bit set. This could
happen in some circumstances because a stale or wrong TLB entry was
pulled out of the victim cache. However, after commit
68fea03855 (which prevents stale entries being in the victim
cache) and the previous commit (which ensures we don't incorrectly
hit in the victim cache)) this should never be possible.
Drop the check on TLB_INVALID_MASK from the "is this a TLB_RECHECK?"
condition, and instead assert that the tlb fill procedure has given
us a valid TLB entry (or longjumped out with a guest exception).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180713141636.18665-3-peter.maydell@linaro.org
In get_page_addr_code(), we were incorrectly looking in the victim
TLB for an entry which matched the target address for reads, not
for code accesses. This meant that we could hit on a victim TLB
entry that indicated that the address was readable but not
executable, and incorrectly bypass the call to tlb_fill() which
should generate the guest MMU exception. Fix this bug.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180713141636.18665-2-peter.maydell@linaro.org
RX and TX interrupt bits were reversed, resulting in an endless sequence
of serial interupts in the emulated system and the following repeated
error message when booting Linux.
serial8250: too much work for irq61
This results in a boot failure most of the time.
Qemu command line used to reproduce the problem:
qemu-system-aarch64 -M raspi3 -m 1024 \
-kernel arch/arm64/boot/Image \
--append "rdinit=/sbin/init console=ttyS1,115200"
-initrd rootfs.cpio \
-dtb arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb \
-nographic -monitor null -serial null -serial stdio
This is with arm64:defconfig. The root file system was generated using
buildroot.
NB that this error likely arises from an erratum in the
BCM2835 datasheet where the TX and RX bits were swapped
in the AU_MU_IER_REG description (but correct for IIR):
https://elinux.org/BCM2835_datasheet_errata#p12
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Message-id: 1529355846-25102-1-git-send-email-linux@roeck-us.net
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: added NB about datasheet]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
These devices are currently causing some problems when a user is trying
to hot-plug or introspect them during runtime. Since these devices can
not be instantiated by the user at all (they need to be wired up in code
instead), we should mark them with user_creatable = false anyway, then we
avoid at least the crashes with the hot-plugging. The introspection problem
will be handled by a separate patch.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1531415537-26037-1-git-send-email-thuth@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The GICD_ITARGETSR implementation still has some 11MPCore behaviour
that we were incorrectly using in our GICv1 and GICv2 implementations
for the case where the interrupt number is less than GIC_INTERNAL.
The desired behaviour here is:
* for 11MPCore: RAZ/WI for irqs 0..28; read a number matching the
CPU doing the read for irqs 29..31
* for GICv1 and v2: RAZ/WI if uniprocessor; otherwise read a
number matching the CPU doing the read for all irqs < 32
Stop squashing GICD_ITARGETSR to 0 for IRQs 0..28 unless this
is an 11MPCore GIC.
Reported-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20180712154152.32183-3-peter.maydell@linaro.org
In gic_deactivate_irq() the interrupt number comes from the guest
(on a write to the GICC_DIR register), so we need to sanity check
that it isn't out of range before we use it as an array index.
Handle this in a similar manner to the check we do in
gic_complete_irq() for the GICC_EOI register.
The array overrun is not disastrous because the calling code
uses (value & 0x3ff) to extract the interrupt field, so the
only out-of-range values possible are 1020..1023, which allow
overrunning only from irq_state[] into the following
irq_target[] array which the guest can already manipulate.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Message-id: 20180712154152.32183-2-peter.maydell@linaro.org
The AST2500 SoC family changes the runtime behaviour of the hardware
strapping register (SCU70) to write-1-set/write-1-clear, with
write-1-clear implemented on the "read-only" SoC revision register
(SCU7C). For the the AST2400, the hardware strapping is
runtime-configured with read-modify-write semantics.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-id: 20180709143524.17480-1-andrew@aj.id.au
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
'I' was being double-incremented; correctly within the inner loop
and incorrectly within the outer loop.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180711103957.3040-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
There is a race condition during hotplug when iothread is used. It
occurs because virtio-scsi may be processing command queues in the
iothread while the monitor performs SCSI device hotplug.
When a SCSI device is hotplugged the HotplugHandler->plug() callback is
invoked and virtio-scsi emits a rescan event to the guest.
If the guest submits a SCSI command at this point then it may be
cancelled before hotplug completes. This happens because ->reset() is
called by hw/core/qdev.c:device_set_realized() after
HotplugHandler->plug() has been called and
hw/scsi/scsi-disk.c:scsi_disk_reset() purges all requests.
This patch uses the new HotplugHandler->post_plug() callback to emit the
rescan event after ->reset(). This eliminates the race conditions where
requests could be cancelled.
Reported-by: l00284672 <lizhengui@huawei.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Fam Zheng <famz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20180716083732.3347-3-stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The ->pre_plug() callback is invoked before the device is realized. The
->plug() callback is invoked when the device is being realized but
before it is reset.
This patch adds a ->post_plug() callback which is invoked after the
device has been reset. This callback is needed by HotplugHandlers that
need to wait until after ->reset().
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20180716083732.3347-2-stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This fixes several problems I found in the UART serial implementation.
Now all divisor values are allowed, while before divisor values of zero
and below the base baud rate were rejected. All changes are in reference
to http://www.sci.muni.cz/docs/pc/serport.txt
Signed-off-by: Calvin Lee <cyrus296@gmail.com>
Message-Id: <20180512000545.966-2-cyrus296@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
server->bus in _test_server_free() could be NULL, since TestServer
*dest in test_migrate() was not properly initialized like TestServer *s.
Added init_virtio_dev(dest) and uninit_virtio_dev(dest), so the fields
are properly set and when test_server_free(dest); is called, they can
be correctly freed.
The reason for that is init_virtio_dev() calls qpci_init_pc(), that
creates a QPCIBusPC * (returned as QPCIBus *), while test_server_free()
calls qpci_free_pc(), that frees the QPCIBus *. Not calling
init_virtio_dev() would leave the QPCIBus * of TestServer unset.
Problem came out once I modified pci-pc.c and pci-pc.h, modifying
QPCIBusPC by adding another field before QPCIBus bus. Re-running the
tests showed vhost-user-test failing.
Signed-off-by: Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com>
Message-Id: <1530022733-29581-1-git-send-email-esposem@usi.ch>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hyper-V identifies vCPUs by Virtual Processor (VP) index which can be
queried by the guest via HV_X64_MSR_VP_INDEX msr. It is defined by the
spec as a sequential number which can't exceed the maximum number of
vCPUs per VM.
It has to be owned by QEMU in order to preserve it across migration.
However, the initial implementation in KVM didn't allow to set this
msr, and KVM used its own notion of VP index. Fortunately, the way
vCPUs are created in QEMU/KVM makes it likely that the KVM value is
equal to QEMU cpu_index.
So choose cpu_index as the value for vp_index, and push that to KVM on
kernels that support setting the msr. On older ones that don't, query
the kernel value and assert that it's in sync with QEMU.
Besides, since handling errors from vCPU init at hotplug time is
impossible, disable vCPU hotplug.
This patch also introduces accessor functions to encapsulate the mapping
between a vCPU and its vp_index.
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Message-Id: <20180702134156.13404-3-rkagan@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In Hyper-V-related code, vCPUs are identified by their VP (virtual
processor) index. Since it's customary for "vcpu_id" in QEMU to mean
APIC id, rename the respective variables to "vp_index" to make the
distinction clear.
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Message-Id: <20180702134156.13404-2-rkagan@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
