* Lidong Chen (jemmy858...@gmail.com) wrote:
> After postcopy, the destination qemu work in the dedicated
> thread, so only invoke yield_until_fd_readable before postcopy
> migration.
The subject line needs to be more discriptive:
migration: Stop rdma yielding during incoming postcopy
I think.
(Also please check the subject spellings)
> Signed-off-by: Lidong Chen <lidongc...@tencent.com>
> ---
> migration/rdma.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/migration/rdma.c b/migration/rdma.c
> index 53773c7..81be482 100644
> --- a/migration/rdma.c
> +++ b/migration/rdma.c
> @@ -1489,11 +1489,13 @@ static int qemu_rdma_wait_comp_channel(RDMAContext
> *rdma)
> * Coroutine doesn't start until migration_fd_process_incoming()
> * so don't yield unless we know we're running inside of a coroutine.
> */
> - if (rdma->migration_started_on_destination) {
> + if (rdma->migration_started_on_destination &&
> + migration_incoming_get_current()->state == MIGRATION_STATUS_ACTIVE) {
OK, that's a bit delicate; watch if it ever gets called in a failure
case or similar - and also wathc out if we make more use of the status
on the destination, but otherwise, and with a fix for the subject;
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> yield_until_fd_readable(rdma->comp_channel->fd);
> } else {
> /* This is the source side, we're in a separate thread
> * or destination prior to migration_fd_process_incoming()
> + * after postcopy, the destination also in a seprate thread.
> * we can't yield; so we have to poll the fd.
> * But we need to be able to handle 'cancel' or an error
> * without hanging forever.
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
