Zheng Xiang [Mon, 3 Dec 2018 07:05:17 +0000 (15:05 +0800)]
pcie: set link state inactive/active after hot unplug/plug
When VM boots from the latest version of linux kernel, after
hot-unpluging virtio-blk disks which are hotplugged into
pcie-root-port, the VM's dmesg log shows:
[ 151.046242] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0001 from Slot Status
[ 151.046365] pciehp 0000:00:05.0:pcie004: Slot(0-3): Attention button pressed
[ 151.046369] pciehp 0000:00:05.0:pcie004: Slot(0-3): Powering off due to button press
[ 151.046420] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 151.046425] pciehp 0000:00:05.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 200
[ 151.046464] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 151.046468] pciehp 0000:00:05.0:pcie004: pciehp_set_attention_status: SLOTCTRL a8 write cmd c0
[ 156.163421] pciehp 0000:00:05.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 2f1
[ 156.163427] pciehp 0000:00:05.0:pcie004: pciehp_unconfigure_device: domain:bus:dev = 0000:06:00
[ 156.198736] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 156.198772] pciehp 0000:00:05.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400
[ 157.224124] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0018 from Slot Status
[ 157.224194] pciehp 0000:00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300
[ 157.224220] pciehp 0000:00:05.0:pcie004: pciehp_check_link_active: lnk_status = 2011
[ 157.224223] pciehp 0000:00:05.0:pcie004: Slot(0-3): Link Up
[ 157.224233] pciehp 0000:00:05.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 7f1
[ 157.224281] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 157.224285] pciehp 0000:00:05.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 write cmd 0
[ 157.224300] pciehp 0000:00:05.0:pcie004: __pciehp_link_set: lnk_ctrl = 0
[ 157.224336] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 157.224339] pciehp 0000:00:05.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 200
[ 159.739294] pci 0000:06:00.0 id reading try 50 times with interval 20 ms to get ffffffff
[ 159.739315] pciehp 0000:00:05.0:pcie004: pciehp_check_link_status: lnk_status = 2011
[ 159.739318] pciehp 0000:00:05.0:pcie004: Failed to check link status
[ 159.739371] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 159.739394] pciehp 0000:00:05.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400
[ 160.771426] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 160.771452] pciehp 0000:00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300
[ 160.771495] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 160.771499] pciehp 0000:00:05.0:pcie004: pciehp_set_attention_status: SLOTCTRL a8 write cmd 40
[ 160.771535] pciehp 0000:00:05.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 160.771539] pciehp 0000:00:05.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300
After analyzing the log information, it seems that qemu doesn't
change the Link Status from active to inactive after hot-unplug.
This results in the abnormal log after the linux kernel commit d331710ea78fea merged.
Furthermore, If I hotplug the same virtio-blk disk after hot-unplug,
the virtio-blk would turn on and then back off.
So this patch set the Link Status inactive after hot-unplug and
active after hot-plug.
Signed-off-by: Zheng Xiang <zhengxiang9@huawei.com> Signed-off-by: Zheng Xiang <xiang.zheng@linaro.org> Cc: Wang Haibin <wanghaibin.wang@huawei.com> Cc: qemu-stable@nongnu.org Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 2f2b18f60bf17453b4c01197a9316615a3c1f1de) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Paul A. Clarke [Fri, 7 Dec 2018 17:13:14 +0000 (15:13 -0200)]
Changes requirement for "vsubsbs" instruction
Changes requirement for "vsubsbs" instruction, which has been supported
since ISA 2.03. (Please see section 5.9.1.2 of ISA 2.03)
Reported-by: Paul A. Clarke <pc@us.ibm.com> Signed-off-by: Paul A. Clarke <pc@us.ibm.com> Signed-off-by: Leonardo Bras <leonardo@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit fcfbc18d00b10335310c9665edd6e04f2d152be8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
"-machine pc" will not work all architectures. Lets fall back to the
default machine by not specifying it.
In addition we also need to specify -no-shutdown on s390 as qemu will
exit otherwise.
Cc: qemu-stable@nongnu.org Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 2c26e648e4350079b0c86a6627b2d3566c3709c0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
This test is broken without previous commit fixing dead-lock in mirror.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Acked-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit db5e8210adbafe9c6383d8364345a8c545d38e62)
*drop context deps from test groups not in 3.0
*modify expected QMP output to match encoding for 3.0 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit b9e413dd375 (in 2.9)
"block: explicitly acquire aiocontext in aio callbacks that need it"
added pairs of aio_context_acquire/release to mirror_write_complete and
mirror_read_complete, when they were aio callbacks for blk_aio_* calls.
Then, commit 2e1990b26e5 (in 3.0) "block/mirror: Convert to coroutines"
dropped these blk_aio_* calls, than mirror_write_complete and
mirror_read_complete are not callbacks more, and don't need additional
aiocontext acquiring. Furthermore, mirror_read_complete calls
blk_co_pwritev inside these pair of aio_context_acquire/release, which
leads to the following dead-lock with mirror:
(gdb) info thr
Id Target Id Frame
3 Thread (LWP 145412) "qemu-system-x86" syscall ()
2 Thread (LWP 145416) "qemu-system-x86" __lll_lock_wait ()
* 1 Thread (LWP 145411) "qemu-system-x86" __lll_lock_wait ()
(gdb) bt
#0 __lll_lock_wait ()
#1 _L_lock_812 ()
#2 __GI___pthread_mutex_lock
#3 qemu_mutex_lock_impl (mutex=0x561032dce420 <qemu_global_mutex>,
file=0x5610327d8654 "util/main-loop.c", line=236) at
util/qemu-thread-posix.c:66
#4 qemu_mutex_lock_iothread_impl
#5 os_host_main_loop_wait (timeout=480116000) at util/main-loop.c:236
#6 main_loop_wait (nonblocking=0) at util/main-loop.c:497
#7 main_loop () at vl.c:1892
#8 main
Printing contents of qemu_global_mutex, I see that "__owner = 145416",
so, thr1 is main loop, and now it wants BQL, which is owned by thr2.
Yes it is mirror_read_complete calling blk_co_pwritev after acquiring
aio context.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit d12ade5732c4d2d293735a39b4bd943da8d64db6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20181130023232.3079982-4-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
(cherry picked from commit c688e6ca7b41a105241054853d250df64addbf8f)
*drop functional dep. on 6c2e581d4d7 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eric Blake [Fri, 30 Nov 2018 02:32:31 +0000 (20:32 -0600)]
nbd/client: Make x-dirty-bitmap more reliable
The implementation of x-dirty-bitmap in qemu 3.0 (commit 216ee365)
silently falls back to treating the server as not supporting
NBD_CMD_BLOCK_STATUS if a requested meta_context name was not
negotiated, which in turn means treating the _entire_ image as
data. Since our hack relied on using 'qemu-img map' to view
which portions of the image were dirty by seeing what the
redirected bdrv_block_status() treats as holes, this means
that our fallback treats the entire image as clean. Better
would have been to treat the entire image as dirty, or to fail
to connect because the user's request for a specific context
could not be honored. This patch goes with the latter.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20181130023232.3079982-3-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
(cherry picked from commit 47829c40794160debdb33b4a042d182e776876d4)
*avoid context dep. on 6c2e581d Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eric Blake [Fri, 30 Nov 2018 02:32:30 +0000 (20:32 -0600)]
nbd/server: Advertise all contexts in response to bare LIST
The NBD spec, and even our code comment, says that if the client
asks for NBD_OPT_LIST_META_CONTEXT with 0 queries, then we should
reply with (a possibly-compressed representation of) ALL contexts
that we are willing to let them try. But commit 3d068aff forgot
to advertise qemu:dirty-bitmap:FOO.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20181130023232.3079982-2-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
(cherry picked from commit e31d802479df9daff1994a7ed1e36bbc5bb19d03) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
BALATON Zoltan [Wed, 28 Nov 2018 19:27:06 +0000 (20:27 +0100)]
i2c: Move typedef of bitbang_i2c_interface to i2c.h
Clang 3.4 considers duplicate typedef in ppc4xx_i2c.h and
bitbang_i2c.h an error even if they are identical. Move it to a common
place to allow building with this clang version.
Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 2b4c1125ac3db2734222ff43c25388a16aca4a99) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
qemu_vfio_open_common() initializes s->lock only after passing s to
qemu_vfio_dma_map() via qemu_vfio_init_ramblock().
qemu_vfio_dma_map() tries to lock the uninitialized lock and crashes.
Fix by initializing s->lock first.
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1645840 Fixes: 418026ca43bc2626db092d7558258f9594366f28 Cc: qemu-stable@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20181127084143.1113-1-armbru@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 549b50a31d28f2687a47e827a1e17300784a2c44) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Mon, 19 Nov 2018 10:19:21 +0000 (11:19 +0100)]
qemu-img: Fix leak
create_opts was leaked here. This is not too bad since the process is
about to exit anyway, but relying on that does not make the code nicer
to read.
Fixes: d402b6a21a825a5c07aac9251990860723d49f5d Reported-by: Kevin Wolf <kwolf@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 3ecd5a4f19fd9a497490a91aaa96e76a5edadd2c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Mon, 19 Nov 2018 10:19:20 +0000 (11:19 +0100)]
qemu-img: Fix typo
Fixes: d402b6a21a825a5c07aac9251990860723d49f5d Reported-by: Kevin Wolf <kwolf@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit f0998879e049dad19beed881a1c56643ce536384) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Mark Cave-Ayland [Sun, 11 Nov 2018 09:40:23 +0000 (09:40 +0000)]
fdc: fix segfault in fdctrl_stop_transfer() when DMA is disabled
Commit c8a35f1cf0f "fdc: use IsaDma interface instead of global DMA_*
functions" accidentally introduced a segfault in fdctrl_stop_transfer() for
non-DMA transfers.
If fdctrl->dma_chann has not been configured then the fdctrl->dma interface
reference isn't initialised during isabus_fdc_realize(). Unfortunately
fdctrl_stop_transfer() unconditionally references the DMA interface when
finishing the transfer causing a NULL pointer dereference.
Fix the issue by adding a check in fdctrl_stop_transfer() so that the DMA
interface reference and release method is only invoked if fdctrl->dma_chann
has been set.
(This issue was discovered by Martin testing a recent change in the NetBSD
installer under qemu-system-sparc)
Cc: qemu-stable@nongnu.org Reported-by: Martin Husemann <martin@duskware.de> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Hervé Poussineau <hpoussin@reactos.org> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 441f6692ecc14859b77af2ac6d8f55e6f1354d3b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Tue, 4 Dec 2018 03:53:43 +0000 (11:53 +0800)]
net: drop too large packet early
We try to detect and drop too large packet (>INT_MAX) in 1592a9947036
("net: ignore packet size greater than INT_MAX") during packet
delivering. Unfortunately, this is not sufficient as we may hit
another integer overflow when trying to queue such large packet in
qemu_net_queue_append_iov():
- size of the allocation may overflow on 32bit
- packet->size is integer which may overflow even on 64bit
Fixing this by moving the check to qemu_sendv_packet_async() which is
the entrance of all networking codes and reduce the limit to
NET_BUFSIZE to be more conservative. This works since:
- For the callers that call qemu_sendv_packet_async() directly, they
only care about if zero is returned to determine whether to prevent
the source from producing more packets. A callback will be triggered
if peer can accept more then source could be enabled. This is
usually used by high speed networking implementation like virtio-net
or netmap.
- For the callers that call qemu_sendv_packet() that calls
qemu_sendv_packet_async() indirectly, they often ignore the return
value. In this case qemu will just the drop packets if peer can't
receive.
Qemu will copy the packet if it was queued. So it was safe for both
kinds of the callers to assume the packet was sent.
Since we move the check from qemu_deliver_packet_iov() to
qemu_sendv_packet_async(), it would be safer to make
qemu_deliver_packet_iov() static to prevent any external user in the
future.
This is a revised patch of CVE-2018-17963.
Cc: qemu-stable@nongnu.org Cc: Li Qiang <liq3ea@163.com> Fixes: 1592a9947036 ("net: ignore packet size greater than INT_MAX") Reported-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20181204035347.6148-2-jasowang@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 25c01bd19d0e4b66f357618aeefda1ef7a41e21a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Michael Roth [Fri, 9 Nov 2018 16:13:52 +0000 (10:13 -0600)]
make-release: add skiboot .version file
This is needed to build skiboot from tarball-distributed sources
since the git data the make_release.sh script relies on to generate
it is not available.
Cc: qemu-stable@nongnu.org Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20181109161352.29873-1-mdroth@linux.vnet.ibm.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 3fccd3f26ef3c0c76a06c138b17af6d55a5d9904) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
yuchenlin [Fri, 12 Oct 2018 09:07:52 +0000 (17:07 +0800)]
vhost-scsi: prevent using uninitialized vqs
There are 3 virtqueues (ctrl, event and cmd) for virtio scsi device,
but seabios will only set the physical address for the 3rd one (cmd).
Then in vhost_virtqueue_start(), virtio_queue_get_desc_addr()
will be 0 for ctrl and event vq.
In this case, ctrl and event vq are not initialized.
vhost_verify_ring_mappings may use uninitialized vhost_virtqueue
such that vhost_verify_ring_part_mapping returns ENOMEM.
When encountered this problem, we got the following logs:
qemu-system-x86_64: Unable to map available ring for ring 0
qemu-system-x86_64: Verify ring failure on region 0
Signed-off-by: Forrest Liu <forrestl@synology.com> Signed-off-by: yuchenlin <yuchenlin@synology.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit e6cc11d64fc998c11a4dfcde8fda3fc33a74d844) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Ilya Maximets [Mon, 8 Oct 2018 16:05:35 +0000 (19:05 +0300)]
migration: Stop postcopy fault thread before notifying
POSTCOPY_NOTIFY_INBOUND_END handlers will remove userfault fds
from the postcopy_remote_fds array which could be still in
use by the fault thread. Let's stop the thread before
notification to avoid possible accessing wrong memory.
Fixes: 46343570c06e ("vhost+postcopy: Wire up POSTCOPY_END notify") Cc: qemu-stable@nongnu.org Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Message-Id: <20181008160536.6332-2-i.maximets@samsung.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit 55d0fe8254984321a126efd8db358f754737aa63) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Denis V. Lunev [Thu, 4 Oct 2018 10:03:13 +0000 (13:03 +0300)]
nbd: fix NBD_FLAG_SEND_CACHE value
Commit bc37b06a5 added NBD_CMD_CACHE support, but used the wrong value
for NBD_FLAG_SEND_CACHE flag for negotiation. That commit picked bit 8,
which had already been assigned by the NBD specification to mean
NBD_FLAG_CAN_MULTI_CONN, and which was already implemented in the
Linux kernel as a part of stable userspace-kernel API since 4.10:
"bit 8, NBD_FLAG_CAN_MULTI_CONN: Indicates that the server operates
entirely without cache, or that the cache it uses is shared among all
connections to the given device. In particular, if this flag is
present, then the effects of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA
MUST be visible across all connections when the server sends its reply
to that command to the client. In the absense of this flag, clients
SHOULD NOT multiplex their commands over more than one connection to
the export.
...
bit 10, NBD_FLAG_SEND_CACHE: documents that the server understands
NBD_CMD_CACHE; however, note that server implementations exist
which support the command without advertising this bit, and
conversely that this bit does not guarantee that the command will
succeed or have an impact."
Consequences:
- a client trying to use NBD_CMD_CACHE per the NBD spec will not
see the feature as available from a qemu 3.0 server (not fatal,
clients already have to be prepared for caching to not exist)
- a client accidentally coded to the qemu 3.0 bit value instead
of following the spec may interpret NBD_CMD_CACHE as being available
when it is not (probably not fatal, the spec says the server should
gracefully fail unknown commands, and that clients of NBD_CMD_CACHE
should be prepared for failure even when the feature is advertised);
such clients are unlikely (perhaps only in unreleased Virtuozzo code),
and will disappear over time
- a client prepared to use multiple connections based on
NBD_FLAG_CAN_MULTI_CONN may cause data corruption when it assumes
that caching is consistent when in reality qemu 3.0 did not have
a consistent cache. Partially mitigated by using read-only
connections (where nothing needs to be flushed, so caching is
indeed consistent) or when using qemu-nbd with the default -e 1
(at most one client at a time); visible only when using -e 2 or
more for a writable export.
Thus the commit fixes negotiation flag in QEMU according to the
specification.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> CC: Valery Vdovin <valery.vdovin@acronis.com> CC: Eric Blake <eblake@redhat.com> CC: Paolo Bonzini <pbonzini@redhat.com> CC: qemu-stable@nongnu.org
Message-Id: <20181004100313.4253-1-den@openvz.org> Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: enhance commit message, add defines for unimplemented flags] Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit df91328adab8490367776d2b21b35d790a606120) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Sat, 29 Sep 2018 03:36:15 +0000 (11:36 +0800)]
intel_iommu: better handling of dmar state switch
QEMU is not handling the global DMAR switch well, especially when from
"on" to "off".
Let's first take the example of system reset.
Assuming that a guest has IOMMU enabled. When it reboots, we will drop
all the existing DMAR mappings to handle the system reset, however we'll
still keep the existing memory layouts which has the IOMMU memory region
enabled. So after the reboot and before the kernel reloads again, there
will be no mapping at all for the host device. That's problematic since
any software (for example, SeaBIOS) that runs earlier than the kernel
after the reboot will assume the IOMMU is disabled, so any DMA from the
software will fail.
For example, a guest that boots on an assigned NVMe device might fail to
find the boot device after a system reboot/reset and we'll be able to
observe SeaBIOS errors if we capture the debugging log:
WARNING - Timeout at nvme_wait:144!
Meanwhile, we should see DMAR errors on the host of that NVMe device.
It's the DMA fault that caused a NVMe driver timeout.
The correct fix should be that we do proper switching of device DMA
address spaces when system resets, which will setup correct memory
regions and notify the backend of the devices. This might not affect
much on non-assigned devices since QEMU VT-d emulation will assume a
default passthrough mapping if DMAR is not enabled in the GCMD
register (please refer to vtd_iommu_translate). However that's required
for an assigned devices, since that'll rebuild the correct GPA to HPA
mapping that is needed for any DMA operation during guest bootstrap.
Besides the system reset, we have some other places that might change
the global DMAR status and we'd better do the same thing there. For
example, when we change the state of GCMD register, or the DMAR root
pointer. Do the same refresh for all these places. For these two
places we'll also need to explicitly invalidate the context entry cache
and iotlb cache.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1625173 CC: QEMU Stable <qemu-stable@nongnu.org> Reported-by: Cong Li <coli@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
--
v2:
- do the same for GCMD write, or root pointer update [Alex]
- test is carried out by me this time, by observing the
vtd_switch_address_space tracepoint after system reboot
v3:
- rewrite commit message as suggested by Alex Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 2cc9ddccebcaa48b3debfc279a83761fcbb7616c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Sat, 29 Sep 2018 03:36:14 +0000 (11:36 +0800)]
intel_iommu: introduce vtd_reset_caches()
Provide the function and use it in vtd_init(). Used to reset both
context entry cache and iotlb cache for the whole IOMMU unit.
Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 06aba4ca52fd2c8718b8ba486f22f0aa7c99ed55)
*functional dep. for 2cc9ddcceb Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Mon, 8 Oct 2018 13:55:02 +0000 (14:55 +0100)]
target/arm: Correct condition for v8M callee stack push
In v7m_exception_taken() we were incorrectly using a
"LR bit EXCRET.ES is 1" check when it should be 0
(compare the pseudocode ExceptionTaken() function).
This meant we didn't stack the callee-saved registers
when tailchaining from a NonSecure to a Secure exception.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20181002145940.30931-1-peter.maydell@linaro.org
(cherry picked from commit 7b73a1ca05b33d42278ce29cea4652e22d408165) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Kevin Wolf [Fri, 28 Sep 2018 09:11:50 +0000 (11:11 +0200)]
block-backend: Set werror/rerror defaults in blk_new()
Currently, the default values for werror and rerror have to be set
explicitly with blk_set_on_error() by the callers of blk_new(). The only
caller actually doing this is blockdev_init(), which is called for
BlockBackends created using -drive.
In particular, anonymous BlockBackends created with
-device ...,drive=<node-name> didn't get the correct default set and
instead defaulted to the integer value 0 (= BLOCKDEV_ON_ERROR_REPORT).
This is the intended default for rerror anyway, but the default for
werror should be BLOCKDEV_ON_ERROR_ENOSPC.
Set the defaults in blk_new() instead so that they apply no matter what
way the BlockBackend was created.
Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com>
(cherry picked from commit cb53460b708db3617ab73248374d071d5552c263) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Paolo Bonzini [Wed, 26 Sep 2018 21:17:42 +0000 (23:17 +0200)]
virtio: do not take address of packed members
The address of a packed member is not packed, which may cause accesses
to unaligned pointers. Avoid this by reading the packed value before
passing it to another function.
Cc: Jason Wang <jasowang@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d41ca5afe3bc513ecf10b3ba5aa59523e3cd54aa) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Mon, 8 Oct 2018 13:55:02 +0000 (14:55 +0100)]
virt: Suppress external aborts on virt-2.10 and earlier
In commit c79c0a314c43b78 we enabled emulation of external aborts
when the guest attempts to access a physical address with no
mapped device. In commit 4672cbd7bed88dc6 we suppress this for
most legacy boards to prevent breakage of previously working
guests, but we didn't suppress it in the 'virt' board, with
the rationale "we know that guests won't try to prod devices
that we don't describe in the device tree or ACPI tables". This
is mostly true, but we've had a report of a Linux guest image
that this did break. The problem seems to be that the guest
is (incorrectly) configured with a DEBUG_UART_PHYS value that
tells it there is a uart at 0x10009000 (which is true for
vexpress but not for virt), so in early bootup the kernel
probes this bogus address.
This is a misconfigured guest, so we don't need to worry
about it too much, but we can arrange that guests that ran
on QEMU v2.10 (before c79c0a314c43b78) will still run on
the "virt-2.10" board model, by suppressing external aborts
only for that version and earlier. This seems a reasonable
compromise: "virt-2.10" is supposed to behave the same way
that "virt" did in the 2.10 release, and making it do that
provides a usable workaround for guests with bugs like this.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20180925144127.31965-1-peter.maydell@linaro.org Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
(cherry picked from commit 846690dee8ca6a4143d20b39e894fd1f24627561) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Wed, 30 May 2018 05:16:36 +0000 (13:16 +0800)]
net: ignore packet size greater than INT_MAX
There should not be a reason for passing a packet size greater than
INT_MAX. It's usually a hint of bug somewhere, so ignore packet size
greater than INT_MAX in qemu_deliver_packet_iov()
CC: qemu-stable@nongnu.org Reported-by: Daniel Shapira <daniel@twistlock.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 1592a9947036d60dde5404204a5d45975133caf5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Wed, 30 May 2018 04:11:30 +0000 (12:11 +0800)]
pcnet: fix possible buffer overflow
In pcnet_receive(), we try to assign size_ to size which converts from
size_t to integer. This will cause troubles when size_ is greater
INT_MAX, this will lead a negative value in size and it can then pass
the check of size < MIN_BUF_SIZE which may lead out of bound access
for both buf and buf1.
Fixing by converting the type of size to size_t.
CC: qemu-stable@nongnu.org Reported-by: Daniel Shapira <daniel@twistlock.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit b1d80d12c5f7ff081bb80ab4f4241d4248691192) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Wed, 30 May 2018 05:07:43 +0000 (13:07 +0800)]
rtl8139: fix possible out of bound access
In rtl8139_do_receive(), we try to assign size_ to size which converts
from size_t to integer. This will cause troubles when size_ is greater
INT_MAX, this will lead a negative value in size and it can then pass
the check of size < MIN_BUF_SIZE which may lead out of bound access of
for both buf and buf1.
Fixing by converting the type of size to size_t.
CC: qemu-stable@nongnu.org Reported-by: Daniel Shapira <daniel@twistlock.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 1a326646fef38782e5542280040ec3ea23e4a730) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jason Wang [Wed, 30 May 2018 05:08:15 +0000 (13:08 +0800)]
ne2000: fix possible out of bound access in ne2000_receive
In ne2000_receive(), we try to assign size_ to size which converts
from size_t to integer. This will cause troubles when size_ is greater
INT_MAX, this will lead a negative value in size and it can then pass
the check of size < MIN_BUF_SIZE which may lead out of bound access of
for both buf and buf1.
Fixing by converting the type of size to size_t.
CC: qemu-stable@nongnu.org Reported-by: Daniel Shapira <daniel@twistlock.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit fdc89e90fac40c5ca2686733df17b6423fb8d8fb) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Fix cpu_get_tb_cpu_state() for non-SVE CPUs
Not only are the sve-related tb_flags fields unused when SVE is
disabled, but not all of the cpu registers are initialized properly
for computing same. This can corrupt other fields by ORing in -1,
which might result in QEMU crashing.
This bug was not present in 3.0, but this patch is cc'd to
stable because adf92eab90e3f5f34c285 where the bug was
introduced was marked for stable.
Fixes: adf92eab90e3f5f34c285 Cc: qemu-stable@nongnu.org (3.0.1) Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit e79b445d896deb61909be52b61b87c98a9ed96f7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jeff Cody [Tue, 11 Sep 2018 22:32:32 +0000 (18:32 -0400)]
block/rbd: add iotest for rbd legacy keyvalue filename parsing
This is a small test that will check for the ability to parse
both legacy and modern options for rbd.
The way the test is set up is for failure to occur, but without
having to wait to timeout on a non-existent rbd server. The error
messages in the success path show that the arguments were parsed.
The failure behavior prior to the patch series that has this test, is
qemu-img complaining about mandatory options (e.g. 'pool') not being
provided.
Jeff Cody [Tue, 11 Sep 2018 22:32:31 +0000 (18:32 -0400)]
block/rbd: Attempt to parse legacy filenames
When we converted rbd to get rid of the older key/value-centric
encoding format, we broke compatibility with image files with backing
file strings encoded in the old format.
This leaves a bit of an ugly conundrum, and a hacky solution.
If the initial attempt to parse the "proper" options fails, it assumes
that we may have an older key/value encoded filename. Fall back to
attempting to parse the filename, and extract the required options from
it. If that fails, pass along the original error message.
We do not support mixed modern usage alongside legacy keyvalue pair
usage.
A deprecation warning has been added, although care should be taken
when actually deprecating since the impact is not limited to
commandline or qapi usage, but also opening existing images.
Jeff Cody [Tue, 11 Sep 2018 22:32:30 +0000 (18:32 -0400)]
block/rbd: pull out qemu_rbd_convert_options
Code movement to pull the conversion from Qdict to BlockdevOptionsRbd
into a helper function.
Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Jeff Cody <jcody@redhat.com>
Message-id: 5b49a980f2cde6610ab1df41bb0277d00b5db893.1536704901.git.jcody@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
(cherry picked from commit f24b03b56cdb28d753b4ff9ae210d555f14cb0d8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Before, we did not clear callback like handle_output when delete
the virtqueue which may result be segmentfault.
The scene is as follows:
1. Start a vm with multiqueue vhost-net,
2. then we write VIRTIO_PCI_GUEST_FEATURES in PCI configuration to
triger multiqueue disable in this vm which will delete the virtqueue.
In this step, the tx_bh is deleted but the callback virtio_net_handle_tx_bh
still exist.
3. Finally, we write VIRTIO_PCI_QUEUE_NOTIFY in PCI configuration to
notify the deleted virtqueue. In this way, virtio_net_handle_tx_bh
will be called and qemu will be crashed.
Although the way described above is uncommon, we had better reinforce it.
CC: qemu-stable@nongnu.org Signed-off-by: liujunjie <liujunjie23@huawei.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 7da2d99fb9fbf30104125c061caaff330e362d74) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
bitmap_to_extents function is broken: it switches dirty variable after
every iteration, however it can process only part of dirty (or zero)
area during one iteration in case when this area is too large for one
extent.
Fortunately, the bug doesn't produce wrong extent flags: it just inserts
a zero-length extent between sequential extents representing large dirty
(or zero) area. However, zero-length extents are forbidden by the NBD
protocol. So, a careful client should consider such a reply as a server
fault, while a less-careful will likely ignore zero-length extents.
The bug can only be triggered by a client that requests block status
for nearly 4G at once (a request of 4G and larger is impossible per
the protocol, and requests smaller than 4G less the bitmap granularity
cause the loop to quit iterating rather than revisit the tail of the
large area); it also cannot trigger if the client used the
NBD_CMD_FLAG_REQ_ONE flag. Since qemu 3.0 as client (using the
x-dirty-bitmap extension) always passes the flag, it is immune; and
we are not aware of other open-source clients that know how to request
qemu:dirty-bitmap:FOO contexts. Clients that want to avoid the bug
could cap block status requests to a smaller length, such as 2G or 3G.
Fix this by more careful handling of dirty variable.
Bug was introduced in 3d068aff16
"nbd/server: implement dirty bitmap export", with the whole function.
and is present in v3.0.0 release.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20180914165116.23182-1-vsementsov@virtuozzo.com> CC: qemu-stable@nongnu.org Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: improved commit message] Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 6545916d528de7a6b784f4d10e7b236b30bfaced) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Filippov [Tue, 11 Sep 2018 01:23:35 +0000 (18:23 -0700)]
target/xtensa: fix s32c1i TCGMemOp flags
s32c1i must load and store value with target endianness, not host.
This results in an infinite loop in atomic cmpxchg sequences when target
endianness doesn't match host endianness.
Fixes: 9fb40342d4b3 ("target/xtensa: support MTTCG") Cc: qemu-stable@nongnu.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 7a54cfbcee8dd7aa87ce655a321b622107556326) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Fam Zheng [Fri, 24 Aug 2018 02:43:42 +0000 (10:43 +0800)]
job: Fix nested aio_poll() hanging in job_txn_apply
All callers have acquired ctx already. Doing that again results in
aio_poll() hang. This fixes the problem that a BDRV_POLL_WHILE() in the
callback cannot make progress because ctx is recursively locked, for
example, when drive-backup finishes.
Alberto Garcia [Thu, 6 Sep 2018 14:25:41 +0000 (17:25 +0300)]
block: Fix use after free error in bdrv_open_inherit()
When a block device is opened with BDRV_O_SNAPSHOT and the
bdrv_append_temp_snapshot() call fails then the error code path tries
to unref the already destroyed 'options' QDict.
This can be reproduced easily by setting TMPDIR to a location where
the QEMU process can't write:
Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 8961be33e8ca7e809c603223803ea66ef7ea5be7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Fixes: dbb6da8ba7e ("pc: acpi: revert back to 1 SRAT entry for hotpluggable area") Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d2a1b1d602986a5f02658f6d4fc9ed422f8ddebf) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Igor Mammedov [Wed, 22 Aug 2018 09:46:44 +0000 (11:46 +0200)]
pc: acpi: revert back to 1 SRAT entry for hotpluggable area
Commit 10efd7e108 "pc: acpi: fix memory hotplug regression by reducing stub SRAT entry size"
attemped to fix hotplug regression introduced by 848a1cc1e "hw/acpi-build: build SRAT memory affinity structures for DIMM devices"
fixed issue for Windows/3.0+ linux kernels, however it regressed 2.6 based
kernels (RHEL6) to the point where guest might crash at boot.
Reason is that 2.6 kernel discards SRAT table due too small last entry
which down the road leads to crashes. Hack I've tried in 10efd7e108 is also
not ACPI spec compliant according to which whole possible RAM should be
described in SRAT. Revert 10efd7e108 to fix regression for 2.6 based kernels.
With 10efd7e108 reverted, I've also tried splitting SRAT table statically
in different ways %/node and %/slot but Windows still fails to online
2nd pc-dimm hot-plugged into node 0 (as described in 10efd7e108) and
sometimes even coldplugged pc-dimms where affected with static SRAT
partitioning.
The only known so far way where Windows stays happy is when we have 1
SRAT entry in the last node covering all hotplug area.
Revert 848a1cc1e until we come up with a way to avoid regression
on Windows with hotplug area split in several entries.
Tested this with 2.6/3.0 based kernels (RHEL6/7) and WS20[08/12/12R2/16]).
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit dbb6da8ba7e02105bdbb33b527e088249c9843c8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio_queue_get_desc_addr returns 64-bit hwaddr while int is usually 32-bit.
If returned hwaddr is not equal to 0 but least-significant 32 bits are
equal to 0 then this code will not actually stop running queue.
Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru> Acked-by: Jia He <hejianet@gmail.com> Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit fa4ae4be15fb08b37bec35139688ef563311d0b9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
When user provides a long domainname or hostname that doesn't fit in the
DHCP packet, we mustn't overflow the response packet buffer. Instead,
report errors, following the g_warning() in the slirp->vdnssearch
branch.
Also check the strlen against 256 when initializing slirp, which limit
is also from the protocol where one byte represents the string length.
This gives an early error before the warning which is harder to notice
or diagnose.
Reported-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Fam Zheng <famz@redhat.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
(cherry picked from commit 6e157a0339793bb081705f52318fc77afd10addf) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
kvm: add call to qemu_add_opts() for -overcommit option
qemu command fails to process -overcommit option. Add the missing
call to qemu_add_opts() in vl.c.
Signed-off-by: Prasad Singamsetty <prasad.singamsetty@oracle.com>
Message-Id: <20180815175704.105902-1-prasad.singamsetty@oracle.com> Reviewed-by: Mark Kanda <mark.kanda@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 1fdd4748711a62d863744f42b958472509a6f202) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Filippov [Fri, 31 Aug 2018 07:40:28 +0000 (00:40 -0700)]
target/xtensa: fix FPU2000 bugs
- FPU2000 defines rfr and wfr opcodes, not rfr.s and wfr.s;
- movcond.s uses incorrect operand in tcg_gen_movcond: in case the
condition is not satisfied it must not change its argument 0.
Fixes: c04e1692e3aa ("target/xtensa: extract FPU2000 opcode
translators") Cc: qemu-stable@nongnu.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit e8e05fd472cbe77650353eaa50d5a9703a91c1db) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Paolo Bonzini [Thu, 23 Aug 2018 12:21:23 +0000 (14:21 +0200)]
virtio: update MemoryRegionCaches when guest negotiates features
Because the cache is sized to include the rings and the event indices,
negotiating the VIRTIO_RING_F_EVENT_IDX feature will result in the size
of the cache changing. And because MemoryRegionCache accesses are
range-checked, if we skip this we end up with an assertion failure.
This happens with OpenBSD 6.3.
Reported-by: Fam Zheng <famz@redhat.com> Fixes: 97cd965c070152bc626c7507df9fb356bbe1cd81 Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Fam Zheng <famz@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit db812c4073c77c8a64db8d6663b3416a587c7b4a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Jeff Cody [Tue, 21 Aug 2018 16:26:19 +0000 (12:26 -0400)]
block: for jobs, do not clear user_paused until after the resume
The function job_cancel_async() will always cause an assert for blockjob
user resume. We set job->user_paused to false, and then call
job->driver->user_resume(). In the case of blockjobs, this is the
block_job_user_resume() function.
In that function, we assert that job.user_paused is set to true.
Unfortunately, right before calling this function, it has explicitly
been set to false.
The fix is pretty simple: set job->user_paused to false only after the
job user_resume() function has been called.
Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Jeff Cody <jcody@redhat.com>
Message-id: bb183b77d8f2dd6bd67b8da559a90ac1e74b2052.1534868459.git.jcody@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
(cherry picked from commit e321c0597c7590499bacab239d7f86e257f96bcd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eduardo Habkost [Thu, 9 Aug 2018 22:18:52 +0000 (19:18 -0300)]
i386: Disable TOPOEXT by default on "-cpu host"
Enabling TOPOEXT is always allowed, but it can't be enabled
blindly by "-cpu host" because it may make guests crash if the
rest of the cache topology information isn't provided or isn't
consistent.
This addresses the bug reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=1613277
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180809221852.15285-1-ehabkost@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit 7210a02c58572b2686a3a8d610c6628f87864aed) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Wu [Tue, 7 Aug 2018 22:18:30 +0000 (00:18 +0200)]
vnc: fix memleak of the "vnc-worker-output" name
Fixes repeated memory leaks of 18 bytes when using VNC:
Direct leak of 831024 byte(s) in 46168 object(s) allocated from:
...
#4 0x7f6d2f919bdd in g_strdup_vprintf glib/gstrfuncs.c:514
#5 0x56085cdcf660 in buffer_init util/buffer.c:59
#6 0x56085ca6a7ec in vnc_async_encoding_start ui/vnc-jobs.c:177
#7 0x56085ca6b815 in vnc_worker_thread_loop ui/vnc-jobs.c:240
Fixes: 543b95801f98 ("vnc: attach names to buffers") Cc: Gerd Hoffmann <kraxel@redhat.com> CC: qemu-stable@nongnu.org Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20180807221830.3844-1-peter@lekensteyn.nl Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 0ae0b069aa8f23a138cc6d2d83edaa5c22f948a5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f8e27262c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x7f8e26a5f3c5 in g_malloc (/lib64/libglib-2.0.so.0+0x523c5)
#2 0x555ab67078a8 in qstring_from_str /home/elmarco/src/qq/qobject/qstring.c:67
#3 0x555ab67071e4 in qstring_new /home/elmarco/src/qq/qobject/qstring.c:24
#4 0x555ab6713fbf in qstring_from_escaped_str /home/elmarco/src/qq/qobject/json-parser.c:144
#5 0x555ab671738c in parse_literal /home/elmarco/src/qq/qobject/json-parser.c:506
#6 0x555ab67179c3 in parse_value /home/elmarco/src/qq/qobject/json-parser.c:569
#7 0x555ab6715123 in parse_pair /home/elmarco/src/qq/qobject/json-parser.c:306
#8 0x555ab6715483 in parse_object /home/elmarco/src/qq/qobject/json-parser.c:357
#9 0x555ab671798b in parse_value /home/elmarco/src/qq/qobject/json-parser.c:561
#10 0x555ab6717a6b in json_parser_parse_err /home/elmarco/src/qq/qobject/json-parser.c:592
#11 0x555ab4fd4dcf in handle_qmp_command /home/elmarco/src/qq/monitor.c:4257
#12 0x555ab6712c4d in json_message_process_token /home/elmarco/src/qq/qobject/json-streamer.c:105
#13 0x555ab67e01e2 in json_lexer_feed_char /home/elmarco/src/qq/qobject/json-lexer.c:323
#14 0x555ab67e0af6 in json_lexer_feed /home/elmarco/src/qq/qobject/json-lexer.c:373
#15 0x555ab6713010 in json_message_parser_feed /home/elmarco/src/qq/qobject/json-streamer.c:124
#16 0x555ab4fd58ec in monitor_qmp_read /home/elmarco/src/qq/monitor.c:4337
#17 0x555ab6559df2 in qemu_chr_be_write_impl /home/elmarco/src/qq/chardev/char.c:175
#18 0x555ab6559e95 in qemu_chr_be_write /home/elmarco/src/qq/chardev/char.c:187
#19 0x555ab6560127 in fd_chr_read /home/elmarco/src/qq/chardev/char-fd.c:66
#20 0x555ab65d9c73 in qio_channel_fd_source_dispatch /home/elmarco/src/qq/io/channel-watch.c:84
#21 0x7f8e26a598ac in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x4c8ac)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180809114417.28718-4-marcandre.lureau@redhat.com>
[Screwed up in commit b27314567d4] Cc: qemu-stable@nongnu.org Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
(cherry picked from commit cb9ec42f33c07cd07d2e2971422bf7636c761202) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Fam Zheng [Thu, 9 Aug 2018 13:22:59 +0000 (21:22 +0800)]
aio: Do aio_notify_accept only during blocking aio_poll
An aio_notify() pairs with an aio_notify_accept(). The former should
happen in the main thread or a vCPU thread, and the latter should be
done in the IOThread.
There is one rare case that the main thread or vCPU thread may "steal"
the aio_notify() event just raised by itself, in bdrv_set_aio_context()
[1]. The sequence is like this:
[1] is problematic. It will clear the ctx->notifier event so that
the blocked ppoll() will not return.
(For the curious, this bug was noticed when booting a number of VMs
simultaneously in RHV. One or two of the VMs will hit this race
condition, making the VIRTIO device unresponsive to I/O commands. When
it hangs, Seabios is busy waiting for a read request to complete (read
MBR), right after initializing the virtio-blk-pci device, using 100%
guest CPU. See also https://bugzilla.redhat.com/show_bug.cgi?id=1562750
for the original bug analysis.)
aio_notify() only injects an event when ctx->notify_me is set,
correspondingly aio_notify_accept() is only useful when ctx->notify_me
_was_ set. Move the call to it into the "blocking" branch. This will
effectively skip [1] and fix the hang.
Furthermore, blocking aio_poll is only allowed on home thread
(in_aio_context_home_thread), because otherwise two blocking
aio_poll()'s can steal each other's ctx->notifier event and cause
hanging just like described above.
Cc: qemu-stable@nongnu.org Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <20180809132259.18402-3-famz@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com>
(cherry picked from commit b37548fcd1b8ac2e88e185a395bef851f3fc4e65) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
It is wrong to leave this field as 1, as nvme_close() called in the
error handling code in nvme_file_open() will use it and try to free
s->queues again.
Another problem is the cleaning ups are duplicated between the fail*
labels of nvme_init() and nvme_file_open(), which calls nvme_close().
A third problem is nvme_close() misses g_free() and
event_notifier_cleanup().
Fix all of them.
Cc: qemu-stable@nongnu.org Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <20180712025420.4932-1-famz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com>
(cherry picked from commit 9582f357bb6f6573c9a452743d8f3ab41ba2e3fa) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
qemu-img: fix regression copying secrets during convert
When the convert command is creating an output file that needs
secrets, we need to ensure those secrets are passed to both the
blk_new_open and bdrv_create API calls.
This is done by qemu-img extracting all opts matching the name
suffix "key-secret". Unfortunately the code doing this was run after the
call to bdrv_create(), which meant the QemuOpts it was extracting
secrets from was now empty.
Previously this worked by luks as a bug meant the "key-secret"
parameters were not purged from the QemuOpts. This bug was fixed in
Exposing the latent bug in qemu-img. This fix simply moves the copying
of secrets to before the bdrv_create() call.
Cc: qemu-stable@nongnu.org Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 8d65a3ccfd5db7f0436e095cd952f5d0c3a873ba) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Kevin Wolf [Tue, 14 Aug 2018 09:52:25 +0000 (11:52 +0200)]
mirror: Fail gracefully for source == target
blockdev-mirror with the same node for source and target segfaults
today: A node is in its own backing chain, so mirror_start_job() decides
that this is an active commit. When adding the intermediate nodes with
block_job_add_bdrv(), it starts the iteration through the subchain with
the backing file of source, though, so it never reaches target and
instead runs into NULL at the base.
While we could fix that by starting with source itself, there is no
point in allowing mirroring a node into itself and I wouldn't be
surprised if this caused more problems later.
So just check for this scenario and error out.
Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 86fae10c64d642256cf019e6829929fa0d259c7a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Kevin Wolf [Mon, 13 Aug 2018 13:23:49 +0000 (15:23 +0200)]
block/qapi: Fix memory leak in qmp_query_blockstats()
For BlockBackends that are skipped in query-blockstats, we would leak
info since commit 567dcb31. Allocate info only later to avoid the memory
leak.
Fixes: CID 1394727 Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com>
(cherry picked from commit f62492bb8d1ea7f7e156ffbdf411de46107072c5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Ignore float_flag_input_denormal from fp_status_f16
When FZ is set, input_denormal exceptions are recognized, but this does
not happen with FZ16. The softfloat code has no way to distinguish
these bits and will raise such exceptions into fp_status_f16.flags,
so ignore them when computing the accumulated flags.
Cc: qemu-stable@nongnu.org (3.0.1) Reported-by: Laurent Desnogues <laurent.desnogues@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Desnogues <laurent.desnogues@gmail.com> Tested-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Message-id: 20180810193129.1556-3-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 19062c169e5bcdda3d60df9161228e107bf0f96e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
When support for FZ16 was added, we failed to include the bit
within FPCR_MASK, which means that it could never be set.
Continue to zero FZ16 when ARMv8.2-FP16 is not enabled.
Fixes: d81ce0ef2c4 Cc: qemu-stable@nongnu.org (3.0.1) Reported-by: Laurent Desnogues <laurent.desnogues@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Desnogues <laurent.desnogues@gmail.com> Tested-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Message-id: 20180810193129.1556-2-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 0b62159be33d45d00dfa34a317c6d3da30ffb480) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Bharata B Rao [Wed, 8 Aug 2018 15:59:19 +0000 (21:29 +0530)]
spapr_cpu_core: vmstate_[un]register per-CPU data from (un)realizefn
VMStateDescription vmstate_spapr_cpu_state was added by commit b94020268e0b6 (spapr_cpu_core: migrate per-CPU data) to migrate per-CPU
data with the required vmstate registration and unregistration calls.
However the unregistration is being done only from vcpu creation error path
and not from CPU delete path.
This causes migration to fail with the following error if migration is
attempted after a CPU unplug like this:
Unknown savevm section or instance 'spapr_cpu' 16
Additionally this leaves the source VM unresponsive after migration failure.
Fix this by ensuring the vmstate_unregister happens during CPU removal.
Fixing this becomes easier when vmstate (un)registration calls are moved to
vcpu (un)realize functions which is what this patch does.
Fixes: https://bugs.launchpad.net/qemu/+bug/1785972 Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Bharata B Rao <bharata@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit cc71c7760e263f808c4240a725425671eeeb7e4d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Add sve-max-vq cpu property to -cpu max
This allows the default (and maximum) vector length to be set
from the command-line. Which is extraordinarily helpful in
debugging problems depending on vector length without having to
bake knowledge of PR_SET_SVE_VL into every guest binary.
Cc: qemu-stable@nongnu.org (3.0.1) Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit adf92eab90e3f5f34c285da6d14d48952b7a8e72) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Also fold the FPCR/FPSR state onto the same line as PSTATE,
and mention but do not dump disabled FPU state.
Cc: qemu-stable@nongnu.org (3.0.1) Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 2bf5f3f91bb4e3faa2a19aec042138a938afbf6a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
With PC, there are 33 registers. Three per line lines up nicely
without overflowing 80 columns.
Cc: qemu-stable@nongnu.org (3.0.1) Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 3cb506a399854c481c2fd2efabecda0654700c47) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Fix sign-extension in sve do_ldr/do_str
The expression (int) imm + (uint32_t) len_align turns into uint32_t
and thus with negative imm produces a memory operation at the wrong
offset. None of the numbers involved are particularly large, so
change everything to use int.
Cc: qemu-stable@nongnu.org (3.0.1) Reported-by: Laurent Desnogues <laurent.desnogues@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 19f2acc915a0f8f443a959844540a6f09133cc96) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-stable@nongnu.org (3.0.1) Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 573ec0fe40b9a412085ac7dfb41975a0fc2b28dd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
The pseudocode for this operation is an increment + compare loop,
so comparing <= the maximum integer produces an all-true predicate.
Rather than bound in both the inline code and the helper, pass the
helper the number of predicate bits to set instead of the number
of predicate elements to set.
Reported-by: Laurent Desnogues <laurent.desnogues@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Desnogues <laurent.desnogues@gmail.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Message-id: 20180801123111.3595-4-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit bbd0968c458d48e34a08b8694fa3309a9fe1c9e7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-gpu: fix crashes upon warm reboot with vga mode
With vga=775 on the Linux command line a first boot of the VM running
Linux works fine. After a warm reboot it crashes during Linux boot.
Before that, valgrind points out bad memory write to console
surface. The VGA code is not aware that virtio-gpu got a message
surface scanout when the display is disabled. Let's reset VGA graphic
mode when it is the case, so that a new display surface is created
when doing further VGA operations.
Peter Maydell [Tue, 7 Aug 2018 11:45:01 +0000 (12:45 +0100)]
slirp: Correct size check in m_inc()
The data in an mbuf buffer is not necessarily at the start of the
allocated buffer. (For instance m_adj() allows data to be trimmed
from the start by just advancing the pointer and reducing the length.)
This means that the allocated buffer size (m->m_size) and the
amount of space from the m_data pointer to the end of the
buffer (M_ROOM(m)) are not necessarily the same.
Commit 864036e251f54c9 tried to change the m_inc() function from
taking the new allocated-buffer-size to taking the new room-size,
but forgot to change the initial "do we already have enough space"
check. This meant that if we were trying to extend a buffer which
had a leading gap between the buffer start and the data, we might
incorrectly decide it didn't need to be extended, and then
overrun the end of the buffer, causing memory corruption and
an eventual crash.
Change the "already big enough?" condition from checking the
argument against m->m_size to checking against M_ROOM().
This only makes a difference for the callsite in m_cat();
the other three callsites all start with a freshly allocated
mbuf from m_get(), which will have m->m_size == M_ROOM(m).
Fixes: 864036e251f54c9 Fixes: https://bugs.launchpad.net/qemu/+bug/1785670 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Message-id: 20180807114501.12370-1-peter.maydell@linaro.org Tested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Thomas Huth [Thu, 19 Jul 2018 13:02:00 +0000 (15:02 +0200)]
target/xtensa/cpu: Set owner of memory region in xtensa_cpu_initfn
The instance_init function of the xtensa CPUs creates a memory region,
but does not set an owner, so the memory region is not destroyed
correctly when the CPU object is removed. This can happen when
introspecting the CPU devices, so introspecting the CPU device will
leave a dangling memory region object in the QOM tree. Make sure to
set the right owner here to fix this issue.
Signed-off-by: Thomas Huth <thuth@redhat.com> Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Message-id: 1532005320-17794-1-git-send-email-thuth@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Mon, 6 Aug 2018 12:34:45 +0000 (13:34 +0100)]
hw/intc/arm_gicv3_common: Move gicd shift bug handling to gicv3_post_load
The code currently in gicv3_gicd_no_migration_shift_bug_post_load()
that handles migration from older QEMU versions with a particular
bug is misplaced. We need to run this after migration in all cases,
not just the cases where the "arm_gicv3/gicd_no_migration_shift_bug"
subsection is present, so it must go in a post_load hook for the
top level VMSD, not for the subsection. Move it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: 20180806123445.1459-6-peter.maydell@linaro.org
Peter Maydell [Mon, 6 Aug 2018 12:34:44 +0000 (13:34 +0100)]
hw/intc/arm_gicv3_common: Move post_load hooks to top-level VMSD
Contrary to the the impression given in docs/devel/migration.rst,
the migration code does not run the pre_load hook for a
subsection unless the subsection appears on the wire, and so
this is not a place where you can set the default value for
state for the "subsection not present" case. Instead this needs
to be done in a pre_load hook for whatever is the parent VMSD
of the subsection.
We got this wrong in two of the subsection definitions in
the GICv3 migration structs; fix this.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-id: 20180806123445.1459-5-peter.maydell@linaro.org
Peter Maydell [Mon, 6 Aug 2018 12:34:43 +0000 (13:34 +0100)]
target/arm: Add dummy needed functions to M profile vmstate subsections
Currently the migration code incorrectly treats a subsection with
no .needed function pointer as if it was the subsection list
terminator -- it is ignored and so is everything after it.
Work around this by giving various M profile vmstate structs
a 'needed' function that always returns true.
We reuse m_needed() for this, since it's always true here.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180806123445.1459-4-peter.maydell@linaro.org
Peter Maydell [Mon, 6 Aug 2018 12:34:42 +0000 (13:34 +0100)]
hw/intc/arm_gicv3_common: Combine duplicate .subsections in vmstate_gicv3_cpu
Commit 6692aac411199064 accidentally introduced a second initialization
of the .subsections field of vmstate_gicv3_cpu, instead of adding
the new subsection to the existing list. The effect of this was
probably that migration of GICv3 with virtualization enabled was
broken (or alternatively that migration of ICC_SRE_EL1 was broken,
depending on which of the two initializers the compiler used).
Combine the two into a single list.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180806123445.1459-3-peter.maydell@linaro.org
Peter Maydell [Mon, 6 Aug 2018 12:34:41 +0000 (13:34 +0100)]
hw/intc/arm_gicv3_common: Give no-migration-shift-bug subsection a needed function
Currently the migration code incorrectly treats a subsection with
no .needed function pointer as if it was the subsection list
terminator -- it is ignored and so is everything after it.
Work around this by giving vmstate_gicv3_gicd_no_migration_shift_bug
a 'needed' function that always returns true.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180806123445.1459-2-peter.maydell@linaro.org
Peter Maydell [Mon, 6 Aug 2018 08:59:05 +0000 (09:59 +0100)]
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
pc, virtio: fixes
A couple of last minute fixes.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Fri 03 Aug 2018 09:35:54 BST
# gpg: using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream:
tests/acpi: update tables after memory hotplug changes
pc: acpi: fix memory hotplug regression by reducing stub SRAT entry size
tests/acpi-test: update ACPI tables test blobs
hw/acpi-build: Add a check for memory-less NUMA nodes
vhost: check region type before casting
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Now, QEmu adds a new check for memory-less NUMA nodes in build_srat().
It effects the ACPI test.
So, Update ACPI tables test blobs.
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Check region type first before casting the memory region
to IOMMUMemoryRegion. Otherwise QEMU will abort with below
error message when casting non-IOMMU memory region:
vhost_iommu_region_add: Object 0x561f28bce4f0 is not an
instance of type qemu:iommu-memory-region
Fixes: cb1efcf462a2 ("iommu: Add IOMMU index argument to notifier APIs") Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Tiwei Bie <tiwei.bie@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
sam460ex: Fix PCI interrupts with multiple devices
The four interrupts of the PCI bus are connected to the same UIC pin
on the real Sam460ex. Evidence for this can be found in the UBoot
source for the Sam460ex in the Sam460ex.c file where
PCI_INTERRUPT_LINE is written. Change the ppc440_pcix model to behave
more like this.
This fixes the problem that can be observed when adding further PCI
cards that got their interrupt rotated to other interrupts than PCI
INT A. In particular, the bug was observed with an additional OHCI PCI
card or an ES1370 sound device.
Signed-off-by: Sebastian Bauer <mail@sebastianbauer.info> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Tested-by: Sebastian Bauer <mail@sebastianbauer.info> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Use the new function sysbus_init_child_obj() to initialize the objects
here, to get the reference counting of the objects right, so that they
are cleaned up correctly when the parent gets removed.
Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
monitor: temporary fix for dead-lock on event recursion
With a Spice port chardev, it is possible to reenter
monitor_qapi_event_queue() (when the client disconnects for
example). This will dead-lock on monitor_lock.
Instead, use some TLS variables to check for recursion and queue the
events.
Fixes:
(gdb) bt
#0 0x00007fa69e7217fd in __lll_lock_wait () at /lib64/libpthread.so.0
#1 0x00007fa69e71acf4 in pthread_mutex_lock () at /lib64/libpthread.so.0
#2 0x0000563303567619 in qemu_mutex_lock_impl (mutex=0x563303d3e220 <monitor_lock>, file=0x5633036589a8 "/home/elmarco/src/qq/monitor.c", line=645) at /home/elmarco/src/qq/util/qemu-thread-posix.c:66
#3 0x0000563302fa6c25 in monitor_qapi_event_queue (event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x56330602bde0, errp=0x7ffc6ab5e728) at /home/elmarco/src/qq/monitor.c:645
#4 0x0000563303549aca in qapi_event_send_spice_disconnected (server=0x563305afd630, client=0x563305745360, errp=0x563303d8d0f0 <error_abort>) at qapi/qapi-events-ui.c:149
#5 0x00005633033e600f in channel_event (event=3, info=0x5633061b0050) at /home/elmarco/src/qq/ui/spice-core.c:235
#6 0x00007fa69f6c86bb in reds_handle_channel_event (reds=<optimized out>, event=3, info=0x5633061b0050) at reds.c:316
#7 0x00007fa69f6b193b in main_dispatcher_self_handle_channel_event (info=0x5633061b0050, event=3, self=0x563304e088c0) at main-dispatcher.c:197
#8 0x00007fa69f6b193b in main_dispatcher_channel_event (self=0x563304e088c0, event=event@entry=3, info=0x5633061b0050) at main-dispatcher.c:197
#9 0x00007fa69f6d0833 in red_stream_push_channel_event (s=s@entry=0x563305ad8f50, event=event@entry=3) at red-stream.c:414
#10 0x00007fa69f6d086b in red_stream_free (s=0x563305ad8f50) at red-stream.c:388
#11 0x00007fa69f6b7ddc in red_channel_client_finalize (object=0x563304df2360) at red-channel-client.c:347
#12 0x00007fa6a56b7fb9 in g_object_unref () at /lib64/libgobject-2.0.so.0
#13 0x00007fa69f6ba212 in red_channel_client_push (rcc=0x563304df2360) at red-channel-client.c:1341
#14 0x00007fa69f68b259 in red_char_device_send_msg_to_client (client=<optimized out>, msg=0x5633059b6310, dev=0x563304e08bc0) at char-device.c:305
#15 0x00007fa69f68b259 in red_char_device_send_msg_to_clients (msg=0x5633059b6310, dev=0x563304e08bc0) at char-device.c:305
#16 0x00007fa69f68b259 in red_char_device_read_from_device (dev=0x563304e08bc0) at char-device.c:353
#17 0x000056330317d01d in spice_chr_write (chr=0x563304cafe20, buf=0x563304cc50b0 "{\"timestamp\": {\"seconds\": 1532944763, \"microseconds\": 326636}, \"event\": \"SHUTDOWN\", \"data\": {\"guest\": false}}\r\n", len=111) at /home/elmarco/src/qq/chardev/spice.c:199
#18 0x00005633034deee7 in qemu_chr_write_buffer (s=0x563304cafe20, buf=0x563304cc50b0 "{\"timestamp\": {\"seconds\": 1532944763, \"microseconds\": 326636}, \"event\": \"SHUTDOWN\", \"data\": {\"guest\": false}}\r\n", len=111, offset=0x7ffc6ab5ea70, write_all=false) at /home/elmarco/src/qq/chardev/char.c:112
#19 0x00005633034df054 in qemu_chr_write (s=0x563304cafe20, buf=0x563304cc50b0 "{\"timestamp\": {\"seconds\": 1532944763, \"microseconds\": 326636}, \"event\": \"SHUTDOWN\", \"data\": {\"guest\": false}}\r\n", len=111, write_all=false) at /home/elmarco/src/qq/chardev/char.c:147
#20 0x00005633034e1e13 in qemu_chr_fe_write (be=0x563304dbb800, buf=0x563304cc50b0 "{\"timestamp\": {\"seconds\": 1532944763, \"microseconds\": 326636}, \"event\": \"SHUTDOWN\", \"data\": {\"guest\": false}}\r\n", len=111) at /home/elmarco/src/qq/chardev/char-fe.c:42
#21 0x0000563302fa6334 in monitor_flush_locked (mon=0x563304dbb800) at /home/elmarco/src/qq/monitor.c:425
#22 0x0000563302fa6520 in monitor_puts (mon=0x563304dbb800, str=0x563305de7e9e "") at /home/elmarco/src/qq/monitor.c:468
#23 0x0000563302fa680c in qmp_send_response (mon=0x563304dbb800, rsp=0x563304df5730) at /home/elmarco/src/qq/monitor.c:517
#24 0x0000563302fa6905 in qmp_queue_response (mon=0x563304dbb800, rsp=0x563304df5730) at /home/elmarco/src/qq/monitor.c:538
#25 0x0000563302fa6b5b in monitor_qapi_event_emit (event=QAPI_EVENT_SHUTDOWN, qdict=0x563304df5730) at /home/elmarco/src/qq/monitor.c:624
#26 0x0000563302fa6c4b in monitor_qapi_event_queue (event=QAPI_EVENT_SHUTDOWN, qdict=0x563304df5730, errp=0x7ffc6ab5ed00) at /home/elmarco/src/qq/monitor.c:649
#27 0x0000563303548cce in qapi_event_send_shutdown (guest=false, errp=0x563303d8d0f0 <error_abort>) at qapi/qapi-events-run-state.c:58
#28 0x000056330313bcd7 in main_loop_should_exit () at /home/elmarco/src/qq/vl.c:1822
#29 0x000056330313bde3 in main_loop () at /home/elmarco/src/qq/vl.c:1862
#30 0x0000563303143781 in main (argc=3, argv=0x7ffc6ab5f068, envp=0x7ffc6ab5f088) at /home/elmarco/src/qq/vl.c:4644
Note that error report is now moved to the first caller, which may
receive an error for a recursed event. This is probably fine (95% of
callers use &error_abort, the rest have NULL error and ignore it)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180731150144.14022-1-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
[*_no_recurse renamed to *_no_reenter, local variables reordered] Signed-off-by: Markus Armbruster <armbru@redhat.com>
* remotes/bonzini/tags/for-upstream:
backends/cryptodev: remove dead code
timer: remove replay clock probe in deadline calculation
i386: implement MSR_SMI_COUNT for TCG
i386: do not migrate MSR_SMI_COUNT on machine types <2.12
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
projects / mirror_qemu.git / log