- 04 8月, 2017 13 次提交
-
-
由 Sameeh Jubran 提交于
This commit fixes a bug which causes the guest to hang. The bug was observed upon a "receive overrun" (bit #6 of the ICR register) interrupt which could be triggered post migration in a heavy traffic environment. Even though the "receive overrun" bit (#6) is masked out by the IMS register (refer to the log below) the driver still receives an interrupt as the "receive overrun" bit (#6) causes the "Other" - bit #24 of the ICR register - bit to be set as documented below. The driver handles the interrupt and clears the "Other" bit (#24) but doesn't clear the "receive overrun" bit (#6) which leads to an infinite loop. Apparently the Windows driver expects that the "receive overrun" bit and other ones - documented below - to be cleared when the "Other" bit (#24) is cleared. So to sum that up: 1. Bit #6 of the ICR register is set by heavy traffic 2. As a results of setting bit #6, bit #24 is set 3. The driver receives an interrupt for bit 24 (it doesn't receieve an interrupt for bit #6 as it is masked out by IMS) 4. The driver handles and clears the interrupt of bit #24 5. Bit #6 is still set. 6. 2 happens all over again The Interrupt Cause Read - ICR register: The ICR has the "Other" bit - bit #24 - that is set when one or more of the following ICR register's bits are set: LSC - bit #2, RXO - bit #6, MDAC - bit #9, SRPD - bit #16, ACK - bit #17, MNG - bit #18 This bug can occur with any of these bits depending on the driver's behaviour and the way it configures the device. However, trying to reproduce it with any bit other than RX0 is challenging and came to failure as the drivers don't implement most of these bits, trying to reproduce it with LSC (Link Status Change - bit #2) bit didn't succeed too as it seems that Windows handles this bit differently. Log sample of the storm: 27563@1494850819.411877:e1000e_irq_pending_interrupts ICR PENDING: 0x1000000 (ICR: 0x815000c2, IMS: 0x1a00004) 27563@1494850819.411900:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2, IMS: 0xa00004) 27563@1494850819.411915:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2, IMS: 0xa00004) 27563@1494850819.412380:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2, IMS: 0xa00004) 27563@1494850819.412395:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2, IMS: 0xa00004) 27563@1494850819.412436:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2, IMS: 0xa00004) 27563@1494850819.412441:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2, IMS: 0xa00004) 27563@1494850819.412998:e1000e_irq_pending_interrupts ICR PENDING: 0x1000000 (ICR: 0x815000c2, IMS: 0x1a00004) * This bug behaviour wasn't observed with the Linux driver. This commit solves: https://bugzilla.redhat.com/show_bug.cgi?id=1447935 https://bugzilla.redhat.com/show_bug.cgi?id=1449490 Cc: qemu-stable@nongnu.org Signed-off-by: NSameeh Jubran <sjubran@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com> (cherry picked from commit 82342e91) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Fam Zheng 提交于
This matches the qbus_set_hotplug_handler in realize, and it releases the final reference to the embedded VirtIODevice so that it is properly finalized. A use-after-free is fixed with this patch, indirectly: virtio_device_instance_finalize wasn't called at hot-unplug, and the vdev->listener would be a dangling pointer in the global and the per address space listener list. See also RHBZ 1449031. Cc: qemu-stable@nongnu.org Signed-off-by: NFam Zheng <famz@redhat.com> Message-Id: <20170518102808.30046-1-famz@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 2cbe2de5) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
According to section 2.1.2 of the virtio-1 specification: "The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that a reset is needed. If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET, the device MUST send a device configuration change notification to the driver." Commit "f5ed3663 virtio: stop virtqueue processing if device is broken" introduced a virtio_error() call that just does that: - internally mark the device as broken - set the DEVICE_NEEDS_RESET bit in the status - send a configuration change notification Unfortunately, virtio_notify_vector(), called by virtio_notify_config(), returns right away when the device is marked as broken and the notification isn't sent in this case. The spec doesn't say whether a broken device can send notifications in other situations or not. But since the driver isn't supposed to do anything but to reset the device, it makes sense to keep the check in virtio_notify_config(). Marking the device as broken AFTER the configuration change notification was sent is enough to fix the issue. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 66453cff) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Hervé Poussineau 提交于
- bs->total_sectors is the number of sectors of the whole disk - s->sector_count is the number of sectors of the FAT partition This fixes the following assert in qemu-img map: qemu-img.c:2641: get_block_status: Assertion `nb_sectors' failed. This also fixes an infinite loop in qemu-img convert. Fixes: 4480e0f9 Fixes: https://bugs.launchpad.net/qemu/+bug/1599539 Cc: qemu-stable@nongnu.org Signed-off-by: NHervé Poussineau <hpoussin@reactos.org> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 139921aa) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Alberto Garcia 提交于
The code that tries to reopen a BlockDriverState in stream_start() when the creation of a new block job fails crashes because it attempts to dereference a pointer that is known to be NULL. This is a regression introduced in a170a91f, likely because the code was copied from stream_complete(). Cc: qemu-stable@nongnu.org Reported-by: NKashyap Chamarthy <kchamart@redhat.com> Signed-off-by: NAlberto Garcia <berto@igalia.com> Tested-by: NKashyap Chamarthy <kchamart@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 525989a5) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
The curl driver has a ugly hack where, if it cannot find an empty CURLState, it just uses aio_poll to wait for one to be empty. This is probably buggy when used together with dataplane, and the simplest way to fix it is to use coroutines instead. A more immediate effect of the bug however is that it can cause a recursive call to curl_readv_bh_cb and recursively taking the BDRVCURLState mutex. This causes a deadlock. The fix is to unlock the mutex around aio_poll, but for cleanliness we should also take the mutex around all calls to curl_init_state, even if reaching the unlock/lock pair is impossible. The same is true for curl_clean_state. Reported-by: NKun Wei <kuwei@redhat.com> Tested-by: NRichard W.M. Jones <rjones@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Message-id: 20170515100059.15795-4-pbonzini@redhat.com Cc: qemu-stable@nongnu.org Cc: Jeff Cody <jcody@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NJeff Cody <jcody@redhat.com> (cherry picked from commit 456af346) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
All curl callbacks go through curl_multi_do, and hence are called with s->mutex held. Note that with comments, and make curl_read_cb drop the lock before invoking the callback. Likewise for curl_find_buf, where the callback can be invoked by the caller. Cc: qemu-stable@nongnu.org Reviewed-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Message-id: 20170515100059.15795-3-pbonzini@redhat.com Signed-off-by: NJeff Cody <jcody@redhat.com> (cherry picked from commit 34db05e7) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
curl_clean_state should only be called after all AIOCBs have been completed. This is not so obvious for the call from curl_detach_aio_context, so assert that. Cc: qemu-stable@nongnu.org Reviewed-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Message-id: 20170515100059.15795-2-pbonzini@redhat.com Signed-off-by: NJeff Cody <jcody@redhat.com> (cherry picked from commit 675a7756) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Filippov 提交于
Return value of read/write simcalls is not calculated correctly in case of operations crossing page boundary and in case of short reads/writes. Read and write simcalls should return the size of data actually read/written or -1 in case of error. Cc: qemu-stable@nongnu.org Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com> (cherry picked from commit 347ec030) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Filippov 提交于
Read and write simcalls map physical memory to access I/O buffers, but 'read' simcall need to map it for writing and 'write' simcall need to map it for reading, i.e. the opposite of what they do now. Fix that. Cc: qemu-stable@nongnu.org Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com> (cherry picked from commit 30c2afd1) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 John Snow 提交于
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1447551 If one tries to issue a block_resize while a guest is busy accessing the disk, it is possible that qemu may deadlock when invoking aio_poll from both the main loop and the iothread. Replace another instance of bdrv_drain_all that doesn't quite belong. Cc: qemu-stable@nongnu.org Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 698bdfa0) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
For one thing, this allows us to drop the error message generation from qemu-img.c and blockdev.c and instead have it unified in bdrv_truncate(). Signed-off-by: NMax Reitz <mreitz@redhat.com> Message-id: 20170328205129.15138-3-mreitz@redhat.com Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit ed3d2ec9) * prereq for 698bdfa0Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
This patch makes vhdx_create() always set errp in case of an error. It also adds errp parameters to vhdx_create_bat() and vhdx_create_new_region_table() so we can pass on the error object generated by blk_truncate() as of a future commit. Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com> Message-id: 20170328205129.15138-2-mreitz@redhat.com Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com> (cherry picked from commit 55b9392b) * prereq for 698bdfa0Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
- 01 8月, 2017 22 次提交
-
-
由 Anton Nefedov 提交于
On error path (like i/o error in one of the coroutines), it's required to - wait for coroutines completion before cleaning the common structures - reenter dependent coroutines so they ever finish Introduced in 2d9187bc. Cc: qemu-stable@nongnu.org Signed-off-by: NAnton Nefedov <anton.nefedov@virtuozzo.com> Reviewed-by: NPeter Lieven <pl@kamp.de> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit b91127ed) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Stefan Hajnoczi 提交于
The main loop uses aio_disable_external()/aio_enable_external() to temporarily disable processing of external AioContext clients like device emulation. This allows monitor commands to quiesce I/O and prevent the guest from submitting new requests while a monitor command is in progress. The aio_enable_external() API is currently broken when an IOThread is in aio_poll() waiting for fd activity when the main loop re-enables external clients. Incrementing ctx->external_disable_cnt does not wake the IOThread from ppoll(2) so fd processing remains suspended and leads to unresponsive emulated devices. This patch adds an aio_notify() call to aio_enable_external() so the IOThread is kicked out of ppoll(2) and will re-arm the file descriptors. The bug can be reproduced as follows: $ qemu -M accel=kvm -m 1024 \ -object iothread,id=iothread0 \ -device virtio-scsi-pci,iothread=iothread0,id=virtio-scsi-pci0 \ -drive if=none,id=drive0,aio=native,cache=none,format=raw,file=test.img \ -device scsi-hd,id=scsi-hd0,drive=drive0 \ -qmp tcp::5555,server,nowait $ scripts/qmp/qmp-shell localhost:5555 (qemu) blockdev-snapshot-sync device=drive0 snapshot-file=sn1.qcow2 mode=absolute-paths format=qcow2 After blockdev-snapshot-sync completes the SCSI disk will be unresponsive. This leads to request timeouts inside the guest. Reported-by: NQianqian Zhu <qizhu@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Message-id: 20170508180705.20609-1-stefanha@redhat.com Suggested-by: NFam Zheng <famz@redhat.com> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 321d1dba) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Zhiyong Yang 提交于
Qemu2.7~2.9 and vhost user for dpdk 17.02 release work together to cause failures of new connection when negotiating to set MQ. (one queue pair works well). Because there exist some bugs in qemu code when introducing VHOST_USER_PROTOCOL_F_REPLY_ACK to qemu. When vhost_user_set_mem_table is invoked to deal with the vhost message VHOST_USER_SET_MEM_TABLE for the second time, qemu indeed doesn't send the messge (The message needs to be sent only once)but still will be waiting for dpdk's reply ack, then, qemu is always freezing, while DPDK is always waiting for next vhost message from qemu. The patch aims to fix the bug, MQ can work well. The same bug is found in function vhost_user_net_set_mtu, it is fixed at the same time. DPDK related patch is as following: http://www.dpdk.org/dev/patchwork/patch/23955/Signed-off-by: NZhiyong Yang <zhiyong.yang@intel.com> Cc: qemu-stable@nongnu.org Fixes: ca525ce5 ("vhost-user: Introduce a new protocol feature REPLY_ACK.") Reviewed-by: NMaxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Tested-by: NJens Freimann <jfreiman@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> (cherry picked from commit 60cd1102) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Fam Zheng 提交于
Opening the backing image for the second time is bad, especially here when it is also in use as the active image as the source. The drive-backup job itself doesn't read from target->backing for COW, instead it gets data from the write notifier, so it's not a big problem. However, exporting the target to NBD etc. won't work, because of the likely stale metadata cache. Use BDRV_O_NO_BACKING in this case and manually set up the backing BdrvChild. Cc: qemu-stable@nongnu.org Signed-off-by: NFam Zheng <famz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit fc0932fd) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
We now have macros in place to make it less verbose to add a scalar to QDict and QList, so use them. Patch created mechanically via: spatch --sp-file scripts/coccinelle/qobject.cocci \ --macro-file scripts/cocci-macro-file.h --dir . --in-place then touched up manually to fix a couple of '?:' back to original spacing, as well as avoiding a long line in monitor.c. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20170427215821.19397-7-eblake@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NAlberto Garcia <berto@igalia.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> (cherry picked from commit 46f5ac20) * prereq for fc0932fdSigned-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
An upcoming Coccinelle cleanup script wanted to reformat the casts present in this file - but on closer look, we don't need the casts at all because C automatically converts void* to any other pointer. Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20170405194741.18956-4-eblake@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com> (cherry picked from commit cb55c19a) * prereq for 46f5ac20Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
Rather than making lots of callers wrap a scalar in a QInt, QString, or QBool, provide helper macros that do the wrapping automatically. Update the Coccinelle script to make mass conversions easy, although the conversion itself will be done as a separate patches to ease review and backport efforts. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20170427215821.19397-6-eblake@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> (cherry picked from commit a92c2159) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
We have macros in place to make it less verbose to add a subtype of QObject to both QDict and QList. While we have made cleanups like this in the past (see commit fcfcd8ff, for example), having it be automated by Coccinelle makes it easier to maintain. Patch created mechanically via: spatch --sp-file scripts/coccinelle/qobject.cocci \ --macro-file scripts/cocci-macro-file.h --dir . --in-place then I verified that no manual touchups were required. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NAlberto Garcia <berto@igalia.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20170427215821.19397-5-eblake@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> (cherry picked from commit de6e7951) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
We have macros in place to make it less verbose to add a subtype of QObject to both QDict and QList. While we have made cleanups like this in the past (see commit fcfcd8ff, for example), having it be automated by Coccinelle makes it easier to maintain. The script is separate from the cleanups, for ease of review and backporting. A later patch will then add further possible cleanups. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Message-Id: <20170427215821.19397-4-eblake@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> (cherry picked from commit a2f3453e) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
When trying to remove a file from a directory, both created in non-mapped mode, the file remains and EBADF is returned to the guest. This is a regression introduced by commit "df4938a6 9pfs: local: unlinkat: don't follow symlinks" when fixing CVE-2016-9602. It changed the way we unlink the metadata file from ret = remove("$dir/.virtfs_metadata/$name"); if (ret < 0 && errno != ENOENT) { /* Error out */ } /* Ignore absence of metadata */ to fd = openat("$dir/.virtfs_metadata") unlinkat(fd, "$name") if (ret < 0 && errno != ENOENT) { /* Error out */ } /* Ignore absence of metadata */ If $dir was created in non-mapped mode, openat() fails with ENOENT and we pass -1 to unlinkat(), which fails in turn with EBADF. We just need to check the return of openat() and ignore ENOENT, in order to restore the behaviour we had with remove(). Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NEric Blake <eblake@redhat.com> [groug: rewrote the comments as suggested by Eric] (cherry picked from commit 6a87e792) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Markus Armbruster 提交于
Broken in commit daa33c52. Cc: qemu-stable@nongnu.org Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NZhang Chen <zhangchen.fnst@cn.fujitsu.com> Message-id: 1493298053-17140-1-git-send-email-armbru@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 38bb54f3) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Bruce Rogers 提交于
Commit f0c9d64a exposed the issue that with a xenfv machine using pci passthrough, acpi pci hotplug code was being executed by mistake. Guard calls to acpi_pcihp_device_plug_cb (and corresponding acpi_pcihp_device_unplug_cb) with a check for xen_enabled(). Without this check I am seeing an error that the bus doesn't have the acpi-pcihp-bsel property set. Signed-off-by: NBruce Rogers <brogers@suse.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> (cherry picked from commit 153eba47) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
The block layer takes care of removing the bs->file child if the block driver's bdrv_open()/bdrv_file_open() implementation fails. The block driver therefore does not need to do so, and indeed should not unless it sets bs->file to NULL afterwards -- because if this is not done, the bdrv_unref_child() in bdrv_open_inherit() will dereference the freed memory block at bs->file afterwards, which is not good. We can now decide whether to add a "bs->file = NULL;" after each of the offending bdrv_unref_child() invocations, or just drop them altogether. The latter is simpler, so let's do that. Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit de234897) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Herongguang (Stephen) 提交于
If a pci device is not reset by VM (by writing into config space) and unplugged by VM, after that when VM reboots, qemu may assert: pcibus_reset: Assertion `bus->irq_count[i] == 0' failed Cc: qemu-stable@nongnu.org Signed-off-by: Nherongguang <herongguang.he@huawei.com> Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> (cherry picked from commit 3936161f) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Daniel P. Berrange 提交于
Historically the migration data channel has only needed to be unidirectional. Thus the 'exec:' protocol was requesting an I/O channel with O_RDONLY on incoming side, and O_WRONLY on the outgoing side. This is fine for classic migration, but if you then try to run TLS over it, this fails because the TLS handshake requires a bi-directional channel. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com> (cherry picked from commit 062d81f0) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 42dc10f1) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
Reproducer: $ ./qemu-img info '' qemu-img: ./block.c:1008: bdrv_open_driver: Assertion `!drv->bdrv_needs_filename || bs->filename[0]' failed. [1] 26105 abort (core dumped) ./qemu-img info '' This patch fixes this to be: $ ./qemu-img info '' qemu-img: Could not open '': The 'file' block driver requires a file name Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 4a008240) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
It does not make much sense to use a backing image for the target when you concatenate multiple images (because then there is no correspondence between the source images' backing files and the target's); but it was still possible to give one by using -o backing_file=X instead of -B X. Fix this by moving the check. (Also, change the error message because -B is not the only way to specify the backing file, evidently.) Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> * applied patch from v1 of series as suggested by author Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
After storing the creation options for the new image into @opts, we fetch some things for our own information, like the backing file name, or whether to use encryption or preallocation. With the -n parameter, there will not be any creation options; this is not too bad because this just means that querying a NULL @opts will always return the default value. However, we also use @opts for the --object options. Therefore, @opts is not necessarily NULL if -n was specified; instead, it may contain those options. In practice, this probably does not cause any problems because there most likely is no object that supports any of the parameters we query here, but this is neither something we should rely on nor does this variable reuse make the code very nice to read. Therefore, just use an own variable for the --object options. Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> * applied patch from v1 of series as suggested by author Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Reitz 提交于
Otherwise the qemu-img process will exit with EXIT_SUCCESS instead of EXIT_FAILURE. Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> * applied directly to stable, upstream code has issue fixed via a refactoring introduced by 9fd77f99, which isn't targetted for stable Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
We've been documenting the value in bytes since its introduction in commit b9a9b3a4 (v1.3), where it was actually reported in bytes. Commit e4654d2d (v2.0) then removed things from block/qapi.c, in preparation for a rewrite to a list of dirty sectors in the next commit 21b56835 in block.c, but the new code mistakenly started reporting in sectors. Fixes: https://bugzilla.redhat.com/1441460 CC: qemu-stable@nongnu.org Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 6c98c57a) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Sameeh Jubran 提交于
The QGA schema states: @can-offline: Whether offlining the VCPU is possible. This member is always filled in by the guest agent when the structure is returned, and always ignored on input (hence it can be omitted then). Currently 'can-offline' is missing entirely from the reply. This causes errors in libvirt which is expecting the reply to be compliant with the schema docs. BZ#1438735: https://bugzilla.redhat.com/show_bug.cgi?id=1438735Signed-off-by: NSameeh Jubran <sameeh@daynix.com> Reviewed-by: NEric Blake <eblake@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com> (cherry picked from commit 54858553) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
- 20 4月, 2017 1 次提交
-
-
由 Peter Maydell 提交于
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 19 4月, 2017 1 次提交
-
-
由 Peter Maydell 提交于
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 18 4月, 2017 3 次提交
-
-
由 Peter Maydell 提交于
# gpg: Signature made Tue 18 Apr 2017 15:58:32 BST # gpg: using RSA key 0xCA35624C6A9171C6 # gpg: Good signature from "Fam Zheng <famz@redhat.com>" # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 5003 7CB7 9706 0F76 F021 AD56 CA35 624C 6A91 71C6 * remotes/famz/tags/block-pull-request: block: Drain BH in bdrv_drained_begin block: Walk bs->children carefully in bdrv_drain_recurse Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Fam Zheng 提交于
During block job completion, nothing is preventing block_job_defer_to_main_loop_bh from being called in a nested aio_poll(), which is a trouble, such as in this code path: qmp_block_commit commit_active_start bdrv_reopen bdrv_reopen_multiple bdrv_reopen_prepare bdrv_flush aio_poll aio_bh_poll aio_bh_call block_job_defer_to_main_loop_bh stream_complete bdrv_reopen block_job_defer_to_main_loop_bh is the last step of the stream job, which should have been "paused" by the bdrv_drained_begin/end in bdrv_reopen_multiple, but it is not done because it's in the form of a main loop BH. Similar to why block jobs should be paused between drained_begin and drained_end, BHs they schedule must be excluded as well. To achieve this, this patch forces draining the BH in BDRV_POLL_WHILE. As a side effect this fixes a hang in block_job_detach_aio_context during system_reset when a block job is ready: #0 0x0000555555aa79f3 in bdrv_drain_recurse #1 0x0000555555aa825d in bdrv_drained_begin #2 0x0000555555aa8449 in bdrv_drain #3 0x0000555555a9c356 in blk_drain #4 0x0000555555aa3cfd in mirror_drain #5 0x0000555555a66e11 in block_job_detach_aio_context #6 0x0000555555a62f4d in bdrv_detach_aio_context #7 0x0000555555a63116 in bdrv_set_aio_context #8 0x0000555555a9d326 in blk_set_aio_context #9 0x00005555557e38da in virtio_blk_data_plane_stop #10 0x00005555559f9d5f in virtio_bus_stop_ioeventfd #11 0x00005555559fa49b in virtio_bus_stop_ioeventfd #12 0x00005555559f6a18 in virtio_pci_stop_ioeventfd #13 0x00005555559f6a18 in virtio_pci_reset #14 0x00005555559139a9 in qdev_reset_one #15 0x0000555555916738 in qbus_walk_children #16 0x0000555555913318 in qdev_walk_children #17 0x0000555555916738 in qbus_walk_children #18 0x00005555559168ca in qemu_devices_reset #19 0x000055555581fcbb in pc_machine_reset #20 0x00005555558a4d96 in qemu_system_reset #21 0x000055555577157a in main_loop_should_exit #22 0x000055555577157a in main_loop #23 0x000055555577157a in main The rationale is that the loop in block_job_detach_aio_context cannot make any progress in pausing/completing the job, because bs->in_flight is 0, so bdrv_drain doesn't process the block_job_defer_to_main_loop BH. With this patch, it does. Reported-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NFam Zheng <famz@redhat.com> Message-Id: <20170418143044.12187-3-famz@redhat.com> Reviewed-by: NJeff Cody <jcody@redhat.com> Tested-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NFam Zheng <famz@redhat.com>
-
由 Fam Zheng 提交于
The recursive bdrv_drain_recurse may run a block job completion BH that drops nodes. The coming changes will make that more likely and use-after-free would happen without this patch Stash the bs pointer and use bdrv_ref/bdrv_unref in addition to QLIST_FOREACH_SAFE to prevent such a case from happening. Since bdrv_unref accesses global state that is not protected by the AioContext lock, we cannot use bdrv_ref/bdrv_unref unconditionally. Fortunately the protection is not needed in IOThread because only main loop can modify a graph with the AioContext lock held. Signed-off-by: NFam Zheng <famz@redhat.com> Message-Id: <20170418143044.12187-2-famz@redhat.com> Reviewed-by: NJeff Cody <jcody@redhat.com> Tested-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NFam Zheng <famz@redhat.com>
-