Re: [PATCH v1] migration/postcopy: ensure preempt channel is ready before loading states

[Peter Xu <peterx@redhat.com>]

On Thu, Apr 04, 2024 at 06:05:50PM +0800, Wei Wang wrote:
> Before loading the guest states, ensure that the preempt channel has been
> ready to use, as some of the states (e.g. via virtio_load) might trigger
> page faults that will be handled through the preempt channel. So yield to
> the main thread in the case that the channel create event has been
> dispatched.
> 
> Originally-by: Lei Wang <lei4.wang@intel.com>
> Link: https://lore.kernel.org/all/9aa5d1be-7801-40dd-83fd-f7e041ced249@intel.com/T/
> Suggested-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: Lei Wang <lei4.wang@intel.com>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> ---
>  migration/savevm.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 388d7af7cd..fbc9f2bdd4 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -2342,6 +2342,23 @@ static int loadvm_handle_cmd_packaged(MigrationIncomingState *mis)
>  
>      QEMUFile *packf = qemu_file_new_input(QIO_CHANNEL(bioc));
>  
> +    /*
> +     * Before loading the guest states, ensure that the preempt channel has
> +     * been ready to use, as some of the states (e.g. via virtio_load) might
> +     * trigger page faults that will be handled through the preempt channel.
> +     * So yield to the main thread in the case that the channel create event
> +     * has been dispatched.
> +     */
> +    do {
> +        if (!migrate_postcopy_preempt() || !qemu_in_coroutine() ||
> +            mis->postcopy_qemufile_dst) {
> +            break;
> +        }
> +
> +        aio_co_schedule(qemu_get_current_aio_context(), qemu_coroutine_self());
> +        qemu_coroutine_yield();
> +    } while (!qemu_sem_timedwait(&mis->postcopy_qemufile_dst_done, 1));

I think we need s/!// here, so the same mistake I made?  I think we need to
rework the retval of qemu_sem_timedwait() at some point later..

Besides, this patch kept the sem_wait() in postcopy_preempt_thread() so it
will wait() on this sem again.  If this qemu_sem_timedwait() accidentally
consumed the sem count then I think the other thread can hang forever?

That's why I put the wait before creation of the preempt thread (in
postcopy_ram_incoming_setup()), as we can only consume the sem once, so we
must prepare the qemufile when the thread is created.

Thanks,

> +
>      ret = qemu_loadvm_state_main(packf, mis);
>      trace_loadvm_handle_cmd_packaged_main(ret);
>      qemu_fclose(packf);
> -- 
> 2.27.0
> 

-- 
Peter Xu