[{"id":3680068,"web_url":"http://patchwork.ozlabs.org/comment/3680068/","msgid":"<aefrPBN7k94Jj2dh@x1.local>","list_archive_url":null,"date":"2026-04-21T21:25:16","subject":"Re: [PATCH] migration: Fix blocking in POSTCOPY_DEVICE during\n package load","submitter":{"id":67717,"url":"http://patchwork.ozlabs.org/api/people/67717/","name":"Peter Xu","email":"peterx@redhat.com"},"content":"On Tue, Apr 21, 2026 at 10:52:27AM +0530, Pranav Tyagi wrote:\n> The package_loaded event is not set in case MIG_RP_MSG_PONG does not\n> arrive on the source from the destination in the return path thread. The\n> migration thread would then be blocked waiting for package_loaded event\n> indefinitely in POSTCOPY_DEVICE state. Where as, in such a condition the\n> source VM can safely resume as the destination has not yet started. The\n> pong message can get lost in case of a network failure or destination\n> crash before sending the pong.\n> \n> This patch uses the error detected in case of network failure or\n> destination crash to set the package_loaded event in the out path of the\n> return path thread. This will kick the migration thread out from\n> a condition of indefinitely waiting for the package_loaded event. The\n> migration thread then fails early and breaks from the migration loop to\n> resume the VM on the source side.\n> \n> Fixes: 7b842fe354c6 (\"migration: Introduce POSTCOPY_DEVICE state\")\n> Signed-off-by: Pranav Tyagi <prtyagi@redhat.com>\n\nAh I see.. thanks for figuring this out.\n\n> ---\n>  migration/migration.c | 20 ++++++++++++++++++++\n>  1 file changed, 20 insertions(+)\n> \n> diff --git a/migration/migration.c b/migration/migration.c\n> index 5c9aaa6e58..1656c1203c 100644\n> --- a/migration/migration.c\n> +++ b/migration/migration.c\n> @@ -2386,6 +2386,15 @@ out:\n>      if (err) {\n>          migrate_error_propagate(ms, err);\n>          trace_source_return_path_thread_bad_end();\n> +        if (ms->state == MIGRATION_STATUS_POSTCOPY_DEVICE) {\n> +            /*\n> +             * Kick the migration thread if it gets stuck in\n> +             * POSTCOPY_DEVICE state waiting for\n> +             * postcopy_package_loaded_event. The event will never be\n> +             * set as MIG_RP_MSG_PONG from the destination is lost.\n> +             */\n> +            qemu_event_set(&ms->postcopy_package_loaded_event);\n> +        }\n\nThis makes sense.  Said that, we have another similar case right below for\nthe postcopy recover path:\n\n    if (ms->state == MIGRATION_STATUS_POSTCOPY_RECOVER) {\n        /*\n         * this will be extremely unlikely: that we got yet another network\n         * issue during recovering of the 1st network failure.. during this\n         * period the main migration thread can be waiting on rp_sem for\n         * this thread to sync with the other side.\n         *\n         * When this happens, explicitly kick the migration thread out of\n         * RECOVER stage and back to PAUSED, so the admin can try\n         * everything again.\n         */\n        migration_rp_kick(ms);\n    }\n\nIt achieves some similar goal, where the migration thread is waiting for\nsome event from return path thread, and when the channel is broken we want\nto kick it out.\n\nI'm thinking if we can reuse that, instead of kicking multiple events.\n\nSay, we can do migration_rp_kick() for both POSTCOPY_RECOVER and\nPOSTCOPY_DEVICE states in the rp thread.  Meanwhile at below..\n\n>      }\n>  \n>      if (ms->state == MIGRATION_STATUS_POSTCOPY_RECOVER) {\n> @@ -3232,6 +3241,17 @@ static MigIterateState migration_iteration_run(MigrationState *s)\n>               * package before actually completing.\n>               */\n>              qemu_event_wait(&s->postcopy_package_loaded_event);\n> +            /*\n> +             * Check for errors in case the migration thread was stuck in\n> +             * POSTCOPY_DEVICE state waiting for the\n> +             * postcopy_package_loaded_event which was never set.\n> +             * If so, fail now and break out of the iteration.\n> +             */\n> +            if (migrate_has_error(s)) {\n> +                migrate_set_state(&s->state, MIGRATION_STATUS_POSTCOPY_DEVICE,\n> +                                  MIGRATION_STATUS_FAILING);\n> +                return MIG_ITERATE_BREAK;\n> +            }\n\n... instead of waiting on postcopy_package_loaded_event, we can do:\n\n    while (!s->postcopy_package_loaded) {\n        if (migration_rp_wait(s)) {\n            /* Error happened */\n            migrate_set_state(&s->state, MIGRATION_STATUS_POSTCOPY_DEVICE,\n                              MIGRATION_STATUS_FAILING);\n            return MIG_ITERATE_BREAK;\n        }\n    }\n    /* Acknowledgement received from dest */\n    migrate_set_state(&s->state, MIGRATION_STATUS_POSTCOPY_DEVICE,\n                      MIGRATION_STATUS_POSTCOPY_ACTIVE);\n\nPS: I think event also works in this case, so likely either one shared sem\nor event should work; it's just that it was a sem before, and rp_sem has a\nname that is generic enough to apply directly to the\npostcopy_package_loaded_event use case.\n\nThanks,\n\n>              migrate_set_state(&s->state, MIGRATION_STATUS_POSTCOPY_DEVICE,\n>                                MIGRATION_STATUS_POSTCOPY_ACTIVE);\n>          }\n> -- \n> 2.53.0\n>","headers":{"Return-Path":"<qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=iMcJJ7aX;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=google header.b=HVhxdpil;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g0b4x1n91z1yGs\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 22 Apr 2026 07:26:07 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from <qemu-devel-bounces@nongnu.org>)\n\tid 1wFIb7-0001O9-Ch; Tue, 21 Apr 2026 17:25:33 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <peterx@redhat.com>) id 1wFIb2-0001Ni-Me\n for qemu-devel@nongnu.org; Tue, 21 Apr 2026 17:25:29 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.129.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <peterx@redhat.com>) id 1wFIaw-0001yf-R9\n for qemu-devel@nongnu.org; Tue, 21 Apr 2026 17:25:25 -0400","from mail-qk1-f198.google.com (mail-qk1-f198.google.com\n [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-133-MXuLj414OkSCScJ9AAFJDw-1; Tue, 21 Apr 2026 17:25:19 -0400","by mail-qk1-f198.google.com with SMTP id\n af79cd13be357-8eabf08affaso777794985a.1\n for <qemu-devel@nongnu.org>; Tue, 21 Apr 2026 14:25:19 -0700 (PDT)","from x1.local ([142.189.10.167]) by smtp.gmail.com with ESMTPSA id\n af79cd13be357-8eb61bc0d3dsm582502185a.26.2026.04.21.14.25.17\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Tue, 21 Apr 2026 14:25:17 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1776806721;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=3TF7SmzuNr0uCh2qnzcJvYPOs35SdTe4cdaC5L6bTTU=;\n b=iMcJJ7aXXFCzGPYtS/MQSfozIMAwbQLEhUsgeyONmPKYmAmKRny2A2SOaPPbbU5xUruEgs\n YiBRdwVLtMn4BwranFQTQMZMnWx3MT1esJQ2EFzeQ9enm514DVLqPs3joHnF3tJWRy36j6\n bXRmc9l3N4mPkZn2etReNUx7uTKes4U=","v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=redhat.com; s=google; t=1776806719; x=1777411519; darn=nongnu.org;\n h=in-reply-to:content-disposition:mime-version:references:message-id\n :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;\n bh=3TF7SmzuNr0uCh2qnzcJvYPOs35SdTe4cdaC5L6bTTU=;\n b=HVhxdpil9n62mA0Jv7FgPhUSCq47qkspqahdLFMqeHB/sbcLylfUEbCD7CZCYju4bB\n VMDR8j+j8TjFxAofr8xXZNlJLWr85WyGjgDN1NigrE4Cz91RoixMbvGoZV1SZvdATBfZ\n ssAqgiJMXOJzU1Dut3K5JwDmJtPkXUFe1Tu5qAxmFuXCKzhpccYVXyJVB/C2p7Ec3rYB\n 3VhWy4coL+YR+/Soqremp5ahsj0FTkyhrkvWpXHnUsdxsZwvnHkmyJ9+NvU7CG4MUIqP\n Jj1q78xGv4UIK3DNpOrMmX9MIccH6mRcRZtKRfEpAyUbySP5CmnnkIth24lnxiTwbSvm\n 7ZdA=="],"X-MC-Unique":"MXuLj414OkSCScJ9AAFJDw-1","X-Mimecast-MFC-AGG-ID":"MXuLj414OkSCScJ9AAFJDw_1776806719","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776806719; x=1777411519;\n h=in-reply-to:content-disposition:mime-version:references:message-id\n :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=3TF7SmzuNr0uCh2qnzcJvYPOs35SdTe4cdaC5L6bTTU=;\n b=gzp2bmYIJ8i0zCclAIfMUTSsq+MsqszeQ6ofOWZTWGCqgeu7roAQLrA6ODmhOj9S0m\n 5AClVuRleqP2pCnZAW2F9kZAvPUaQbXOWmDUa7gf3fxqzStKFMh0qDoGpcfaKkl9JAjL\n HW1At3VMJX2eWd9cdTMzsURok4w+xnO3RCoRgwHFEypGgCm7h7RUyrnkolPl2MkN9J0n\n lU8N4fLLIsKMghHKUp03Qxr581dRz5z92WnY7iTuA5ArCZc4V3KF1dtA5boAck3Z70dH\n M9xXhdNmudfY3+HU8Xvg/lefIZMW08Fy05KS17jlLjo2+FVGPKeBRSqiKRo+86ONUaP4\n ZqOw==","X-Gm-Message-State":"AOJu0YyFt/tSvM6PbpW3CvlZkeDd7KGVQ6cPp7Za0VERdWOYGNVOT8ET\n EN/xs2KBwF1L8yqJFQl18Sb5L8IgD/3TS3U5Dpb3reMoM93OZu6ehSSKmWSCs/hE3AtlcJoS1Ou\n ol5nxzu0pXOqMq1RQvddQt1fXX8xJmraYgBV+tDeNFxZG7Wz/PaL3L39Y","X-Gm-Gg":"AeBDietWapvjJfgCsC6KNYeMOdrAvUwdtI333zHVFsBHVsrgDQ3mwekP5m4T9dLSpbC\n 8UAw2Bk3X1f16BcaWuYTNrEtVHtcdetV4JRq7rWAqVymC+LVh0+D7q0aRj3Igk4Yzyue7EJBTlV\n 6VtnUPUC12j9SOoRotLiYyJ0+FCUGtybhsZiI8gSIqdeJ6CbFP6RVopsH0f4/qvm51AXw9MMVW3\n iHSl0wXC09tLVf+yRva00f653Eb4O7bEGSiR48q6kL+SJXH4lB6l/v9P/ocPdaQX6aALMgOQMQK\n GD8gSQhkgttcs7T9h2uLB5lsEpMV0Rei2qHcpYqlMXM2JUCRexqcLpAtdsHh+HqocDeNytCCent\n 1BMtuWQpRhTr3zrPct8KYVWIaCn7XKdwEbfymMOeCxtCfflA8FSdM2/Vdig==","X-Received":["by 2002:a05:620a:2953:b0:8df:6628:3cd1 with SMTP id\n af79cd13be357-8e7913c28fdmr2626927085a.40.1776806718837;\n Tue, 21 Apr 2026 14:25:18 -0700 (PDT)","by 2002:a05:620a:2953:b0:8df:6628:3cd1 with SMTP id\n af79cd13be357-8e7913c28fdmr2626920785a.40.1776806718158;\n Tue, 21 Apr 2026 14:25:18 -0700 (PDT)"],"Date":"Tue, 21 Apr 2026 17:25:16 -0400","From":"Peter Xu <peterx@redhat.com>","To":"Pranav Tyagi <prtyagi@redhat.com>","Cc":"qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,\n Juraj Marcin <jmarcin@redhat.com>, Prasad Pandit <ppandit@redhat.com>","Subject":"Re: [PATCH] migration: Fix blocking in POSTCOPY_DEVICE during\n package load","Message-ID":"<aefrPBN7k94Jj2dh@x1.local>","References":"<20260421052227.8278-1-prtyagi@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20260421052227.8278-1-prtyagi@redhat.com>","Received-SPF":"pass client-ip=170.10.129.124; envelope-from=peterx@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development <qemu-devel.nongnu.org>","List-Unsubscribe":"<https://lists.nongnu.org/mailman/options/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>","List-Archive":"<https://lists.nongnu.org/archive/html/qemu-devel>","List-Post":"<mailto:qemu-devel@nongnu.org>","List-Help":"<mailto:qemu-devel-request@nongnu.org?subject=help>","List-Subscribe":"<https://lists.nongnu.org/mailman/listinfo/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=subscribe>","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3680324,"web_url":"http://patchwork.ozlabs.org/comment/3680324/","msgid":"<CALY4kkSJRqTpcBwe2UAJHJQBQGU7Tt1oWnX3nUECUKZPA=g3eA@mail.gmail.com>","list_archive_url":null,"date":"2026-04-22T08:49:33","subject":"Re: [PATCH] migration: Fix blocking in POSTCOPY_DEVICE during package\n load","submitter":{"id":93199,"url":"http://patchwork.ozlabs.org/api/people/93199/","name":"Pranav Tyagi","email":"prtyagi@redhat.com"},"content":"On Wed, Apr 22, 2026 at 2:55 AM Peter Xu <peterx@redhat.com> wrote:\n\n> On Tue, Apr 21, 2026 at 10:52:27AM +0530, Pranav Tyagi wrote:\n> > The package_loaded event is not set in case MIG_RP_MSG_PONG does not\n> > arrive on the source from the destination in the return path thread. The\n> > migration thread would then be blocked waiting for package_loaded event\n> > indefinitely in POSTCOPY_DEVICE state. Where as, in such a condition the\n> > source VM can safely resume as the destination has not yet started. The\n> > pong message can get lost in case of a network failure or destination\n> > crash before sending the pong.\n> >\n> > This patch uses the error detected in case of network failure or\n> > destination crash to set the package_loaded event in the out path of the\n> > return path thread. This will kick the migration thread out from\n> > a condition of indefinitely waiting for the package_loaded event. The\n> > migration thread then fails early and breaks from the migration loop to\n> > resume the VM on the source side.\n> >\n> > Fixes: 7b842fe354c6 (\"migration: Introduce POSTCOPY_DEVICE state\")\n> > Signed-off-by: Pranav Tyagi <prtyagi@redhat.com>\n>\n> Ah I see.. thanks for figuring this out.\n>\n> > ---\n> >  migration/migration.c | 20 ++++++++++++++++++++\n> >  1 file changed, 20 insertions(+)\n> >\n> > diff --git a/migration/migration.c b/migration/migration.c\n> > index 5c9aaa6e58..1656c1203c 100644\n> > --- a/migration/migration.c\n> > +++ b/migration/migration.c\n> > @@ -2386,6 +2386,15 @@ out:\n> >      if (err) {\n> >          migrate_error_propagate(ms, err);\n> >          trace_source_return_path_thread_bad_end();\n> > +        if (ms->state == MIGRATION_STATUS_POSTCOPY_DEVICE) {\n> > +            /*\n> > +             * Kick the migration thread if it gets stuck in\n> > +             * POSTCOPY_DEVICE state waiting for\n> > +             * postcopy_package_loaded_event. The event will never be\n> > +             * set as MIG_RP_MSG_PONG from the destination is lost.\n> > +             */\n> > +            qemu_event_set(&ms->postcopy_package_loaded_event);\n> > +        }\n>\n> This makes sense.  Said that, we have another similar case right below for\n> the postcopy recover path:\n>\n>     if (ms->state == MIGRATION_STATUS_POSTCOPY_RECOVER) {\n>         /*\n>          * this will be extremely unlikely: that we got yet another network\n>          * issue during recovering of the 1st network failure.. during this\n>          * period the main migration thread can be waiting on rp_sem for\n>          * this thread to sync with the other side.\n>          *\n>          * When this happens, explicitly kick the migration thread out of\n>          * RECOVER stage and back to PAUSED, so the admin can try\n>          * everything again.\n>          */\n>         migration_rp_kick(ms);\n>     }\n>\n> It achieves some similar goal, where the migration thread is waiting for\n> some event from return path thread, and when the channel is broken we want\n> to kick it out.\n>\n> I'm thinking if we can reuse that, instead of kicking multiple events.\n>\n> Say, we can do migration_rp_kick() for both POSTCOPY_RECOVER and\n> POSTCOPY_DEVICE states in the rp thread.  Meanwhile at below..\n>\n> >      }\n> >\n> >      if (ms->state == MIGRATION_STATUS_POSTCOPY_RECOVER) {\n> > @@ -3232,6 +3241,17 @@ static MigIterateState\n> migration_iteration_run(MigrationState *s)\n> >               * package before actually completing.\n> >               */\n> >              qemu_event_wait(&s->postcopy_package_loaded_event);\n> > +            /*\n> > +             * Check for errors in case the migration thread was stuck\n> in\n> > +             * POSTCOPY_DEVICE state waiting for the\n> > +             * postcopy_package_loaded_event which was never set.\n> > +             * If so, fail now and break out of the iteration.\n> > +             */\n> > +            if (migrate_has_error(s)) {\n> > +                migrate_set_state(&s->state,\n> MIGRATION_STATUS_POSTCOPY_DEVICE,\n> > +                                  MIGRATION_STATUS_FAILING);\n> > +                return MIG_ITERATE_BREAK;\n> > +            }\n>\n> ... instead of waiting on postcopy_package_loaded_event, we can do:\n>\n>     while (!s->postcopy_package_loaded) {\n>         if (migration_rp_wait(s)) {\n>             /* Error happened */\n>             migrate_set_state(&s->state, MIGRATION_STATUS_POSTCOPY_DEVICE,\n>                               MIGRATION_STATUS_FAILING);\n>             return MIG_ITERATE_BREAK;\n>         }\n>     }\n>     /* Acknowledgement received from dest */\n>     migrate_set_state(&s->state, MIGRATION_STATUS_POSTCOPY_DEVICE,\n>                       MIGRATION_STATUS_POSTCOPY_ACTIVE);\n>\n> PS: I think event also works in this case, so likely either one shared sem\n> or event should work; it's just that it was a sem before, and rp_sem has a\n> name that is generic enough to apply directly to the\n> postcopy_package_loaded_event use case.\n>\n> Thanks,\n>\n> >              migrate_set_state(&s->state,\n> MIGRATION_STATUS_POSTCOPY_DEVICE,\n> >                                MIGRATION_STATUS_POSTCOPY_ACTIVE);\n> >          }\n> > --\n> > 2.53.0\n> >\n>\n> --\n> Peter Xu\n>\n>\nThanks for the feedback Peter. I will update the patch accordingly and\nsend it again.\n\nRegards\nPranav Tyagi","headers":{"Return-Path":"<qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=D8lSFq8M;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=google header.b=j1wLTSot;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g0tG95s9lz1yCv\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 22 Apr 2026 18:50:09 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from <qemu-devel-bounces@nongnu.org>)\n\tid 1wFTHQ-00053o-2z; Wed, 22 Apr 2026 04:49:56 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <prtyagi@redhat.com>)\n id 1wFTHL-00053M-Pn\n for qemu-devel@nongnu.org; Wed, 22 Apr 2026 04:49:52 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.133.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <prtyagi@redhat.com>)\n id 1wFTHJ-0005OV-T9\n for qemu-devel@nongnu.org; Wed, 22 Apr 2026 04:49:51 -0400","from mail-ed1-f70.google.com (mail-ed1-f70.google.com\n [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-390-wL1T8wpUMVGMwqyKZPHSUw-1; Wed, 22 Apr 2026 04:49:47 -0400","by mail-ed1-f70.google.com with SMTP id\n 4fb4d7f45d1cf-671bcc1e533so4959460a12.0\n for <qemu-devel@nongnu.org>; Wed, 22 Apr 2026 01:49:46 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1776847788;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=tNkAcbWXWEw9ZDgYlv0BbsLbeoubW3bqnY7/+McjXGU=;\n b=D8lSFq8M0WFn91KQEVn9K+LFFQunOoLFmwvslnuR/O3V4gQtucnhwHTiYVsv8CKVrdkai3\n 7arNSKqYp4coKP2NYt9CDi5D46tJTHWUy6e3K49KzCVWvLtbMO4YdfTNsUbfVQCjAnFDLd\n yn0gtqTbjKHFaBrLGa/Mjh+h9G+Wc0Y=","v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=redhat.com; s=google; t=1776847786; x=1777452586; darn=nongnu.org;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=tNkAcbWXWEw9ZDgYlv0BbsLbeoubW3bqnY7/+McjXGU=;\n b=j1wLTSotaoejHus4GNqPYXhAo/jJMhgDFJshRT4sseaorlD9sj/Uzoqvy6QxB6IvAx\n 0+aW5DRe5p9Gmk9LX4aTiRnM3fbsXZkj8ZBMB2ag0+vd84HomnJuF3dsAGfO/nwsg6or\n imB60zO48OroZ0JgKDJ3XCJvcISOVRcEhtjBNWiO5ZNaMAOPfF5LbZjHgOetcnC3F79r\n DsH9J4OSgJ5+UR/ms9/mV4LmWrrn5BTy8CRcTmwziEgfoCzl/0mw0s4LDdjvRE4aPqx4\n yFsfpld8SUWFGhzqZ2/iPndrxt7iLro31Y7KqSe8UPzR7w2/+jJ/34QZGQeu+g8Miwzg\n 4ePA=="],"X-MC-Unique":"wL1T8wpUMVGMwqyKZPHSUw-1","X-Mimecast-MFC-AGG-ID":"wL1T8wpUMVGMwqyKZPHSUw_1776847786","ARC-Seal":"i=1; a=rsa-sha256; t=1776847786; cv=none;\n d=google.com; s=arc-20240605;\n b=PgAlOZfJHKJElUkBCHz6Orm7DajevAOIvokqloy0UHm2X3NprltZFOAx7B2Ky42s2H\n 75XidaCZSi4ZAklBa2hbUrFleekzQL1t990mJD+n4cU9D2lHQA5sT3LDC0pVg30R9p1l\n 1ammwLOeXs6+OL+2rqG4SsAzhzi0+jK61LY59Z4hR6K/uLttY5Wo2AAOBKl8T9UIaFm7\n 1pKXwaNT74AJvtpSwNkwFJnyeq+cFqxJSLp/IgpTUNODqBaJcp0sHE01qJ5sZfcNbzRN\n oV0XtAa5MGOkkEY/mwQEGbpt5wFiK/EuN+/jyMGhSu8Eb3Ex2WU2NBYI4cK7ajbkwqCe\n Gixg==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=tNkAcbWXWEw9ZDgYlv0BbsLbeoubW3bqnY7/+McjXGU=;\n fh=tqeddvYnnfVFRES8/MufanmBVJwlsV6HFTbK+mWQ8lQ=;\n b=AD6D9Mi5cqTylcyEr0UWk+wYQMQhl2dKVd//Tvh8t+tctQVavxUGNaI99x0/3aaWBV\n yBeb2g00inQZkvJ5VVaSXIH4k2EsjkiNFvvJhrcTFY1lX+YDJ6MdfrQTLyKTeDLBE3og\n 8cVWdx2QSzyh5Plo3zUwMk9sUWGxBFZoKyW8C3Qjtl4J5q4Xkl6QIhx4qmYaGzik7fKF\n 7yWRxTEj+KtZ7qjzNde/RlAKrslCzocczncUBU+X8/mYA71LDlUcQMvkj17uJ10fwQZ7\n +ftIdQgyuH34Nm1j6t4r11SfjsnkbWlHSI21cTe7tnzwPfnV/Ol/y4KV0QJRNq2/j3S8\n 9+Jg==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776847786; x=1777452586;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=tNkAcbWXWEw9ZDgYlv0BbsLbeoubW3bqnY7/+McjXGU=;\n b=hZ7Y2tStRmXHthuwypAuqYfNFr67tBhtet0j82Sb6iUvU8nuyXz2SlvEm5MC8ioOJZ\n Hbfz3McNxalMWr9nLnEcsnnH/cCsujRib+tW/J5l/dS/ugLIjuDtunIDZAghVAJ/a/+9\n aCO/wwdYl6xqkY9wQyL6Altz4CVg/B8NCYu4MyRNUHWL8haAwY7ue1F9oSUMX3lKmDZf\n EQfkn4pdTjLrLEFeUYCI6UZ9b+0hk7zFKVl21qeTmQV5vRqtUm5ANDtmJGntOtX8xvIc\n 7vDx5fhvmLHdvEcPmR+bGAwNDmmW2X+pk2Ybzrq74pBjyB6gisLwb2J3G9VEgpt51Bnf\n Zuww==","X-Gm-Message-State":"AOJu0YxU8opgQKt2yaUMu6+uVnklbzW+8uIz3QHs9kgqKOgKba0mVRkz\n jv7MnCq/JWarn1OVQbjS0VdDwBefUV9CG4hvvXxwdDAp61+v0G0sDC0oe1HydtcLPP/W4WDlsrE\n fVAG54ungVlTbGiAjbEcy80qoPGg0aewnShjv2TrWNnse5osrxS6MnkkfWMjrDzDWols0mhCVuW\n 3yUyiRpSy2GpgbHiLZL2YtxefBdiKMpv4=","X-Gm-Gg":"AeBDiesG/YFU7sAsfOB3YvapmPCzHafTzO4dt0MFl+kL7hsjhJUbYz5Sh8Cb8RgnjsP\n dNAlTtbchSzfC/NuiUGOZmw+urc8MkedIawemW8FTXnrClF4Ol7a8oU74vs8MAMDl9gvTYJ516I\n ZeHS0j7ExbGPqj+XbofbZfTET8jSsakQHbnkIyWMR449d2OGGa/hfZW2DMPw3gwzStErcKeaMKM\n fGZ+UwosSUS/vjL5l4=","X-Received":["by 2002:a05:6402:13cf:b0:66b:e8e5:4628 with SMTP id\n 4fb4d7f45d1cf-672bfdd8b9emr10166081a12.20.1776847785795;\n Wed, 22 Apr 2026 01:49:45 -0700 (PDT)","by 2002:a05:6402:13cf:b0:66b:e8e5:4628 with SMTP id\n 4fb4d7f45d1cf-672bfdd8b9emr10166066a12.20.1776847785293; Wed, 22 Apr 2026\n 01:49:45 -0700 (PDT)"],"MIME-Version":"1.0","References":"<20260421052227.8278-1-prtyagi@redhat.com>\n <aefrPBN7k94Jj2dh@x1.local>","In-Reply-To":"<aefrPBN7k94Jj2dh@x1.local>","From":"Pranav Tyagi <prtyagi@redhat.com>","Date":"Wed, 22 Apr 2026 14:19:33 +0530","X-Gm-Features":"AQROBzDRDrTLFK11eXc1T2T-D5zqW0fUBP5819oE1Eeh6vsBBahCRJEnTQABbjc","Message-ID":"\n <CALY4kkSJRqTpcBwe2UAJHJQBQGU7Tt1oWnX3nUECUKZPA=g3eA@mail.gmail.com>","Subject":"Re: [PATCH] migration: Fix blocking in POSTCOPY_DEVICE during package\n load","To":"Peter Xu <peterx@redhat.com>","Cc":"qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,\n Juraj Marcin <jmarcin@redhat.com>, Prasad Pandit <ppandit@redhat.com>","Content-Type":"multipart/alternative; boundary=\"0000000000001018910650089d32\"","Received-SPF":"pass client-ip=170.10.133.124; envelope-from=prtyagi@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development <qemu-devel.nongnu.org>","List-Unsubscribe":"<https://lists.nongnu.org/mailman/options/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>","List-Archive":"<https://lists.nongnu.org/archive/html/qemu-devel>","List-Post":"<mailto:qemu-devel@nongnu.org>","List-Help":"<mailto:qemu-devel-request@nongnu.org?subject=help>","List-Subscribe":"<https://lists.nongnu.org/mailman/listinfo/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=subscribe>","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]