From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from DB3PR0202CU003.outbound.protection.outlook.com (mail-northeuropeazon11020119.outbound.protection.outlook.com [52.101.84.119]) by lore.virtuozzo.com (Postfix) with ESMTPS id B788B8045D for ; Tue, 3 Nov 2026 14:26:02 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V0TBeuQkXN/Up9klvlLTFZ7w77vmw5Tx/LlOlojshp5vU/o424DkQy0BiPRDAjVR/JcgM7YGHf4AQxofbQclSLA25Kcbv9J2JX7HNfWXy9khz0RGjTbITFyTrCyham3rkx6wK3z1eP7BsR+WRV3UA0PWzBchRtLlGkoqw6dnDvqdVBlRAo7b/3GEQ7+0oxnq5t8mFaGzrDqsVgO2ipo3umVbrrkqsvMVjcy3oRiz4YkkfRwVfG0enXcLVm4pKskhScSHEoamWsgcQ4J7HNCBVHQjZ/IKrK3aTZWMKfL/IlDbEnPXmR/0OinquAV5hTy113mLN8OafA7pkDr1SWudnA== 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=/mB/nfCsfH6xTqPAt36i/o8yv3gpUzxVkH8Z4R6Otuc=; b=EZ5akS8crojkv+OvUVLTdw0i3DdcHTCEMaAQcnZWTgU1+PaPUkUXz3q4ENsjoXfSGooUn5foHAcIY+TVHin4IXuO506PU5vxarD7A7rKqOryrJ05lpgbAd5Q+wmNB4Abw6Fat9mCLjmBovD4B+qPjX8wjT2fi/PfrtARoRPaLepKXaIxK/0JXSrEo9wsMYq9GxsJ5/912NrZeYJ3U9t4hHkpP+9NVF7QQX/ixqvboASVDYEs1LiIZOqXWo4/3B63yP1OW2eG7iYHMlvDmThVirlejXmytFw3PecWNgnEvMCK37tZEQxUnhsUIWtZ5f/er7FNToh5FEKqrSnrbxRi+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.2) 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=/mB/nfCsfH6xTqPAt36i/o8yv3gpUzxVkH8Z4R6Otuc=; b=JnNCevxGEFCNGHdLy8iIWDgd/Jl5H8XxXAdW7Fd/uyBFcmrT+HyoFUrJPUUpnzjCAk+XrZlle/SCxgzFBlvbewR6TK9ZmiN8qND/mOrp2+LFgPZnP4bMkNV1WB9afNjbOZ03lrxjmrgAB34mKACNxuTpygk7HnfQy0VEX7HJRDU= Received: from AS8PR05CA0022.eurprd05.prod.outlook.com (2603:10a6:20b:311::27) by AS2PR08MB8782.eurprd08.prod.outlook.com (2603:10a6:20b:5e4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.592.8; Tue, 3 Nov 2026 14:25:57 +0000 Received: from CPH1EPF0000051E.eurprd04.prod.outlook.com (2603:10a6:20b:311:cafe::4c) by AS8PR05CA0022.outlook.office365.com (2603:10a6:20b:311::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.592.8 via Frontend Transport; Tue, 3 Nov 2026 14:25:57 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.2) 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.2 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.2; helo=b224-2.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-2.smtp-out.eu-central-1.amazonses.com (69.169.224.2) by CPH1EPF0000051E.mail.protection.outlook.com (10.167.241.233) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.592.5 via Frontend Transport; Tue, 3 Nov 2026 14:25:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793715956; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=yqDuI3HcRleYHxBLUPl7wsYk4KE1eJ967lnpbg53Ssc=; b=OqNOA5HFRV9caen+fK/GS9K9kQkulacvoMg1PvNTgqMbKWciW89k5rreqCiN5JqY 9VojCJaQrn3DmC1Pwc6kbNhhWDHEybgQgnFRozYK501+/4xdoRLCFyLdL0DBtzZfvFL O7d6o6y0deK672zw8AOAhmJvwur5b3JLKc+CwtZhHhGrUeRi7EDHZMCUtt32KFqVq0p V4Eh8M1XoEIc5KWBs8xUDEmI7ehy64lmw8/1q4PcejrORwmKAU1vHeQfx9JU6EcyaKg VRjx282n37VW24TFlONiENS3DA9TaqxGvrsMKt6DMxlymiLYEnCg8E+o03mz8K3m4QY bs63rs++qA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793715956; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=yqDuI3HcRleYHxBLUPl7wsYk4KE1eJ967lnpbg53Ssc=; b=BOBmpca7vKZGM6NeDg90/WQfavrALgKmvWbHya1vShmygTi0en/s8/GYKIQyfCXM xjoq8u3Si2qLbMnAzV5uESFLoUJ/fJOga/8wMJHi4ktdaeUnWYD/ddG3A2iv6dxiPl3 8+uBMMVjKdewXbEj8Lb+W8aoK5TKPBzqY1W0PUII= Message-ID: <010701a1a1cd6bf1-3b7781ee-0993-4de1-a5d5-9f4a2114490b-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v7 27/35] vfio/migration: don't assume the device is running on CPR incoming To: Andrey Drobyshev , svt-core@virtuozzo.com Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261103-vfio_v1-v7-27-4467fdccbbe6@virtuozzo.com> References: <20261103-vfio_v1-v7-0-4467fdccbbe6@virtuozzo.com> <20261103-vfio_v1-v7-27-4467fdccbbe6@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2026 14:25:56 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.11.03-69.169.224.2 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CPH1EPF0000051E:EE_|AS2PR08MB8782:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c8bc9f30-166e-4de8-6cb4-08df39b6605f 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|61400799027|48200799018|376014|9140799003|260925021311599003|260925022911599003|260925021911599003|56012099006|4143699003|5063699009|261009223027099003|261028144727099003|261102123227099003|261021121427099003|261022105027099003|261026121527099003|261026140227099003|10067099003|55112099003|16102099003|22082099003|18002099003|5113699003|4113699003|13003099007; X-Microsoft-Antispam-Message-Info: cdHrbxfICToK7QF9vJIZI6qfYblv6TO4SNN+8zAYsfHPfsaw4T8JZXgRmokVmdEvCk7oha7EeSdhAbnh7gVxVO9kkOAuYYL7YlSZDzsifCkZLAb0jiaYZUMCLHO4/+OQ4El2HzwLrw2oVIed/2wX1Va9Ad6Q3hHJzPyAsLjgLBXYUgAFcqnkjd2Zxbm9rz10A0L7L9Kyh86FEv3LMzB/FmSWbw0cG9XRhPNu9JpArcuxN+xgER71zjMsAY2/VKOsqZ6Uslh+hGMn+ATrl/QPa/H4lhaLqG2/+c8Q2WpetMW070e9qpMM4swtqjEmQRwnFMoNO65HjrKZunFREF62Mf79LfDz/5lWWXtQHlZd/uwYApv+MuWSGI/Duy5uO9ZGbiygVJMfU4pemYZMuSBAOOhyROZzmHn2I9ojku1rZs6PSJndsVU/RNjjwQv95z91FBjJXzWUcUYF2z8h5JbwmLlXVSHXy6pMAjUR0hKDyXrdjHoqLUm31WMB+WyanuItDa1aMJFbnJaEAwJgD29xokg7LbikEoQl5cdcJbHRpEyabbQTmIXYvt0XOJv8p44ysg644qfin3bH2bmb3WXwG/gbteAhawxv9ESvFN9EPZSnsEObefGz1C3pCdlfCB+LqYSrJilEz8K75jaIGWq6tqtdbWy9VrRbBjMVNbmkbVYsrwaXE1qSVD5X8+La65U94xdfAIYfVx2NSeibWfywniVCXCQvrNLhqjVTQZRZUVJdu63CmzffaFokbQpBZcHdBeTQ0wUjzRbojPCPKzEHWB8Ju4/dWoPJB0DwTb0K0dghq5nWwN/SEk13ji+ruu/cZFT3Vh87MCL7grV+tnrCw4xjQffRjQXgElBJZhI9hSH8has72BUTjVldvOuElpLa1KnD5D0fKtm6jZu2XB/bHg== X-Forefront-Antispam-Report: CIP:69.169.224.2;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-2.smtp-out.eu-central-1.amazonses.com;PTR:b224-2.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(32142699015)(61400799027)(48200799018)(376014)(9140799003)(260925021311599003)(260925022911599003)(260925021911599003)(56012099006)(4143699003)(5063699009)(261009223027099003)(261028144727099003)(261102123227099003)(261021121427099003)(261022105027099003)(261026121527099003)(261026140227099003)(10067099003)(55112099003)(16102099003)(22082099003)(18002099003)(5113699003)(4113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: IrUPsbHB5TROubLC7bt+Erg8Ka/257BOSYP9UZl3Q7UR0jQXB2HdzDVL9eXEL944HBOJzpNvJVlX6mfTP48C+NPsbBhDOztoK5pBnUSI9xX5LeuoKCDsnAzymYrBDxWeqj1wefNOhGx/U1IwoFhzwDRBkDeAyKM02ONfcJ1uSrHsB1Xg4njTBruUKTKZsOVDrvvbpQWLegCukhGYtB3vkYzvmGQdCxJ91PLtoxNwckUeqDBdc6gWAxiXlbgE2+dO0/Ro1XGRINKbdilmFWz3lNvOZZVerlvD3bfbOwbQtpUx2U9omMxoEOuHZFPO8rdDG4Fn9IqdrnnuXN+GE9iL2GOskWX3pLb64sZOYiBTQND/LIBhmblzSMfkaab8cNghGdHTWFCpTHlnDmRdMaq9Y/S37ppt5mVDzJnZyL1LsyTPuYLdw0uHuGLMtUQBlJqD X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2026 14:25:57.2176 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c8bc9f30-166e-4de8-6cb4-08df39b6605f X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: CPH1EPF0000051E.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8782 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Medium] vfio/migration: CPR target caches STOP for a device the source l= eft RUNNING -- commit f6418f1061a535eaf9359082700c745eaca13dbc Author: Andrey Drobyshev vfio/migration: don't assume the device is running on CPR incoming This patch changes the CPR target so that vfio_migration_init() caches STOP instead of RUNNING for the device. The VM state handler then updates the cached state to RUNNING or STOP when the target VM starts or stays paused. > diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c > index b142c9f228911..04d0de7cef0ac 100644 > --- a/hw/vfio/migration.c > +++ b/hw/vfio/migration.c [ ... ] > @@ -914,6 +914,14 @@ static void vfio_vmstate_change(void *opaque, bool r= unning, RunState state) > Error *local_err =3D NULL; > int ret; > =20 > + /* CPR target only: the device kept its state, note where the VM lef= t it */ > + if (cpr_is_incoming()) { > + vbasedev->migration->device_state =3D running ? > + VFIO_DEVICE_STATE_RUNNING : VFIO_DEVICE_STATE_STOP; > + return; > + } > + > + /* CPR source only: the device keeps running across the exec */ > if (cpr_is_in_progress()) { > return; > } [ ... ] > @@ -1039,7 +1047,9 @@ static int vfio_migration_init(VFIODevice *vbasedev) > vbasedev->migration =3D g_new0(VFIOMigration, 1); > migration =3D vbasedev->migration; > migration->vbasedev =3D vbasedev; > - migration->device_state =3D VFIO_DEVICE_STATE_RUNNING; > + /* A device inherited across CPR is in STOP unless the VM gets start= ed */ > + migration->device_state =3D cpr_is_incoming() ? VFIO_DEVICE_STATE_ST= OP : > + VFIO_DEVICE_STATE_RUNN= ING; [Severity: Medium] Can this cache a wrong state when the CPR source VM was running? On the source, migration_stop_vm() calls vm_stop_force_state(RUN_STATE_FINISH_MIGRATE). Since cpr_is_in_progress() is true, both vfio_vmstate_change() and vfio_vmstate_change_prepare() return early, so the device stays RUNNING in the kernel. On the target, vfio_migration_init() runs while cpr_is_incoming() is true and caches STOP unconditionally. The cache is corrected only if vfio_vmstate_change() runs. That requires vm_start() to be called while the incoming mode is still set. In process_incoming_migration_bh() the paused path does not run VM change-state handlers: migration/migration.c:process_incoming_migration_bh() { ... } else { runstate_set(RUN_STATE_PAUSED); } ... } This path is taken with -S, with autostart off, or when migration_block_activate() fails. In those cases the new branch in vfio_vmstate_change() never runs. The cache stays STOP while the device is RUNNING in the kernel. Once migration_incoming_state_destroy() clears the incoming mode, later transitions rely on that cache. In vfio_migration_set_state(): if (new_state =3D=3D migration->device_state) { return 0; } Could a later request for STOP be skipped here, leaving a running device that is believed to be stopped? The cached value is also read by vfio_device_state_is_running() and by the switch in vfio_save_setup(). The commit message says the device is cached as "STOP if it stays paused" and that "At CPR the device can only be in one of the two." Is that accurate for a source that was running? The patch infers the device state from the target's run state, not from the source's run state. Would it be possible to carry the real device state from the source, or to query it, instead of inferring it from the target's run state? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261103-vfio= _v1-v7-0-4467fdccbbe6@virtuozzo.com?part=3D27