From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazon11023075.outbound.protection.outlook.com [40.107.159.75]) by lore.virtuozzo.com (Postfix) with ESMTPS id 28CFC80460 for ; Fri, 16 Oct 2026 15:41:22 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gFazjXvm89xzqHN9qoes8OXvwg8J+4AUDV6xOEvhf3JiufJyTWXDIwNrVGvP2UgvTmDLmuHlJ0znZsxWcEuzjGMMuIkzU8W3GGHexdMxDdMhVjsPJj8RefUZmVZWzm8NWw0oFhj9LZYPXFTxWT66UU6lsJ8t1tB7Xm47V7QYDmL+XnjmzAovyAy4N8q/Ah25qA/AAOBFXHEYmfc90JF4Dt6cHag5uBhy+9YySdnoWkKwVHveEJriOIbs0AB98QCe2sletBWpRPo2Dq6Kfz1+6s5yd17mPJLBcZDIuher9ythSvAjUfHy7jGqySNAq2S9DSOjdjLutKYxQ9TE60PHVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Zi7cddxPxTu+Go2N3bnvuBqrQX1DhVvuCDCKssAsyaM=; b=w7jruLSKe8EioicabLyGZ8o1LiyjOg79rqBpyLReq3fnFg7t58dA4+07Xl8KBPMJm5bliTdqTXmA9p+/SSlgLwfMwO/wirAJUJB2LRgln5IuCeid4E4b9EMB0asnMqLEt5EzZGbHrLuGvHEGk2dn4+gQS6tyy5nGdAnwpzvbXMqXhAvn9SACh1tDbbwSSPe9+tJuDlDdcbIvSXbnerFUJgau7GbAhjyYQf5To2IfGjs14pcJ66yoPoJIt3cAhfkvHJm1n2HCqUXVhPoyhFsSIGM7y3t+rVjSvFqv6UGrxEKdlwYRerX0rI6NgKiLrayMcOec6PQnJXQoNKIf3QZIZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.1) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zi7cddxPxTu+Go2N3bnvuBqrQX1DhVvuCDCKssAsyaM=; b=m2n/OUj0a/IWW/FT7bpul2pn4lx8ANavhxzdF/LkYflDYEwKlGQzODOu8Lz7iHEiqLRV0kWFpKwYfOHeKW9QIIqJXOvP0pU35JE3ATpihaKjA1FIry9XsjKkEKDx2W5epzY6Bjjo5/EMc0UKXB4CLqLucB6kvfOmfVAuaOzqByc= Received: from PAZP264CA0034.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:122::21) by DB5PR08MB10062.eurprd08.prod.outlook.com (2603:10a6:10:48f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.8; Fri, 16 Oct 2026 15:41:15 +0000 Received: from MI3PEPF00008556.eurprd05.prod.outlook.com (2603:10a6:102:122:cafe::e) by PAZP264CA0034.outlook.office365.com (2603:10a6:102:122::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Fri, 16 Oct 2026 15:41:15 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.1) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.1 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.1; helo=b224-1.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-1.smtp-out.eu-central-1.amazonses.com (69.169.224.1) by MI3PEPF00008556.mail.protection.outlook.com (10.167.240.10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Fri, 16 Oct 2026 15:41:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1792165274; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=CHRniCty2RQ69rOCXunvQ7aj5ZPshm+aDxawilFyJ1o=; b=NGzLfVZCahqgVQH3DOWwtBlIgV8wt+m0I4gwZADg6UOowF7I6PgSQCsEZkd0O3aA PNPhDgIzjChTpnD08YU2cJoHxIUTgoPu2PLWAhevm65alBWG11GbBgWBYwZQfOBqAAB 4E5YlwPOUe4bsCmM35RC8WV3fVp+LUc6uOkwubHe7XHbmOokvhH9O/6KUgU+6Nxm2rq m2x3ZwYwI03Fw24ag1eUicVRjyqgOnUr3Gp0X+yhNVNyzFr7eTLH3bl7v3FoZLxYIaZ CcYR5JjKbpkqDeJU5iKAhevp8N0n3+3K93CY89aH+LL/ZsFfPrnxhKxd5euDj9A3uLL 6E+hUf4fNA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1792165274; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=CHRniCty2RQ69rOCXunvQ7aj5ZPshm+aDxawilFyJ1o=; b=de0wwcaGpZuxC9ukiBuorKK89IBK+/nl2Zzi91jh/+JBjYT9p8wqng1qVBXbJ1r2 AbdTYR4RUFBKstHp6QsslK+RGSRtDElljPJCeDZ7AYBqIEcnUph6EGaJMQySl5Mhpwq MkZhyPfh7sjdo8E/Dq3+7VP1eCDUlS95NY1VENU8= Message-ID: <010701a1455fe4c8-3eeb58b3-a873-41d4-a71f-71af90706cd0-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v3 14/28] migration: yank: Move register instance earlier To: Andrey Drobyshev , svt-core@virtuozzo.com Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261016-vfio_v1-v3-14-47487cb5a8e5@virtuozzo.com> References: <20261016-vfio_v1-v3-0-47487cb5a8e5@virtuozzo.com> <20261016-vfio_v1-v3-14-47487cb5a8e5@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2026 15:41:14 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.16-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MI3PEPF00008556:EE_|DB5PR08MB10062:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: edb45f81-0376-43eb-2bcd-08df2b9be9d6 X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|32142699015|9140799003|61400799027|376014|48200799018|260925022911599003|5063699009|56012099006|260925021311599003|5023799004|4143699003|261009223027099003|10067099003|260925021911599003|55112099003|16102099003|5113699003|4113699003|6133799003|18002099003|22082099003|13003099007; X-Microsoft-Antispam-Message-Info: EMMCop7TtR69GvZoKoQo0hDfBrrKtgGSa0ZNFmji5vtgNr9O1iLuWw1+dc9XAO9Zs8WAoxNXKklEdLv4WyaSO8VIUd9cqlJDOlJStrx0MmjLS3mcK+0Zt4hVVEnvhXj4t81+7mQYKpHHr12Ww6vxgGYY6fKknipGoRM2glOF/eGH+5v69OPmHpZCxZ9EjDNmy0AuZJ1gwCj4L/fZhMlN69tnQrfRXAWS8Hj10XSde6LI4+xinpM9FfndvIqcCpU2d13adYM+pA2fqplj+5O/uekzOzOFcYL3pffTE2S4EGTKMmUAhqhcgr7OH0TZyxpnhO7p0u9z5pIWWUzc5vg+9PW0a0fcFHyOWjkBFJtZGhRVM4H7hQzKg6ovyxH9Cs79JnjK5MkHO8NUCTqt6cYDLtJyM253i5/RAZD1H3qLJyS2VNAzmsPkCpuLAgBRSMtSXrtat8QaNqshwOuRhrgHsRKSmLs4CoG2yvuvLvC+Xq3aJ+Ua11VxKZG4ASjzfpNK/74XxUD4z22Lz7ZQK1IAJ/0Ok89+6L1dcpnWP76qlt/A4nkX9n26P/2HmWRkjaZx35JQ327cdAxDer+vO4xltCYCqvNmnZchONom3c2/vAWpSGvbJiOysyoUcWPdO0Lr4+bn4s2Y92rjkl1yEVojs2qiBQdG6yjbqB0vtdmx5np0SROEWG/w19FhxzyW06RU0GUMh9Up2K1xKgvwUAsJnH0Nhy0fucE8u5aEJR5AdaGxP0bl9WEhXoZ4fut0633xP65+EWfb1+YtLbghEAEvW1fXdY/uFS0w9s2InslkVKlVtneWDgoW7AdmZzpSuylqoBKhd5qa4q7XRcPDc3UAXw== X-Forefront-Antispam-Report: CIP:69.169.224.1;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-1.smtp-out.eu-central-1.amazonses.com;PTR:b224-1.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(32142699015)(9140799003)(61400799027)(376014)(48200799018)(260925022911599003)(5063699009)(56012099006)(260925021311599003)(5023799004)(4143699003)(261009223027099003)(10067099003)(260925021911599003)(55112099003)(16102099003)(5113699003)(4113699003)(6133799003)(18002099003)(22082099003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: rxB5v1fIWZE6/qjE/mPwYMHQkreS7x8LtBMnczpu7am2IpU1Xorh8wlCQwA93/4Zr3X5Ojz3FD1TeQux9KEghg+y4OZ8bGSq/VPmzSYf+Pusyty2cvjwC/xFVHHXoPkrmJz/2/pqMElSvUTxkKZEmo1acM/7qNIQ2Q0Vmnq5CC6orE94JChEe7nbZwY9BFCxxjnsrZ2nf3EYw0eAD4/c6irkKjdgRhTdf3+Wz9Q8bBoy+4N6dbmRcI3BvVQZNc6e5JNeggZcMmWwkgxT7FltaLQZTb4/b2GgRTP48vEirmFDIc2GE0IeGHuNwTSpKD7m7hC/qZ0TUA5NSNLoilAApBZJrqGHy+sz4H4JxC6yx9/NLH/bWjgaci3YhYR+jH5uM4nm9a+Ei/939qrPlKPTWzYKgSLxoNZcGVOIQLj8vWOO1H/O6LdRIH1uQVZleutJ X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 15:41:15.2313 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: edb45f81-0376-43eb-2bcd-08df2b9be9d6 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF00008556.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10062 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [High] migration: stale incoming_postcopy_state makes migrate_prepare() r= efuse all later outgoing migrations - [Medium] migration: migrate_prepare() registers yank with &error_abort, a= borting QEMU if cleanup is pending -- Commit ce0aafa8f0f4f6ebc0a21db9c39794339fc1b277 Author: Fabiano Rosas migration: yank: Move register instance earlier This commit moves yank_register_instance() into migrate_prepare() so it pairs with the unregister in migration_cleanup(). It also adds a guard that refuses a non-resume migrate while an incoming postcopy migration is in progress, and reworks the error-path unregister logic in qmp_migrate() and qmp_migrate_finish(). Link: https://lore.kernel.org/qemu-devel/20260123141656.6765-11-farosas@sus= e.de > diff --git a/migration/migration.c b/migration/migration.c > index 2f8ef20c0369..0b8309565323 100644 > --- a/migration/migration.c > +++ b/migration/migration.c [ ... ] > @@ -2174,6 +2174,15 @@ static bool migrate_prepare(MigrationState *s, boo= l resume, Error **errp) > return false; > } > =20 > + /* > + * The guest already runs during incoming postcopy, but the incoming > + * migration still holds the yank instance registered below. > + */ > + if (migration_incoming_postcopy_advised()) { > + error_setg(errp, "Incoming postcopy migration is still in progre= ss"); > + return false; > + } > + [Severity: High] Can this guard reject every later outgoing migrate on a VM whose incoming migration has already finished? migration_incoming_postcopy_advised() evaluates: PostcopyState ps =3D postcopy_state_get(); return ps >=3D POSTCOPY_INCOMING_ADVISE && ps < POSTCOPY_INCOMING_END; Only the postcopy listen thread ever sets POSTCOPY_INCOMING_END. Consider this sequence on the destination with postcopy-ram enabled: loadvm_postcopy_handle_advise() postcopy_state_set(POSTCOPY_INCOMING_ADVISE); (the len =3D=3D 0 case with !migrate_postcopy_ram() also returns 0 without resetting the state) Precopy then completes without postcopy starting, so LISTEN and the listen thread never run: process_incoming_migration_co() if (ps =3D=3D POSTCOPY_INCOMING_ADVISE) { postcopy_ram_incoming_cleanup(mis); } ... process_incoming_migration_bh() migration_incoming_state_destroy() <- yank instance released here postcopy_ram_incoming_cleanup() does not reset the state, and none of the other postcopy_state_set() callers run on this path or on the ret < 0 fail: path. The state therefore stays at ADVISE (or DISCARD, LISTENING or RUNNING after some failures). After that, migration_incoming_postcopy_advised() stays true, and every non-resume QMP migrate returns "Incoming postcopy migration is still in progress", even though the incoming side no longer holds the yank instance. Chained migration (A->B->C) looks like a realistic trigger. The refusal appears to last until a new incoming migration starts or QEMU is restarted. I did not find anything later in the series that resets the state or narrows this check. Should the guard test whether the incoming side still holds the yank instance, or should the postcopy state be reset when incoming migration finishes or fails? [ ... ] > @@ -2235,11 +2244,12 @@ static bool migrate_prepare(MigrationState *s, bo= ol resume, Error **errp) > return false; > } > =20 > + yank_register_instance(MIGRATION_YANK_INSTANCE, &error_abort); > + > return true; > } [Severity: Medium] Can this abort QEMU instead of returning a QMP error when the previous outgoing migration's cleanup has not run yet? The unregister is the last step of migration_cleanup(), which runs only from the bottom half scheduled in migration_iteration_finish(): migration_thread() s->state set to FAILED (or COMPLETED) migration_iteration_finish() bql_lock(); ... migration_bh_schedule(migration_cleanup_bh, s); bql_unlock(); Between the terminal state change and the bottom half running, the main loop can process a QMP migrate command. In that window migration_is_running() returns false, since FAILED, CANCELLED and COMPLETED fall into its default case: case MIGRATION_STATUS_CANCELLING: case MIGRATION_STATUS_COLO: return true; default: return false; The RUN_STATE_POSTMIGRATE check does not catch it either, as that is set later in migration_iteration_finish(). migrate_init() does not look at a pending cleanup. So migrate_prepare() can reach: yank_register_instance(MIGRATION_YANK_INSTANCE, &error_abort); while the old instance is still registered. yank_register_instance() then does error_setg(errp, "duplicate yank instance"), which with &error_abort calls abort(). Before this patch the registration in qmp_migrate_finish() used the caller's errp, so the same race produced a QMP error. The commit message adds a guard for the incoming postcopy case for this reason, but nothing similar covers the outgoing cleanup-pending window. The later patches through the series end do not change this. Could this use a non-fatal errp and return an error from migrate_prepare() instead, or could migrate_prepare() reject the request while cleanup is still pending? [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261016-vfio= _v1-v3-0-47487cb5a8e5@virtuozzo.com?part=3D14