[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/3] migration: Add migration events on target s
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH 3/3] migration: Add migration events on target side |
Date: |
Wed, 20 May 2015 10:10:11 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
On 05/20/2015 09:35 AM, Juan Quintela wrote:
> We reuse the migration events from the source side, sending them on the
> appropiate place.
s/appropiate/appropriate/
>
> Signed-off-by: Juan Quintela <address@hidden>
> ---
> migration/migration.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> @@ -116,14 +117,17 @@ static void process_incoming_migration_co(void *opaque)
> Error *local_err = NULL;
> int ret;
>
> + qapi_event_send_migration(MIGRATION_STATUS_ACTIVE, &error_abort);
> ret = qemu_loadvm_state(f);
> qemu_fclose(f);
> free_xbzrle_decoded_buf();
> if (ret < 0) {
> + qapi_event_send_migration(MIGRATION_STATUS_FAILED, &error_abort);
> error_report("load of migration failed: %s", strerror(-ret));
> migrate_decompress_threads_join();
> exit(EXIT_FAILURE);
Does qapi_event_send_* send an event right away, or merely just queue
things up to be sent at a safe point later in the overall event loop?
Or put another way, could the early exit() here prevent the actual error
from being delivered, because we don't return control to the event loop
to actually flush the pending event queue?
But whether or not we have a design issue on the failure path, at least
something got printed via error_report, and the real benefit of this
patch is the event on success; so I'm fine with giving this patch:
Reviewed-by: Eric Blake <address@hidden>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature