aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-31block/mirror: set actively_synced even after the job is readyFiona Ebner
In preparation to allow switching from background to active mode. This ensures that setting actively_synced will not be missed when the switch happens after the job is ready. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20231031135431.393137-3-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31blockjob: introduce block-job-change QMP commandFiona Ebner
which will allow changing job-type-specific options after job creation. In the JobVerbTable, the same allow bits as for set-speed are used, because set-speed can be considered an existing change command. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-ID: <20231031135431.393137-2-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31virtio-blk: remove batch notification BHStefan Hajnoczi
There is a batching mechanism for virtio-blk Used Buffer Notifications that is no longer needed because the previous commit added batching to virtio_notify_irqfd(). Note that this mechanism was rarely used in practice because it is only enabled when EVENT_IDX is not negotiated by the driver. Modern drivers enable EVENT_IDX. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230913200045.1024233-5-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31virtio: use defer_call() in virtio_irqfd_notify()Stefan Hajnoczi
virtio-blk and virtio-scsi invoke virtio_irqfd_notify() to send Used Buffer Notifications from an IOThread. This involves an eventfd write(2) syscall. Calling this repeatedly when completing multiple I/O requests in a row is wasteful. Use the defer_call() API to batch together virtio_irqfd_notify() calls made during thread pool (aio=threads), Linux AIO (aio=native), and io_uring (aio=io_uring) completion processing. Behavior is unchanged for emulated devices that do not use defer_call_begin()/defer_call_end() since defer_call() immediately invokes the callback when called outside a defer_call_begin()/defer_call_end() region. fio rw=randread bs=4k iodepth=64 numjobs=8 IOPS increases by ~9% with a single IOThread and 8 vCPUs. iodepth=1 decreases by ~1% but this could be noise. Detailed performance data and configuration specifics are available here: https://gitlab.com/stefanha/virt-playbooks/-/tree/blk_io_plug-irqfd This duplicates the BH that virtio-blk uses for batching. The next commit will remove it. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230913200045.1024233-4-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31util/defer-call: move defer_call() to util/Stefan Hajnoczi
The networking subsystem may wish to use defer_call(), so move the code to util/ where it can be reused. As a reminder of what defer_call() does: This API defers a function call within a defer_call_begin()/defer_call_end() section, allowing multiple calls to batch up. This is a performance optimization that is used in the block layer to submit several I/O requests at once instead of individually: defer_call_begin(); <-- start of section ... defer_call(my_func, my_obj); <-- deferred my_func(my_obj) call defer_call(my_func, my_obj); <-- another defer_call(my_func, my_obj); <-- another ... defer_call_end(); <-- end of section, my_func(my_obj) is called once Suggested-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230913200045.1024233-3-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31block: rename blk_io_plug_call() API to defer_call()Stefan Hajnoczi
Prepare to move the blk_io_plug_call() API out of the block layer so that other subsystems call use this deferred call mechanism. Rename it to defer_call() but leave the code in block/plug.c. The next commit will move the code out of the block layer. Suggested-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Paul Durrant <paul@xen.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230913200045.1024233-2-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31contrib/plugins: Close file descriptor on error returnCong Liu
This patch closes the file descriptor fd on error return to avoid resource leak. Fixes: ec7ee95db909 ("contrib/plugins: fix coverity warning in lockstep") Signed-off-by: Cong Liu <liucong2@kylinos.cn> Message-Id: <20231018025225.1640122-1-liucong2@kylinos.cn> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-20-alex.bennee@linaro.org>
2023-10-31plugins: Remove an extra parameterAkihiko Odaki
copy_call() has an unused parameter so remove it. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20231019101030.128431-7-akihiko.odaki@daynix.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231029145033.592566-19-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2023-10-31semihosting: fix memleak at semihosting_arg_fallbackMatheus Tavares Bernardino
We duplicate "cmd" as strtok may modify its argument, but we forgot to free it later. Furthermore, add_semihosting_arg doesn't take responsibility for this memory either (it strdup's the argument). Signed-off-by: Matheus Tavares Bernardino <quic_mathbern@quicinc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <03d81c56bfc3d08224e4106efca5949d8894cfa5.1697801632.git.quic_mathbern@quicinc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-18-alex.bennee@linaro.org>
2023-10-31gdbstub: Check if gdb_regs is NULLAkihiko Odaki
cpu->gdb_regs may be NULL if no coprocessor is registered. Fixes: 73c392c26b ("gdbstub: Replace gdb_regs with an array") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20231029145033.592566-17-alex.bennee@linaro.org> Message-Id: <20231019101030.128431-2-akihiko.odaki@daynix.com> Tested-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2023-10-31tests/docker: upgrade debian-all-test-cross to bookwormAlex Bennée
This requires a few more tweaks than usual as: - the default sources format has changed - bring in python3-tomli from the repos - split base install from cross compilers - also include libclang-rt-dev for sanitiser builds Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-16-alex.bennee@linaro.org>
2023-10-31tests/docker: use debian-all-test-cross for sparc64Alex Bennée
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-15-alex.bennee@linaro.org>
2023-10-31tests/docker: use debian-all-test-cross for riscv64Alex Bennée
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-14-alex.bennee@linaro.org>
2023-10-31tests/docker: use debian-all-test-cross for mipsAlex Bennée
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-13-alex.bennee@linaro.org>
2023-10-31tests/docker: use debian-all-test-cross for mips64Alex Bennée
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-12-alex.bennee@linaro.org>
2023-10-31tests/docker: use debian-all-test-cross for m68kAlex Bennée
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-11-alex.bennee@linaro.org>
2023-10-31tests/docker: use debian-all-test-cross for hppaAlex Bennée
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-10-alex.bennee@linaro.org>
2023-10-31tests/docker: use debian-all-test-cross for powerAlex Bennée
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-9-alex.bennee@linaro.org>
2023-10-31tests/docker: move sh4 to use debian-legacy-test-crossAlex Bennée
sh4 is another target which doesn't work with bookworm compilers. To keep on buster move across to the debian-legacy-test-cross image and update accordingly. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231030135715.800164-1-alex.bennee@linaro.org>
2023-10-31tests/docker: use debian-legacy-test-cross for alphaAlex Bennée
Maintaining two sets of containers for test building is silly. While it makes sense for the QEMU cross-compile targets to have their own fat containers built by lcitool we might as well merge the other random debian based compilers into the same one used on gitlab. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-7-alex.bennee@linaro.org>
2023-10-31gitlab: add build-loongarch to matrixAlex Bennée
We have the compiler and with a few updates a container that can build QEMU so we should at least run the check-tcg smoke tests. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-6-alex.bennee@linaro.org>
2023-10-31gitlab: clean-up build-soft-softmmu jobAlex Bennée
Having dropped alpha we also now drop xtensa as we don't have the compiler in this image. It's not all doom and gloom though as a number of other targets have gained softmmu TCG tests so we can add them. We will take care of the other targets with their own containers in future commits. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-5-alex.bennee@linaro.org>
2023-10-31gitlab: split alpha testing into a legacy containerAlex Bennée
The current bookworm compiler doesn't build the static binaries due to bug #1054412 and it might be awhile before it gets fixed. The problem of keeping older architecture compilers running isn't going to go away so lets prepare the ground. Create a legacy container and move some tests around so the others can get upgraded. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-4-alex.bennee@linaro.org>
2023-10-31tests/tcg: Add -fno-stack-protectorAkihiko Odaki
A build of GCC 13.2 will have stack protector enabled by default if it was configured with --enable-default-ssp option. For such a compiler, it is necessary to explicitly disable stack protector when linking without standard libraries. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20230731091042.139159-3-akihiko.odaki@daynix.com> [AJB: fix comment string typo] Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-3-alex.bennee@linaro.org>
2023-10-31tests/vm/openbsd: Use the system dtc packageThomas Huth
We can use the pre-packaged libfdt from the dtc package to avoid that we have to compile this code each time again and again. While we're at it, the "--python=python3" does not seemt to be necessary anymore, so we can drop it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231016154049.37147-1-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231029145033.592566-2-alex.bennee@linaro.org>
2023-10-31blockdev: mirror: avoid potential deadlock when using iothreadFiona Ebner
The bdrv_getlength() function is a generated co-wrapper and uses AIO_WAIT_WHILE() to wait for the spawned coroutine. AIO_WAIT_WHILE() expects the lock to be acquired exactly once. Fix a case where it may be acquired twice. This can happen when the source node is explicitly specified as the @replaces parameter or if the source node is a filter node. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20231019131936.414246-4-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31block: avoid potential deadlock during bdrv_graph_wrlock() in bdrv_close()Fiona Ebner
by passing the BlockDriverState along, so the held AioContext can be dropped before polling. See commit 31b2ddfea3 ("graph-lock: Unlock the AioContext while polling") which introduced this functionality for more information. The only way to reach bdrv_close() is via bdrv_unref() and for calling that the BlockDriverState's AioContext lock is supposed to be held. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20231019131936.414246-3-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31blockjob: drop AioContext lock before calling bdrv_graph_wrlock()Fiona Ebner
Same rationale as in 31b2ddfea3 ("graph-lock: Unlock the AioContext while polling"). Otherwise, a deadlock can happen. The alternative would be to pass a BlockDriverState along to bdrv_graph_wrlock(), but there is no BlockDriverState readily available and it's also better conceptually, because the lock is held for the job. The function is always called with the job's AioContext lock held, via one of the .abort, .clean, .free or .prepare job driver functions. Thus, it's safe to drop it. While mirror_exit_common() does hold a second AioContext lock while calling block_job_remove_all_bdrv(), that is for the main thread's AioContext and does not need to be dropped (bdrv_graph_wrlock(bs) also skips dropping the lock if bdrv_get_aio_context(bs) == qemu_get_aio_context()). Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20231019131936.414246-2-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31iotests: Test media change with iothreadsKevin Wolf
iotests case 118 already tests all relevant operations for media change with multiple devices, however never with iothreads. This changes the test so that the virtio-scsi tests run with an iothread. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231013153302.39234-3-kwolf@redhat.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31block: Fix locking in media change monitor commandsKevin Wolf
blk_insert_bs() requires that the caller holds the AioContext lock for the node to be inserted. Since commit c066e808e11, neglecting to do so causes a crash when the child has to be moved to a different AioContext to attach it to the BlockBackend. This fixes qmp_blockdev_insert_anon_medium(), which is called for the QMP commands 'blockdev-insert-medium' and 'blockdev-change-medium', to correctly take the lock. Cc: qemu-stable@nongnu.org Fixes: https://issues.redhat.com/browse/RHEL-3922 Fixes: c066e808e11a5c181b625537b6c78e0de27a4801 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231013153302.39234-2-kwolf@redhat.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31iotests: add tests for "qemu-img rebase" with compressionAndrey Drobyshev
The test cases considered so far: 314 (new test suite): 1. Check that compression mode isn't compatible with "-f raw" (raw format doesn't support compression). 2. Check that rebasing an image onto no backing file preserves the data and writes the copied clusters actually compressed. 3. Same as 2, but with a raw backing file (i.e. the clusters copied from the backing are originally uncompressed -- we check they end up compressed after being merged). 4. Remove a single delta from a backing chain, perform the same checks as in 2. 5. Check that even when backing and overlay are initially uncompressed, copied clusters end up compressed when rebase with compression is performed. 271: 1. Check that when target image has subclusters, rebase with compression will make an entire cluster containing the written subcluster compressed. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20230919165804.439110-9-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qemu-img: add compression option to rebase subcommandAndrey Drobyshev
If we rebase an image whose backing file has compressed clusters, we might end up wasting disk space since the copied clusters are now uncompressed. In order to have better control over this, let's add "--compress" option to the "qemu-img rebase" command. Note that this option affects only the clusters which are actually being copied from the original backing file. The clusters which were uncompressed in the target image will remain so. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20230919165804.439110-8-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31iotests/{024, 271}: add testcases for qemu-img rebaseAndrey Drobyshev
As the previous commit changes the logic of "qemu-img rebase" (it's using write alignment now), let's add a couple more test cases which would ensure it works correctly. In particular, the following scenarios: 024: add test case for rebase within one backing chain when the overlay cluster size > backings cluster size; 271: add test case for rebase images that contain subclusters. Check that no extra allocations are being made. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20230919165804.439110-7-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qemu-img: rebase: avoid unnecessary COW operationsAndrey Drobyshev
When rebasing an image from one backing file to another, we need to compare data from old and new backings. If the diff between that data happens to be unaligned to the target cluster size, we might end up doing partial writes, which would lead to copy-on-write and additional IO. Consider the following simple case (virtual_size == cluster_size == 64K): base <-- inc1 <-- inc2 qemu-io -c "write -P 0xaa 0 32K" base.qcow2 qemu-io -c "write -P 0xcc 32K 32K" base.qcow2 qemu-io -c "write -P 0xbb 0 32K" inc1.qcow2 qemu-io -c "write -P 0xcc 32K 32K" inc1.qcow2 qemu-img rebase -f qcow2 -b base.qcow2 -F qcow2 inc2.qcow2 While doing rebase, we'll write a half of the cluster to inc2, and block layer will have to read the 2nd half of the same cluster from the base image inc1 while doing this write operation, although the whole cluster is already read earlier to perform data comparison. In order to avoid these unnecessary IO cycles, let's make sure every write request is aligned to the overlay subcluster boundaries. Using subcluster size is universal as for the images which don't have them this size equals to the cluster size. so in any case we end up aligning to the smallest unit of allocation. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Message-ID: <20230919165804.439110-6-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qemu-img: add chunk size parameter to compare_buffers()Andrey Drobyshev
Add @chsize param to the function which, if non-zero, would represent the chunk size to be used for comparison. If it's zero, then BDRV_SECTOR_SIZE is used as default chunk size, which is the previous behaviour. In particular, we're going to use this param in img_rebase() to make the write requests aligned to a predefined alignment value. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20230919165804.439110-5-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qemu-img: rebase: use backing files' BlockBackend for buffer alignmentAndrey Drobyshev
Since commit bb1c05973cf ("qemu-img: Use qemu_blockalign"), buffers for the data read from the old and new backing files are aligned using BlockDriverState (or BlockBackend later on) referring to the target image. However, this isn't quite right, because buf_new is only being used for reading from the new backing, while buf_old is being used for both reading from the old backing and writing to the target. Let's take that into account and use more appropriate values as alignments. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Message-ID: <20230919165804.439110-4-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qemu-iotests: 024: add rebasing test case for overlay_size > backing_sizeAndrey Drobyshev
Before previous commit, rebase was getting infitely stuck in case of rebasing within the same backing chain and when overlay_size > backing_size. Let's add this case to the rebasing test 024 to make sure it doesn't break again. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20230919165804.439110-3-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qemu-img: rebase: stop when reaching EOF of old backing fileAndrey Drobyshev
In case when we're rebasing within one backing chain, and when target image is larger than old backing file, bdrv_is_allocated_above() ends up setting *pnum = 0. As a result, target offset isn't getting incremented, and we get stuck in an infinite for loop. Let's detect this case and proceed further down the loop body, as the offsets beyond the old backing size need to be explicitly zeroed. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Denis V. Lunev <den@openvz.org> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20230919165804.439110-2-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-10-31qemu-file: Make qemu_fflush() return errorsJuan Quintela
This let us simplify code of this shape. qemu_fflush(f); int ret = qemu_file_get_error(f); if (ret) { return ret; } into: int ret = qemu_fflush(f); if (ret) { return ret; } I updated all callers where there is any error check. qemu_fclose() don't need to check for f->last_error because qemu_fflush() returns it at the beggining of the function. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-13-quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2023-10-31migration: Remove transferred atomic counterJuan Quintela
After last commit, it is a write only variable. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-12-quintela@redhat.com>
2023-10-31migration: Use migration_transferred_bytes()Juan Quintela
There are only two differnces with the old value: - the amount of QEMUFile that hasn't yet been flushed. It can be discussed what is more exact, the new or the old one. - the amount of transferred bytes that we forgot to account for (the newer is better, i.e. exact). Notice that this two values are used to: a - present to the user b - calculate the rate_limit So a few KB here and there is not going to make a difference. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-11-quintela@redhat.com>
2023-10-31qemu-file: Simplify qemu_file_get_error()Juan Quintela
If we pass a NULL error is the same that returning directly the value. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-10-quintela@redhat.com>
2023-10-31migration: migration_rate_limit_reset() don't need the QEMUFileJuan Quintela
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-9-quintela@redhat.com>
2023-10-31migration: migration_transferred_bytes() don't need the QEMUFileJuan Quintela
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-8-quintela@redhat.com>
2023-10-31qemu-file: Remove _noflush from qemu_file_transferred_noflush()Juan Quintela
qemu_file_transferred() don't exist anymore, so we can reuse the name. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-7-quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2023-10-31qemu_file: Remove unused qemu_file_transferred()Juan Quintela
Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-6-quintela@redhat.com>
2023-10-31migration: Use the number of transferred bytes directlyJuan Quintela
We only use migration_transferred_bytes() to calculate the rate_limit, for that we don't need to flush whatever is on the qemu_file buffer. Remember that the buffer is really small (normal case is 32K if we use iov's can be 64 * TARGET_PAGE_SIZE), so this is not relevant to calculations. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-5-quintela@redhat.com>
2023-10-31qemu_file: total_transferred is not used anymoreJuan Quintela
Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-4-quintela@redhat.com>
2023-10-31qemu_file: Use a stat64 for qemu_file_transferredJuan Quintela
This way we can read it from any thread. I checked that it gives the same value as the current one. We never use two qemu_files at the same time. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-3-quintela@redhat.com>
2023-10-31qemu-file: Don't increment qemu_file_transferred at qemu_file_fill_bufferJuan Quintela
We only call qemu_file_transferred_* on the sending side. Remove the increment at qemu_file_fill_buffer() and add asserts to qemu_file_transferred* functions. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-2-quintela@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-17 18:13:30 +0000