- Jan 20, 2024
-
-
Nick Briggs authored
Solaris has #defines for htonll and ntohll which cause syntax errors when compiling code that attempts to (re)define these functions.. Signed-off-by:
Nick Briggs <nicholas.h.briggs@gmail.com> Link: https://lore.kernel.org/r/65a04a7d.497ab3.3e7bef1f@gateway.sonic.net Signed-off-by:
Peter Xu <peterx@redhat.com> (cherry picked from commit 44ce1b5d2fc77343f6a318cb3de613336a240048) Signed-off-by:
Michael Tokarev <mjt@tls.msk.ru>
-
- Dec 01, 2023
-
-
Het Gala authored
migrate_uri_parse() allocates memory to 'channel' if the user opts for old syntax - uri, which is leaked because there is no code for freeing 'channel'. So, free channel to avoid memory leak in case where 'channels' is empty and uri parsing is required. Fixes: 5994024f ("migration: Implement MigrateChannelList to qmp migration flow") Signed-off-by:
Het Gala <het.gala@nutanix.com> Suggested-by:
Markus Armbruster <armbru@redhat.com> Tested-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
Markus Armbruster <armbru@redhat.com> Link: https://lore.kernel.org/r/20231129204301.131228-1-het.gala@nutanix.com Signed-off-by:
Peter Xu <peterx@redhat.com>
-
- Nov 30, 2023
-
-
Zongmin Zhou authored
Since socket_parse() will allocate memory for 'saddr',and its value will pass to 'addr' that allocated by migrate_uri_parse(), then 'saddr' will no longer used,need to free. But due to 'saddr->u' is shallow copying the contents of the union, the members of this union containing allocated strings,and will be used after that. So just free 'saddr' itself without doing a deep free on the contents of the SocketAddress. Fixes: 72a8192e ("migration: convert migration 'uri' into 'MigrateAddress'") Signed-off-by:
Zongmin <Zhou<zhouzongmin@kylinos.cn> Reviewed-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231120031428.908295-1-zhouzongmin@kylinos.cn>
-
Fabiano Rosas authored
This is being shadowed but the assignments at multifd_channel_connect() and multifd_tls_channel_connect() . Signed-off-by:
Fabiano Rosas <farosas@suse.de> Message-ID: <20231110200241.20679-2-farosas@suse.de> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
- Nov 15, 2023
-
-
Michael Tokarev authored
Fixes: 67c31c9c "migration: Don't abuse qemu_file transferred for RDMA" Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Michael Tokarev <mjt@tls.msk.ru>
-
- Nov 07, 2023
-
-
Kevin Wolf authored
This adds GRAPH_RDLOCK annotations to declare that callers of bdrv_filter_bs() need to hold a reader lock for the graph because it calls bdrv_filter_child(), which accesses bs->file/backing. Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Message-ID: <20231027155333.420094-4-kwolf@redhat.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
-
- Nov 03, 2023
-
-
Juan Quintela authored
We were not unlocking bitmap mutex on the error case. To fix it forever change to enclose the code with WITH_QEMU_LOCK_GUARD(). Coverity CID 1523750. Fixes: a2326705 ("migration: Stop migration immediately in RDMA error paths") Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231103074245.55166-1-quintela@redhat.com>
-
Cédric Le Goater authored
qemu_uuid_unparse() includes a trailing NUL when writing the uuid string and the buffer size should be UUID_FMT_LEN + 1 bytes. Add a define for this size and use it where required. Cc: Fam Zheng <fam@euphon.net> Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
"Denis V. Lunev" <den@openvz.org> Signed-off-by:
Cédric Le Goater <clg@redhat.com>
-
- Nov 02, 2023
-
-
Het Gala authored
Integrate MigrateChannelList with all transport backends (socket, exec and rdma) for both src and dest migration endpoints for hmp migration. Suggested-by:
Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by:
Het Gala <het.gala@nutanix.com> Signed-off-by:
Fabiano Rosas <farosas@suse.de> Message-ID: <20231023182053.8711-14-farosas@suse.de> Signed-off-by:
Juan Quintela <quintela@redhat.com>
-
Het Gala authored
Integrate MigrateChannelList with all transport backends (socket, exec and rdma) for both src and dest migration endpoints for qmp migration. For current series, limit the size of MigrateChannelList to single element (single interface) as runtime check. Suggested-by:
Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by:
Het Gala <het.gala@nutanix.com> Signed-off-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-13-farosas@suse.de>
-
Het Gala authored
migration_channels_and_uri_compatible() check for transport mechanism suitable for multifd migration gets executed when the caller calls old uri syntax. It needs it to be run when using the modern MigrateChannel QAPI syntax too. After URI -> 'MigrateChannel' : migration_channels_and_uri_compatible() -> migration_channels_and_transport_compatible() passes object as argument and check for valid transport mechanism. Suggested-by:
Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by:
Het Gala <het.gala@nutanix.com> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Signed-off-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-12-farosas@suse.de>
-
Het Gala authored
MigrateChannelList allows to connect accross multiple interfaces. Add MigrateChannelList struct as argument to migration QAPIs. We plan to include multiple channels in future, to connnect multiple interfaces. Hence, we choose 'MigrateChannelList' as the new argument over 'MigrateChannel' to make migration QAPIs future proof. Suggested-by:
Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by:
Het Gala <het.gala@nutanix.com> Acked-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Signed-off-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-10-farosas@suse.de>
-
Fabiano Rosas authored
Convert the file: URI to accept a FileMigrationArgs to be compatible with the new migration QAPI. Signed-off-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-9-farosas@suse.de>
-
Het Gala authored
Exec transport backend for 'migrate'/'migrate-incoming' QAPIs accept new wire protocol of MigrateAddress struct. It is achived by parsing 'uri' string and storing migration parameters required for exec connection into strList struct. Suggested-by:
Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by:
Het Gala <het.gala@nutanix.com> Signed-off-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-8-farosas@suse.de>
-
Het Gala authored
RDMA based transport backend for 'migrate'/'migrate-incoming' QAPIs accept new wire protocol of MigrateAddress struct. It is achived by parsing 'uri' string and storing migration parameters required for RDMA connection into well defined InetSocketAddress struct. Suggested-by:
Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by:
Het Gala <het.gala@nutanix.com> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Signed-off-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-7-farosas@suse.de>
-
Het Gala authored
Socket transport backend for 'migrate'/'migrate-incoming' QAPIs accept new wire protocol of MigrateAddress struct. It is achived by parsing 'uri' string and storing migration parameters required for socket connection into well defined SocketAddress struct. Suggested-by:
Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by:
Het Gala <het.gala@nutanix.com> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Signed-off-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-6-farosas@suse.de>
-
Het Gala authored
This patch parses 'migrate' and 'migrate-incoming' QAPI's 'uri' string containing migration connection related information and stores them inside well defined 'MigrateAddress' struct. Fabiano fixed for "file" transport. Suggested-by:
Aravind Retnakaran <aravind.retnakaran@nutanix.com> Signed-off-by:
Het Gala <het.gala@nutanix.com> Signed-off-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231023182053.8711-4-farosas@suse.de> Message-ID: <20231023182053.8711-5-farosas@suse.de>
-
Peter Xu authored
Now we have a Error** passed into the return path thread stack, which is even clearer than an int retval. Change ram_dirty_bitmap_reload() and the callers to use a bool instead to replace errnos. Suggested-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231017202633.296756-5-peterx@redhat.com>
-
Peter Xu authored
Normally the postcopy recover phase should only exist for a super short period, that's the duration when QEMU is trying to recover from an interrupted postcopy migration, during which handshake will be carried out for continuing the procedure with state changes from PAUSED -> RECOVER -> POSTCOPY_ACTIVE again. Here RECOVER phase should be super small, that happens right after the admin specified a new but working network link for QEMU to reconnect to dest QEMU. However there can still be case where the channel is broken in this small RECOVER window. If it happens, with current code there's no way the src QEMU can got kicked out of RECOVER stage. No way either to retry the recover in another channel when established. This patch allows the RECOVER phase to fail itself too - we're mostly ready, just some small things missing, e.g. properly kick the main migration thread out when sleeping on rp_sem when we found that we're at RECOVER stage. When this happens, it fails the RECOVER itself, and rollback to PAUSED stage. Then the user can retry another round of recovery. To make it even stronger, teach QMP command migrate-pause to explicitly kick src/dst QEMU out when needed, so even if for some reason the migration thread didn't got kicked out already by a failing rethrn-path thread, the admin can also kick it out. This will be an super, super corner case, but still try to cover that. One can try to test this with two proxy channels for migration: (a) socat unix-listen:/tmp/src.sock,reuseaddr,fork tcp:localhost:10000 (b) socat tcp-listen:10000,reuseaddr,fork unix:/tmp/dst.sock So the migration channel will be: (a) (b) src -> /tmp/src.sock -> tcp:10000 -> /tmp/dst.sock -> dst Then to make QEMU hang at RECOVER stage, one can do below: (1) stop the postcopy using QMP command postcopy-pause (2) kill the 2nd proxy (b) (3) try to recover the postcopy using /tmp/src.sock on src (4) src QEMU will go into RECOVER stage but won't be able to continue from there, because the channel is actually broken at (b) Before this patch, step (4) will make src QEMU stuck in RECOVER stage, without a way to kick the QEMU out or continue the postcopy again. After this patch, (4) will quickly fail qemu and bounce back to PAUSED stage. Admin can also kick QEMU from (4) into PAUSED when needed using migrate-pause when needed. After bouncing back to PAUSED stage, one can recover again. Reported-by:
Xiaohui Li <xiaohli@redhat.com> Reviewed-by:
Fabiano Rosas <farosas@suse.de> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2111332 Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231017202633.296756-3-peterx@redhat.com>
-
Peter Xu authored
rp_state.error was a boolean used to show error happened in return path thread. That's not only duplicating error reporting (migrate_set_error), but also not good enough in that we only do error_report() and set it to true, we never can keep a history of the exact error and show it in query-migrate. To make this better, a few things done: - Use error_setg() rather than error_report() across the whole lifecycle of return path thread, keeping the error in an Error*. - With above, no need to have mark_source_rp_bad(), remove it, alongside with rp_state.error itself. - Use migrate_set_error() to apply that captured error to the global migration object when error occured in this thread. - Do the same when detected qemufile error in source return path We need to re-export qemu_file_get_error_obj() to do the last one. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231017202633.296756-2-peterx@redhat.com>
-
- Nov 01, 2023
-
-
Steve Sistare authored
Extend the blocker interface so that a blocker can be registered for one or more migration modes. The existing interfaces register a blocker for all modes, and the new interfaces take a varargs list of modes. Internally, maintain a separate blocker list per mode. The same Error object may be added to multiple lists. When a block is deleted, it is removed from every list, and the Error is freed. No functional change until a new mode is added. Signed-off-by:
Steve Sistare <steven.sistare@oracle.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <1698263069-406971-3-git-send-email-steven.sistare@oracle.com>
-
Steve Sistare authored
Create a mode migration parameter that can be used to select alternate migration algorithms. The default mode is normal, representing the current migration algorithm, and does not need to be explicitly set. No functional change until a new mode is added, except that the mode is shown by the 'info migrate' command. Signed-off-by:
Steve Sistare <steven.sistare@oracle.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <1698263069-406971-2-git-send-email-steven.sistare@oracle.com>
-
Peter Xu authored
This patch is inspired by Joao Martin's patch here: https://lore.kernel.org/r/20230926161841.98464-1-joao.m.martins@oracle.com Add tracepoints for major downtime checkpoints on both src and dst. They share the same tracepoint with a string showing its stage. Besides the checkpoints in the previous patch, this patch also added destination checkpoints. On src, we have these checkpoints added: - src-downtime-start: right before vm stops on src - src-vm-stopped: after vm is fully stopped - src-iterable-saved: after all iterables saved (END sections) - src-non-iterable-saved: after all non-iterable saved (FULL sections) - src-downtime-stop: migration fully completed On dst, we have these checkpoints added: - dst-precopy-loadvm-completes: after loadvm all done for precopy - dst-precopy-bh-*: record BH steps to resume VM for precopy - dst-postcopy-bh-*: record BH steps to resume VM for postcopy On dst side, we don't have a good way to trace total time consumed by iterable or non-iterable for now. We can mark it by 1st time receiving a FULL / END section, but rather than that let's just rely on the other tracepoints added for vmstates to back up the information. With this patch, one can enable "vmstate_downtime*" tracepoints and it'll enable all tracepoints for downtime measurements necessary. Drop loadvm_postcopy_handle_run_bh() tracepoint alongside, because they service the same purpose, which was only for postcopy. We then have unified prefix for all downtime relevant tracepoints. Co-developed-by:
Joao Martins <joao.m.martins@oracle.com> Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231030163346.765724-6-peterx@redhat.com>
-
Peter Xu authored
Provide a helper for non-COLO use case of migration to stop a VM. This prepares for adding some downtime relevant tracepoints to migration, where they may or may not apply to COLO. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231030163346.765724-5-peterx@redhat.com>
-
Peter Xu authored
We have a bunch of savevm_section* tracepoints, they're good to analyze migration stream, but not always suitable if someone would like to analyze the migration downtime. Two major problems: - savevm_section* tracepoints are dumping all sections, we only care about the sections that contribute to the downtime - They don't have an identifier to show the type of sections, so no way to filter downtime information either easily. We can add type into the tracepoints, but instead of doing so, this patch kept them untouched, instead of adding a bunch of downtime specific tracepoints, so one can enable "vmstate_downtime*" tracepoints and get a full picture of how the downtime is distributed across iterative and non-iterative vmstate save/load. Note that here both save() and load() need to be traced, because both of them may contribute to the downtime. The contribution is not a simple "add them together", though: consider when the src is doing a save() of device1 while the dest can be load()ing for device2, so they can happen concurrently. Tracking both sides make sense because device load() and save() can be imbalanced, one device can save() super fast, but load() super slow, vice versa. We can't figure that out without tracing both. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231030163346.765724-4-peterx@redhat.com>
-
Peter Xu authored
Unify the three users on recording downtimes with the same pair of helpers. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231030163346.765724-3-peterx@redhat.com>
-
Peter Xu authored
Postcopy calculates its downtime separately. It always sets MigrationState.downtime properly, but not MigrationState.downtime_start. Make postcopy do the same as other modes on properly recording the timestamp when the VM is going to be stopped. Drop the temporary variable in postcopy_start() along the way. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fabiano Rosas <farosas@suse.de> Reviewed-by:
Juan Quintela <quintela@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231030163346.765724-2-peterx@redhat.com>
-
Peter Xu authored
Before finally register one SaveStateEntry, we detect for duplicated entries. This could be helpful to notify us asap instead of get silent migration failures which could be hard to diagnose. For example, this patch will generate a message like this (if without previous fixes on x2apic) as long as we wants to boot a VM instance with "-smp 200,maxcpus=288,sockets=2,cores=72,threads=2" and QEMU will bail out even before VM starts: savevm_state_handler_insert: Detected duplicate SaveStateEntry: id=apic, instance_id=0x0 Suggested-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Juan Quintela <quintela@redhat.com> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231020090731.28701-10-quintela@redhat.com>
-
Juan Quintela authored
Current code does: - register pre_2_10_vmstate_dummy_icp with "icp/server" and instance dependinfg on cpu number - for newer machines, it register vmstate_icp with "icp/server" name and instance 0 - now it unregisters "icp/server" for the 1st instance. This is wrong at many levels: - we shouldn't have two VMSTATEDescriptions with the same name - In case this is the only solution that we can came with, it needs to be: * register pre_2_10_vmstate_dummy_icp * unregister pre_2_10_vmstate_dummy_icp * register real vmstate_icp Created vmstate_replace_hack_for_ppc() with warnings left and right that it is a hack. CC: Cedric Le Goater <clg@kaod.org> CC: Daniel Henrique Barboza <danielhb413@gmail.com> CC: David Gibson <david@gibson.dropbear.id.au> CC: Greg Kurz <groug@kaod.org> Reviewed-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231020090731.28701-8-quintela@redhat.com>
-
- Oct 31, 2023
-
-
Juan Quintela authored
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>
-
Juan Quintela authored
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>
-
Juan Quintela authored
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>
-
Juan Quintela authored
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>
-
Juan Quintela authored
Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-9-quintela@redhat.com>
-
Juan Quintela authored
Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-8-quintela@redhat.com>
-
Juan Quintela authored
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>
-
Juan Quintela authored
Reviewed-by:
Fabiano Rosas <farosas@suse.de> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-6-quintela@redhat.com>
-
Juan Quintela authored
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>
-
Juan Quintela authored
Reviewed-by:
Fabiano Rosas <farosas@suse.de> Signed-off-by:
Juan Quintela <quintela@redhat.com> Message-ID: <20231025091117.6342-4-quintela@redhat.com>
-
Juan Quintela authored
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>
-