From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from DB3PR0202CU003.outbound.protection.outlook.com (mail-northeuropeazon11020129.outbound.protection.outlook.com [52.101.84.129]) by lore.virtuozzo.com (Postfix) with ESMTPS id B6281802A5 for ; Tue, 13 Oct 2026 15:45:24 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KBcAkMwgUW3AorJ9bbCN7/GxW15aBcUY6+XPaSid7v0cALpefxEysR17g9RpsNkB+FVioG8EVk4FMaFDXxJ9QTq4kFaa7t6hw2z9Nt1wNVVinXSptyGLyJMdO8xXCmJhoVTta/Xui3gIQeTOTHflEkK1p9zCUxZEnkzNsTRmVgoLp6+mjm59QROj1Q8G9LSxeYhwvRT56NMVem4gDHYBTMnAf6hpie2FPFQz8B1fUE+94D5umMdamwJbjqSY7Vbh44hinivQi5R4gZO3b/3FIrAfsXHDLnLifSLacTB38XbAFZNp1swC3GVyOc8tAaEjZv5bz9EkVlj1U6CTM+KuvQ== 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=UHzMKpQM4We0S0obiIjqt9alnXErkbX0sk/PlMG7bkk=; b=quUGuamy6mAZvfBPtqc3a+PPHv6aJqZiJv/d23uFoVwLtZHj+aYmNG4XlGyxt0RhiqHOMymj1+rSfqmGJ95inXXZUSgfJxWYy9i4F/2+A1Rl6B3tAiZYh4cTLKGQg5jqUGD/P81bHqfOK0C4nxlBrDOuhoNd6HGpROwGl1uVYI9ZL95BBlb1j0psTP8Sa/KFUSpwVcQlUaBCFLj6wHBmZ/SsvgeJ/vHIisU3PozfnidjN/P+YmdsrXryrIbFGrzzu3sKxGn11Tw1SczM3g2T8F9QW20w1KIqfVwqYbx5xE033KQlkWaEmHRAuaESXfRMwIGDAqvfgIb3LDAeMLigSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.5) 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=UHzMKpQM4We0S0obiIjqt9alnXErkbX0sk/PlMG7bkk=; b=nxCdHYAPSokxzwSnFObYAemdu4bKateYhbHMpAioB9WvLcocFpa9VYxzB8XSnJvJyOdf1E3ItYJ3qIF7pJwf/IFXuqJTbZmbd8g+NGp2AdFBbj+sFjkHGJPq+tBVQXMqO+fHzbDcbpHqVjJ9980WrvmQO9OzKlmT6TkzjAK9mpw= Received: from PR1P264CA0001.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:19e::6) by DU0PR08MB9775.eurprd08.prod.outlook.com (2603:10a6:10:444::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Tue, 13 Oct 2026 15:45:18 +0000 Received: from MAD0EPF000008C6.eurprd05.prod.outlook.com (2603:10a6:102:19e:cafe::5a) by PR1P264CA0001.outlook.office365.com (2603:10a6:102:19e::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Tue, 13 Oct 2026 15:45:18 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.5) 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.5 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.5; helo=b224-5.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-5.smtp-out.eu-central-1.amazonses.com (69.169.224.5) by MAD0EPF000008C6.mail.protection.outlook.com (10.167.241.202) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Tue, 13 Oct 2026 15:45:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791906317; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=8UUPK5pBfw5gGzgzHIMNst+Sv0pkB2TpF6RiNjGBRIY=; b=SMsorYEydogyKP3Ho5scmxs4IMIdoCfA9YKPBidHzKefEGnCfM71B1cv852HXIlT CTc2mMlNbfMHe1ag85Y4Ul8Z/CPjx5nm3Wv74Vv1uShqVD2T//LFAY8oM3dFjuMrsAx 0iCItIuuWizxU7jS6fLsjRtulAdNQOheD1c0h6zSYCmkCM/ygO1wvX5pACMI6/C8s5k jMX4asIuif/c9ES9M3RYE/TRHXCovXxY+t1+cGCAbW8sWbttUGfF+hIKFN3XNNH138O oNm1WTY3GfvwMO9G/WqHVOnhtZyFImBwmUifI765kTn9WzFc4OEqCjDxmvUUvmQwNoJ 5+uLcB90Vw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791906317; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=8UUPK5pBfw5gGzgzHIMNst+Sv0pkB2TpF6RiNjGBRIY=; b=bC75KdpVbpGWKVQi3QBV5ZkT4iM6N4Y7yVJzaK1badWkgHSbH9O7w8eGPXXlfDeH 00hcFPAACagHZI5FZcIZR312Td6tCo7tOaEbq0/shxQhIuc6FEuIADM/9nHeZkF1hNq LudzOyBcJldFRzeH11VnY68EHPgfJ1epb9wNGGF8= Message-ID: <010701a135f083b9-60fd3adb-fecf-4813-80e3-2ba9420e14ef-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v2 14/24] migration: Fix crash on second migration when cancel early To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261013-vfio_v1-v2-14-433455c0a294@virtuozzo.com> References: <20261013-vfio_v1-v2-0-433455c0a294@virtuozzo.com> <20261013-vfio_v1-v2-14-433455c0a294@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2026 15:45:17 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.13-69.169.224.5 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MAD0EPF000008C6:EE_|DU0PR08MB9775:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 0b2199cc-286e-4ccd-36f0-08df2940fb30 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|48200799018|9140799003|61400799027|32142699015|376014|261009223027099003|5113699003|6133799003|4113699003|4143699003|56012099006|5063699009|22082099003|16102099003|18002099003|55112099003|10067099003|10063799003|3023799007|13003099007; X-Microsoft-Antispam-Message-Info: ++SrYtBJJ39W3x0+ZCkLBWuYrgdM199Zx2Fcg7LQ1JFNxBGJbI2P5S3+UieHnKLvxANEUnjq8shqYQbQqO2csjY8R9/nGkjQfUAr84OUbLVEwJH/FxeIRg4z2fi8Z/6uTw3gkGXxkfME31kKMbLrT9P3Bv3BsfbfJWQ7DwhrfQkIQ4FBoaV7aNts/sIAHyNm/u/CmQnaaFnZl/Ek9K0Z8UbKRET+g+sPdceOlgGoveOtjmMsrFufCCH2O+OT0ZmUhoJ4DpqWF+Cp2XkwTYTop2CQ9TgtDvZRnDjRavag6/IdPhnRYYtZRPQotVQW+mw4QKIcMsRnvXep7rybo0Vp1iTv8CWYR7BUfdwSTS60pGuryS6iywI/wnrMMLanD1pe87E54IDAW6RGnK81vq0XwEilKPte5fLH9oWbORYLCGrk0T9HW+JqDYCqtcDGaCOF84LFlS5Xchq6UuYyw0vtUMBE4Bg5sOrP+PmwVD7TzWzqHijtsN8obD3HExnOZvXmtAJpKfvIXPG3iC239Lugn+TR2MaXcKnlsp/CC+M1VDzfc+jxnV/OrPhl3oF1OoJI5N2PpadbySX3XODKTg5dpk1EUDalaDFvDLW544V/CEehk3UXRnvDPcxVm7QdR3OqW0FP7MsZXXKbbLDxwjPAqPiYByZLVYB6DTUnLe0QToipYhHpRJiN/mjZcftZg4M5ulWXrUvFlJDPbbsXWnLBWHmBDT+uu7B1hr1L3pi4z0E+KnJNPtOiISWsbpvtOGbjPtqlSn4geEIOg7u9IgLm2WySMQJ03lBA60oPwQ0DMHZ2AUoJTPodErvxZUH1nEU4J6uB0iwJvHSR/+oPiKcsBw== X-Forefront-Antispam-Report: CIP:69.169.224.5;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-5.smtp-out.eu-central-1.amazonses.com;PTR:b224-5.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(48200799018)(9140799003)(61400799027)(32142699015)(376014)(261009223027099003)(5113699003)(6133799003)(4113699003)(4143699003)(56012099006)(5063699009)(22082099003)(16102099003)(18002099003)(55112099003)(10067099003)(10063799003)(3023799007)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: BW+Q49RZ7QtjKaUrFn7IvvpFiAFNSt7Ti1BOCa6emrbHQj2gZPMeycnMm5Wu4UcQwIf8tOKvskADyG//dKsHYZJLw1ZjonL8Ctc+fHgc0i3eABXTpt7ZYjx1D20DEUE06aD6/f9Sk1l2yQtvP+/td8+GR3Kc1wDqey7ncgkOi/4LQktDYLPwQkT/t2+0JMM/mn0QDv9Iq1WO5qdHsukHOa2L9AWTJWFVH+BTFIsrC9Bt9FAd+AYnP3SP4m3G9tSg/KWc98tCu182zQxjBM1lOezKtb/1TOnTG1r5sJ5N0Wf+6Or4Ek7x3kmm7c++PZSHS5qPmAa0YHx7EzRZLCHK0XLMSIEn5EVmz+RXWlsEVkVfHQR6/Kt4t9f5CPUgGtnjXx/dE7pwnK0i4AMjDbG1h8JOoJdnRkPCYyCAuvyFB+Y29CKuiUSdheAtZ/IMmNAF X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 15:45:17.7853 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0b2199cc-286e-4ccd-36f0-08df2940fb30 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008C6.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9775 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [High] migration: cancel in CPR HUP wait fires FAILED without SETUP, trip= ping notify assert - [Medium] migration: migration_cancel() asserts on live migrate_mode() whi= le hup_source is set -- commit e9dea0ff5e4d16a3a4c776bef4c26e24060a56d5 Author: Peter Xu migration: Fix crash on second migration when cancel early This patch changes migration_cancel() so that, when a cpr-transfer migration is waiting for the HUP event on the CPR channel, it calls migration_cleanup() instead of directly setting the CANCELLED state. It also detaches hup_source at the start of qmp_migrate_finish_cb() so the wait window can be detected, and adds several assertions. Link: https://lore.kernel.org/r/20260417184742.293061-1-marcandre.lureau@re= dhat.com Link: https://lore.kernel.org/r/20260421175820.302795-1-peterx@redhat.com > diff --git a/migration/migration.c b/migration/migration.c > index 14ff16fa6a4e7..2e4be2db65ddd 100644 > --- a/migration/migration.c > +++ b/migration/migration.c [ ... ] > @@ -1653,14 +1653,19 @@ void migration_cancel(void) > } > =20 > /* > - * If qmp_migrate_finish has not been called, then there is no path = that > - * will complete the cancellation. Do it now. > + * This is cpr-transfer specific processing. > + * > + * If this is true, it means cpr-transfer migration is waiting for t= he > + * destination to send HUP event on CPR channel to continue the next > + * phase. If so, do the cleanup proactively to avoid get stuck in > + * CANCELLING state. > */ > - if (setup && !s->to_dst_file) { > - migrate_set_state(&s->state, MIGRATION_STATUS_CANCELLING, > - MIGRATION_STATUS_CANCELLED); > - cpr_state_close(); > - cpr_transfer_source_destroy(s); > + if (cpr_transfer_source_active(s)) { > + assert(migrate_mode() =3D=3D MIG_MODE_CPR_TRANSFER); [Severity: Medium] Can this assert abort QEMU? migrate_mode() returns the live value of migrate_get_current()->parameters.mode, since cpr_get_incoming_mode() is NONE on the source. Consider this sequence: qmp_migrate() with mode=3Dcpr-transfer cpr_transfer_add_hup_watch() /* sets s->hup_source, state is SETUP */ migrate-set-parameters mode=3Dnormal qmp_migrate_set_parameters()->migrate_params_apply() s->parameters.mode =3D params->mode; migrate-cancel migration_cancel() cpr_transfer_source_active(s) is true assert(migrate_mode() =3D=3D MIG_MODE_CPR_TRANSFER) fails As far as I can tell, none of migrate_params_test_apply(), migrate_params_check() or migrate_params_apply() reject a mode change while a migration is running. The same assert can be reached at exit, because migration_shutdown() calls migration_cancel(). Since hup_source being set already implies that cpr-transfer was chosen when the migration started, is this assertion on the mutable global mode needed? Before this patch, migration_cancel() had no such assertion. The second assertion, assert(setup && !s->to_dst_file), did not appear to fire in the cases I checked. > + assert(setup && !s->to_dst_file); > + migration_cleanup(s); [Severity: High] Can this path abort QEMU when a VFIO PCI device is present? migration_cleanup() ends with: migration_call_notifiers(MIG_EVENT_PRECOPY_FAILED, NULL); but in the HUP-wait window migration_connect() has not run yet, so MIG_EVENT_PRECOPY_SETUP was never delivered: qmp_migrate() cpr_transfer_add_hup_watch() /* no SETUP notification yet */ migrate_cancel migration_cancel() migration_cleanup() migration_call_notifiers(MIG_EVENT_PRECOPY_FAILED, NULL) vfio_cpr_pci_notifier() vfio_cpr_set_msi_virq(vdev, errp, true) The FAILED handler in hw/vfio/cpr.c re-adds irqfds that only the SETUP handler removes: if (e->type =3D=3D MIG_EVENT_PRECOPY_SETUP) { return vfio_cpr_set_msi_virq(vdev, errp, false); } else if (e->type =3D=3D MIG_EVENT_PRECOPY_FAILED) { return vfio_cpr_set_msi_virq(vdev, errp, true); } With SETUP skipped, the irqfds are still assigned, so a second KVM_IRQFD assign may fail. I did not find this in the repository. It is from my recollection that KVM rejects a duplicate eventfd with -EBUSY. If so, the notifier returns nonzero and migration_call_notifiers() hits: ret =3D notifier->notify(notifier, &e, errp); if (ret) { assert(type =3D=3D MIG_EVENT_PRECOPY_SETUP); return ret; } The type is FAILED, so the assert fails. Can the cancel path avoid sending FAILED to notifiers when SETUP was never sent? Other notifiers (virtio-net failover, scsi-block, vfio-migration) seem to tolerate an unpaired FAILED and do not return errors. The same unpaired FAILED already exists in the migration_connect() error_in path. This patch adds a new route to it that a user can trigger easily. The later patches in the series do not appear to address this. The series later removes the VFIO CPR block in migrate_cpr_is_blocked(), which makes the VFIO plus cpr-transfer configuration reachable. > + /* Now all things should have been released */ > + assert(!cpr_transfer_source_active(s)); > } > } [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261013-vfio= _v1-v2-0-433455c0a294@virtuozzo.com?part=3D14