- Aug 28, 2020
-
-
Zhenyu Ye authored
Currently migration_tls_get_creds() adds the reference of creds but there was no place to unref it. So the OBJECT(creds) will never be freed and result in memory leak. The leak stack: Direct leak of 104 byte(s) in 1 object(s) allocated from: #0 0xffffa88bd20b in __interceptor_malloc (/usr/lib64/libasan.so.4+0xd320b) #1 0xffffa7f0cb1b in g_malloc (/usr/lib64/libglib-2.0.so.0+0x58b1b) #2 0x14b58cb in object_new_with_type qom/object.c:634 #3 0x14b597b in object_new qom/object.c:645 #4 0x14c0e4f in user_creatable_add_type qom/object_interfaces.c:59 #5 0x141c78b in qmp_object_add qom/qom-qmp-cmds.c:312 #6 0x140e513 in qmp_marshal_object_add qapi/qapi-commands-qom.c:279 #7 0x176ba97 in do_qmp_dispatch qapi/qmp-dispatch.c:165 #8 0x176bee7 in qmp_dispatch qapi/qmp-dispatch.c:208 #9 0x136e337 in monitor_qmp_dispatch monitor/qmp.c:150 #10 0x136eae3 in monitor_qmp_bh_dispatcher monitor/qmp.c:239 #11 0x1852e93 in aio_bh_call util/async.c:89 #12 0x18531b7 in aio_bh_poll util/async.c:117 #13 0x18616bf in aio_dispatch util/aio-posix.c:459 #14 0x1853f37 in aio_ctx_dispatch util/async.c:268 #15 0xffffa7f06a7b in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x52a7b) Since we're fine to use the borrowed reference when using the creds, so just remove the object_ref() in migration_tls_get_creds(). Signed-off-by:
Zhenyu Ye <yezhenyu2@huawei.com> Message-Id: <20200722033228.71-1-yezhenyu2@huawei.com> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
Daniel P. Berrangé authored
With blockdev, a BlockDriverState may not have a device name, so using a node name is required as an alternative. Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200827111606.1408275-2-berrange@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
Longpeng (Mike) authored
The vsock channel is more widely use in some new features, for example, the Nitro/Enclave. It can also be used as the migration channel. Signed-off-by:
Longpeng(Mike) <longpeng2@huawei.com> Message-Id: <20200806074030.174-3-longpeng2@huawei.com> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
Longpeng (Mike) authored
Currently, the only difference of tcp channel and unix channel in migration/socket.c is the way to build SocketAddress, but socket_parse() can handle these two types, so use it to instead of tcp_build_address() and unix_build_address(). The socket-type channel can be further unified based on the up, this would be helpful for us to add other socket-type channels. Signed-off-by:
Longpeng(Mike) <longpeng2@huawei.com> Message-Id: <20200806074030.174-2-longpeng2@huawei.com> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
- Aug 27, 2020
-
-
Eduardo Habkost authored
Rename the macros to make them consistent with the MIGRATION_OBJ macro name. This will make future conversion to OBJECT_DECLARE* easier. Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Tested-By:
Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200825192110.3528606-51-ehabkost@redhat.com> Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com>
-
- Aug 21, 2020
-
-
Hanna Reitz authored
This migration parameter allows mapping block node names and bitmap names to aliases for the purpose of block dirty bitmap migration. This way, management tools can use different node and bitmap names on the source and destination and pass the mapping of how bitmaps are to be transferred to qemu (on the source, the destination, or even both with arbitrary aliases in the migration stream). While touching this code, fix a bug where bitmap names longer than 255 bytes would fail an assertion in qemu_put_counted_string(). Suggested-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by:
Max Reitz <mreitz@redhat.com> Message-Id: <20200820150725.68687-2-mreitz@redhat.com> Reviewed-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Marc-André Lureau authored
Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Meson doesn't enjoy the same flexibility we have with Make in choosing the include path. In particular the tracing headers are using $(build_root)/$(<D). In order to keep the include directives unchanged, the simplest solution is to generate headers with patterns like "trace/trace-audio.h" and place forwarding headers in the source tree such that for example "audio/trace.h" includes "trace/trace-audio.h". This patch is too ugly to be applied to the Makefiles now. It's only a way to separate the changes to the tracing header files from the Meson rewrite of the tracing logic. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jul 27, 2020
-
-
Eric Blake authored
Noticed while reviewing the file for newer patches. Fixes: b35ebdf0 Signed-off-by:
Eric Blake <eblake@redhat.com> Message-Id: <20200727203206.134996-1-eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
First, if only bitmaps postcopy is enabled (and not ram postcopy) postcopy_pause_incoming crashes on an assertion assert(mis->to_src_file). And anyway, bitmaps postcopy is not prepared to be somehow recovered. The original idea instead is that if bitmaps postcopy failed, we just lose some bitmaps, which is not critical. So, on failure we just need to remove unfinished bitmaps and guest should continue execution on destination. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Message-Id: <20200727194236.19551-18-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
If target is turned off prior to postcopy finished, target crashes because busy bitmaps are found at shutdown. Canceling incoming migration helps, as it removes all unfinished (and therefore busy) bitmaps. Similarly on source we crash in bdrv_close_all which asserts that all bdrv states are removed, because bdrv states involved into dirty bitmap migration are referenced by it. So, we need to cancel outgoing migration as well. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Message-Id: <20200727194236.19551-17-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
Bitmaps data is not critical, and we should not fail the migration (or use postcopy recovering) because of dirty-bitmaps migration failure. Instead we should just lose unfinished bitmaps. Still we have to report io stream violation errors, as they affect the whole migration stream. While touching this, tighten code that was previously blindly calling malloc on a size read from the migration stream, as a corrupted stream (perhaps from a malicious user) should not be able to convince us to allocate an inordinate amount of memory. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200727194236.19551-16-vsementsov@virtuozzo.com> Reviewed-by:
Eric Blake <eblake@redhat.com> [eblake: typo fixes, enhance commit message] Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
Keep bitmap state for disabled bitmaps too. Keep the state until the end of the process. It's needed for the following commit to implement bitmap postcopy canceling. To clean-up the new list the following logic is used: We need two events to consider bitmap migration finished: 1. chunk with DIRTY_BITMAP_MIG_FLAG_COMPLETE flag should be received 2. dirty_bitmap_mig_before_vm_start should be called These two events may come in any order, so we understand which one is last, and on the last of them we remove bitmap migration state from the list. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Message-Id: <20200727194236.19551-15-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
bdrv_enable_dirty_bitmap_locked() call does nothing, as if we are in postcopy, bitmap successor must be enabled, and reclaim operation will enable the bitmap. So, actually we need just call _reclaim_ in both if branches, and making differences only to add an assertion seems not really good. The logic becomes simple: on load complete we do reclaim and that's all. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Message-Id: <20200727194236.19551-14-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
finish_lock is bad name, as lock used not only on process end. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Message-Id: <20200727194236.19551-13-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
Move all state variables into one global struct. Reduce global variable usage, utilizing opaque pointer where possible. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Message-Id: <20200727194236.19551-12-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
No reasons to keep two public init functions. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200727194236.19551-11-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
Rename dirty_bitmap_mig_cleanup to dirty_bitmap_do_save_cleanup, to stress that it is on save part. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Message-Id: <20200727194236.19551-10-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
Rename types to be symmetrical for load/save part and shorter. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Message-Id: <20200727194236.19551-9-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Vladimir Sementsov-Ogievskiy authored
Using the _locked version of bdrv_enable_dirty_bitmap to bypass locking is wrong as we do not already own the mutex. Moreover, the adjacent call to bdrv_dirty_bitmap_enable_successor grabs the mutex. Fixes: 58f72b965e9e1q Cc: qemu-stable@nongnu.org # v3.0 Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Message-Id: <20200727194236.19551-8-vsementsov@virtuozzo.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
- Jul 17, 2020
-
-
Vladimir Sementsov-Ogievskiy authored
We shouldn't fail when finding an unnamed bitmap in a unnamed node or node with auto-generated node name, as bitmap migration ignores such bitmaps in the first place. Fixes: 82640edb Fixes: 4ff5cc12 Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200626130658.76498-1-vsementsov@virtuozzo.com> Reviewed-by:
Eric Blake <eblake@redhat.com> [eblake: commit message grammar tweaks] Signed-off-by:
Eric Blake <eblake@redhat.com>
-
- Jul 13, 2020
-
-
Liao Pingfang authored
Remove superfluous breaks, as there is a "return" before them. Signed-off-by:
Liao Pingfang <liao.pingfang@zte.com.cn> Signed-off-by:
Yi Wang <wang.yi59@zte.com.cn> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Denis V. Lunev authored
qemu_fclose() could return error, f.e. if bdrv_co_flush() will return the error. This validation will become more important once we will start waiting of asynchronous IO operations, started from bdrv_write_vmstate(), which are coming soon. Signed-off-by:
Denis V. Lunev <den@openvz.org> Reviewed-by:
"Dr. David Alan Gilbert" <dgilbert@redhat.com> Reviewed-by:
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> CC: Kevin Wolf <kwolf@redhat.com> CC: Max Reitz <mreitz@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com> CC: Fam Zheng <fam@euphon.net> CC: Juan Quintela <quintela@redhat.com> CC: Denis Plotnikov <dplotnikov@virtuozzo.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Zheng Chuan authored
"tmp.tls_hostname" and "tmp.tls_creds" allocated by migrate_params_test_apply() is forgot to free at the end of qmp_migrate_set_parameters(). Fix that. The leak stack: Direct leak of 2 byte(s) in 2 object(s) allocated from: #0 0xffffb597c20b in __interceptor_malloc (/usr/lib64/libasan.so.4+0xd320b) #1 0xffffb52dcb1b in g_malloc (/usr/lib64/libglib-2.0.so.0+0x58b1b) #2 0xffffb52f8143 in g_strdup (/usr/lib64/libglib-2.0.so.0+0x74143) #3 0xaaaac52447fb in migrate_params_test_apply (/usr/src/debug/qemu-4.1.0/migration/migration.c:1377) #4 0xaaaac52fdca7 in qmp_migrate_set_parameters (/usr/src/debug/qemu-4.1.0/qapi/qapi-commands-migration.c:192) #5 0xaaaac551d543 in qmp_dispatch (/usr/src/debug/qemu-4.1.0/qapi/qmp-dispatch.c:165) #6 0xaaaac52a0a8f in qmp_dispatch (/usr/src/debug/qemu-4.1.0/monitor/qmp.c:125) #7 0xaaaac52a1c7f in monitor_qmp_dispatch (/usr/src/debug/qemu-4.1.0/monitor/qmp.c:214) #8 0xaaaac55cb0cf in aio_bh_call (/usr/src/debug/qemu-4.1.0/util/async.c:117) #9 0xaaaac55d4543 in aio_bh_poll (/usr/src/debug/qemu-4.1.0/util/aio-posix.c:459) #10 0xaaaac55cae0f in aio_dispatch (/usr/src/debug/qemu-4.1.0/util/async.c:268) #11 0xffffb52d6a7b in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x52a7b) #12 0xaaaac55d1e3b(/usr/bin/qemu-kvm-4.1.0+0x1622e3b) #13 0xaaaac4e314bb(/usr/bin/qemu-kvm-4.1.0+0xe824bb) #14 0xaaaac47f45ef(/usr/bin/qemu-kvm-4.1.0+0x8455ef) #15 0xffffb4bfef3f in __libc_start_main (/usr/lib64/libc.so.6+0x23f3f) #16 0xaaaac47ffacb(/usr/bin/qemu-kvm-4.1.0+0x850acb) Direct leak of 2 byte(s) in 2 object(s) allocated from: #0 0xffffb597c20b in __interceptor_malloc (/usr/lib64/libasan.so.4+0xd320b) #1 0xffffb52dcb1b in g_malloc (/usr/lib64/libglib-2.0.so.0+0x58b1b) #2 0xffffb52f8143 in g_strdup (/usr/lib64/libglib-2.0.so.0+0x74143) #3 0xaaaac5244893 in migrate_params_test_apply (/usr/src/debug/qemu-4.1.0/migration/migration.c:1382) #4 0xaaaac52fdca7 in qmp_migrate_set_parameters (/usr/src/debug/qemu-4.1.0/qapi/qapi-commands-migration.c:192) #5 0xaaaac551d543 in qmp_dispatch (/usr/src/debug/qemu-4.1.0/qapi/qmp-dispatch.c) #6 0xaaaac52a0a8f in qmp_dispatch (/usr/src/debug/qemu-4.1.0/monitor/qmp.c:125) #7 0xaaaac52a1c7f in monitor_qmp_dispatch (/usr/src/debug/qemu-4.1.0/monitor/qmp.c:214) #8 0xaaaac55cb0cf in aio_bh_call (/usr/src/debug/qemu-4.1.0/util/async.c:117) #9 0xaaaac55d4543 in aio_bh_poll (/usr/src/debug/qemu-4.1.0/util/aio-posix.c:459) #10 0xaaaac55cae0f in in aio_dispatch (/usr/src/debug/qemu-4.1.0/util/async.c:268) #11 0xffffb52d6a7b in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x52a7b) #12 0xaaaac55d1e3b(/usr/bin/qemu-kvm-4.1.0+0x1622e3b) #13 0xaaaac4e314bb(/usr/bin/qemu-kvm-4.1.0+0xe824bb) #14 0xaaaac47f45ef (/usr/bin/qemu-kvm-4.1.0+0x8455ef) #15 0xffffb4bfef3f in __libc_start_main (/usr/lib64/libc.so.6+0x23f3f) #16 0xaaaac47ffacb(/usr/bin/qemu-kvm-4.1.0+0x850acb) Signed-off-by:
Chuan Zheng <zhengchuan@huawei.com> Reviewed-by:
KeQian Zhu <zhukeqian1@huawei.com> Reviewed-by:
HaiLiang <zhang.zhanghailiang@huawei.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
- Jul 10, 2020
-
-
Claudio Fontana authored
move the vcpu throttling functionality into its own module. This functionality is not specific to any accelerator, and it is used currently by migration to slow down guests to try to have migrations converge, and by the cocoa MacOS UI to throttle speed. cpu-throttle contains the controls to adjust and inspect throttle settings, start (set) and stop vcpu throttling, and the throttling function itself that is run periodically on vcpus to make them take a nap. Execution of the throttling function on all vcpus is triggered by a timer, registered at module initialization. No functionality change. Signed-off-by:
Claudio Fontana <cfontana@suse.de> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Laurent Vivier <lvivier@redhat.com> Message-Id: <20200629093504.3228-3-cfontana@suse.de> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jul 03, 2020
-
-
Keqian Zhu authored
real_dirty_pages becomes equal to total ram size after dirty log sync in ram_init_bitmaps, the reason is that the bitmap of ramblock is initialized to be all set, so old path counts them as "real dirty" at beginning. This causes wrong dirty rate and false positive throttling. Signed-off-by:
Keqian Zhu <zhukeqian1@huawei.com> Message-Id: <20200622032037.31112-1-zhukeqian1@huawei.com> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
Dr. David Alan Gilbert authored
This function returns a boolean success and we're returning -1; lets just use the 'out' error path. Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Fixes: 58b7c17e ("Disable mlock around incoming postcopy") Buglink: https://bugs.launchpad.net/qemu/+bug/1885720 Message-Id: <20200701093557.130096-1-dgilbert@redhat.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
- Jul 02, 2020
-
-
David Hildenbrand authored
COLO will copy all memory in a RAM block, disable discarding of RAM. Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Tested-by:
Lukas Straub <lukasstraub2@web.de> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Hailiang Zhang <zhang.zhanghailiang@huawei.com> Cc: Juan Quintela <quintela@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-10-david@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
David Hildenbrand authored
RDMA will pin all guest memory (as documented in docs/rdma.txt). We want to disable RAM block discards - however, to keep it simple use ram_block_discard_is_required() instead of inhibiting. Note: It is not sufficient to limit disabling to pin_all. Even when only conditionally pinning 1 MB chunks, as soon as one page within such a chunk was discarded and one page not, the discarded pages will be pinned as well. Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-9-david@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
David Hildenbrand authored
The only remaining special case is postcopy. It cannot handle concurrent discards yet, which would result in requesting already sent pages from the source. Special-case it in virtio-balloon instead. Introduce migration_in_incoming_postcopy(), to find out if incoming postcopy is active. Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20200626072248.78761-7-david@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
Markus Armbruster authored
qemu_rdma_registration_stop() uses the ERROR() macro to create, report to stderr, and store an Error object. The stored Error object is never used, and its memory is leaked. Even where ERROR() doesn't leak, it is ill-advised. The whole point of passing an Error to the caller is letting the caller handle the error. Error handling may report to stderr, to somewhere else, or not at all. Also reporting in the callee mixes up concerns that should be kept separate. Since I don't know what reporting to stderr is supposed to accomplish, I'm not touching it. Commit 2a1bc8bd "migration/rdma: rdma_accept_incoming_migration fix error handling" plugged the same leak in rdma_accept_incoming_migration(). Plug the memory leak the same way: keep the report part, delete the store part. The report part uses fprintf(). If it's truly an error, it should use error_report() instead. But I don't know, so I leave it alone, just like commit 2a1bc8bd did. Fixes: 2da776db Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Signed-off-by:
Markus Armbruster <armbru@redhat.com> Message-Id: <20200630090351.1247703-27-armbru@redhat.com> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
- Jun 26, 2020
-
-
Eric Blake authored
I'm not aware of any immediate bugs in qemu where a second runtime evaluation of the arguments to MIN() or MAX() causes a problem, but proactively preventing such abuse is easier than falling prey to an unintended case down the road. At any rate, here's the conversation that sparked the current patch: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg05718.html Update the MIN/MAX macros to only evaluate their argument once at runtime; this uses typeof(1 ? (a) : (b)) to ensure that we are promoting the temporaries to the same type as the final comparison (we have to trigger type promotion, as typeof(bitfield) won't compile; and we can't use typeof((a) + (b)) or even typeof((a) + 0), as some of our uses of MAX are on void* pointers where such addition is undefined). However, we are unable to work around gcc refusing to compile ({}) in a constant context (such as the array length of a static variable), even when only used in the dead branch of a __builtin_choose_expr(), so we have to provide a second macro pair MIN_CONST and MAX_CONST for use when both arguments are known to be compile-time constants and where the result must also be usable as a constant; this second form evaluates arguments multiple times but that doesn't matter for constants. By using a void expression as the expansion if a non-constant is presented to this second form, we can enlist the compiler to ensure the double evaluation is not attempted on non-constants. Alas, as both macros now rely on compiler intrinsics, they are no longer usable in preprocessor #if conditions; those will just have to be open-coded or the logic rewritten into #define or runtime 'if' conditions (but where the compiler dead-code-elimination will probably still apply). I tested that both gcc 10.1.1 and clang 10.0.0 produce errors for all forms of macro mis-use. As the errors can sometimes be cryptic, I'm demonstrating the gcc output: Use of MIN when MIN_CONST is needed: In file included from /home/eblake/qemu/qemu-img.c:25: /home/eblake/qemu/include/qemu/osdep.h:249:5: error: braced-group within expression allowed only inside a function 249 | ({ \ | ^ /home/eblake/qemu/qemu-img.c:92:12: note: in expansion of macro ‘MIN’ 92 | char array[MIN(1, 2)] = ""; | ^~~ Use of MIN_CONST when MIN is needed: /home/eblake/qemu/qemu-img.c: In function ‘is_allocated_sectors’: /home/eblake/qemu/qemu-img.c:1225:15: error: void value not ignored as it ought to be 1225 | i = MIN_CONST(i, n); | ^ Use of MIN in the preprocessor: In file included from /home/eblake/qemu/accel/tcg/translate-all.c:20: /home/eblake/qemu/accel/tcg/translate-all.c: In function ‘page_check_range’: /home/eblake/qemu/include/qemu/osdep.h:249:6: error: token "{" is not valid in preprocessor expressions 249 | ({ \ | ^ Fix the resulting callsites that used #if or computed a compile-time constant min or max to use the new macros. cpu-defs.h is interesting, as CPU_TLB_DYN_MAX_BITS is sometimes used as a constant and sometimes dynamic. It may be worth improving glib's MIN/MAX definitions to be saner, but that is a task for another day. Signed-off-by:
Eric Blake <eblake@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200625162602.700741-1-eblake@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 18, 2020
-
-
Wei Wang authored
It's reported an error of implicit conversion from "unsigned long" to "double" when compiling with Clang 10. Simply make the encoding rate 0 when the encoded_size is 0. Fixes: e460a4b1 Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Reported-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
Wei Wang <wei.w.wang@intel.com> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Message-id: 20200617201309.1640952-3-richard.henderson@linaro.org Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Jun 17, 2020
-
-
Laurent Vivier authored
multifd_send_pages() loops around the available channels, the next channel to use between two calls to multifd_send_pages() is stored inside a local static variable, next_channel. It works well, except if the number of channels decreases between two calls to multifd_send_pages(). In this case, the loop can try to access the data of a channel that doesn't exist anymore. The problem can be triggered if we start a migration with a given number of channels and then we cancel the migration to restart it with a lower number. This ends generally with an error like: qemu-system-ppc64: .../util/qemu-thread-posix.c:77: qemu_mutex_lock_impl: Assertion `mutex->initialized' failed. This patch fixes the error by capping next_channel with the current number of channels before using it. Signed-off-by:
Laurent Vivier <lvivier@redhat.com> Message-Id: <20200617113154.593233-1-lvivier@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
- Jun 15, 2020
-
-
Markus Armbruster authored
Signed-off-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200610053247.1583243-31-armbru@redhat.com>
-
- Jun 10, 2020
-
-
Philippe Mathieu-Daudé authored
This code is not related to hardware emulation. Move it under accel/ with the other hypervisors. Reviewed-by:
Paul Durrant <paul@xen.org> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200508100222.7112-1-philmd@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 01, 2020
-
-
Lukas Straub authored
migration_rate_limit will erroneously ratelimit a shutdown socket, which causes the migration thread to hang in ram_save_host_page if the socket is shutdown. Fix this by explicitly testing if the socket has errors or was shutdown in migration_rate_limit. Signed-off-by:
Lukas Straub <lukasstraub2@web.de> Message-Id: <e79085bbe2d46dfa007dd41820194d5e2d4fcd80.1590007004.git.lukasstraub2@web.de> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
Lukas Straub authored
If the secondary has to failover during checkpointing, it still is in the old state (i.e. different state than primary). Thus we can't expose the primary state until after the checkpoint is sent. This fixes sporadic connection reset of client connections during failover. Signed-off-by:
Lukas Straub <lukasstraub2@web.de> Message-Id: <d4555dd5146a54518c4d9d4efd996b7c745c6687.1589193382.git.lukasstraub2@web.de> Reviewed-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
Lukas Straub authored
If vmstate_loading is true, secondary_vm_do_failover will set failover status to FAILOVER_STATUS_RELAUNCH and return success without initiating failover. However, if there is an error during the vmstate_loading section, failover isn't relaunched. Instead we then wait for failover on colo_incoming_sem. Fix this by relaunching failover even if there was an error. Also, to make this work properly, set vmstate_loading to false when returning during the vmstate_loading section. Signed-off-by:
Lukas Straub <lukasstraub2@web.de> Message-Id: <f60b0a8e2fadaaec792e04819dfc46951842d6ba.1589193382.git.lukasstraub2@web.de> Reviewed-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
Lukas Straub authored
If we suceed in receiving ram state, but fail receiving the device state, there will be a mismatch between the two. Fix this by flushing the ram cache only after the vmstate has been received. Signed-off-by:
Lukas Straub <lukasstraub2@web.de> Message-Id: <3289d007d494cb0e2f05b1cf4ae6a78d300fede3.1589193382.git.lukasstraub2@web.de> Reviewed-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-