From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a1a1d60f30-c13cf530-2cf8-41d3-bba0-3eb7b814ab0e-000000@eu-central-1.amazonses.com> Received: from AS8PR04CU009.outbound.protection.outlook.com (mail-westeuropeazon11021074.outbound.protection.outlook.com [52.101.70.74]) by lore.virtuozzo.com (Postfix) with ESMTPS id 4A771810EB for ; Tue, 3 Nov 2026 14:35:31 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NeyMmSWDCKeWhJ5u6+1ZKIZKlCmMMPXA1bNeOKX0+66It2O+QMzwG8zpJ2g+x7usQCeSQaQYczOjycA8haLJZDgInFzGOz3TNGJL211NOn67Pefs6CgNTxj0ITIkshErriI0p5HkibjpVD1Hkcr/qD45jljPBb01+15dtJ/OXb9kcTuJmoYkbJR3cdNvKqDjb6IZKQcIi/4HszXmkA31sn78UeITRLXsazmgfaP4+Hf1zZj6JXHQucYij3Dnru8Uv9QoUjzuekqsH//rTrcP5D9y8PzY/SMF3BwC40x95pAvOcKE5K8R6jnLBEv310Tz1Mb+W4HQWpUTpTZKQJzlbA== 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=1wdYgDG5WNKlxZZancCQhNzwfnrlzMOQIl3C5N0KApM=; b=QoeihlDSa0cBXxWQ+4shcbqpvSxK7EEYVZAqEz7gj3Vxt6WO96ttJVueHLis/W4f4d2m7IME1vu/BOnIfXijGqNQZ8gxKdNjEOy1hoYiEPWT+q8a75+Ay7xTW9GlfToKNT/BkuQMEJmD+1UcHOVX3oOuHZ2wileW6uN1vXdxhV2/TGgZXuIlUbFDROQ/Bux1Kpfa0SsLnw+tR5rK/UVmbLP3j4nWEhjzpkkLONWQv2ToLLXr9SitSDOFUbPCCJrxlBL5Wp/YqIzaLW2VadsZQ+5Hx9jBg3uusOtzHHb1J089whiboeny4GXC/B8DN3dmw5VVcKhC+eVmScLhyUf0GQ== 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=1wdYgDG5WNKlxZZancCQhNzwfnrlzMOQIl3C5N0KApM=; b=ikNccIWFixJxri/ldPgG744l1smBmd1Q+hOvY72UbUmzHmf2SaQCkCICcimNJAb7b5WH+t7Xaab9wN+z+QRD6yEL0UMXo2lsT5LYfsYDOIAq7azxvHuBfvcbUbYhK96ClNkdnXZPa1e075kRzTs48Z2Y3QkN3RCClKxsh8Kdn0U= Received: from VI1PR06CA0176.eurprd06.prod.outlook.com (2603:10a6:803:c8::33) by DB3PR08MB8889.eurprd08.prod.outlook.com (2603:10a6:10:439::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.9; Tue, 3 Nov 2026 14:35:23 +0000 Received: from MI3PEPF00008482.eurprd02.prod.outlook.com (2603:10a6:803:c8:cafe::9e) by VI1PR06CA0176.outlook.office365.com (2603:10a6:803:c8::33) 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:35:23 +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 MI3PEPF00008482.mail.protection.outlook.com (10.167.240.169) 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:35:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793716522; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=pOSKyAChylafoFEVoO1WkaMPW69eK0iWYcRptcMqE9I=; b=doJQ4rbOSs06AvOlmZHxk0tCYrRp1ugSHsVTsaITxUxwfrvBhPPe1Yugwt5ylCOu MBB/C7OhteHkw1ElKLBQsmuEdRIm14C8NftbYBY6Jq+LBDnIn0TrjZ7plOYg8bQQ9gy Xl8EliAS8sy8KCHn1CN4OParTmTa9Ay+HcrNq1wycBkTuJ9Y84rvlSY38tBRBGNPWML 5aWK1HmwzcXmOJHI/5i7kCa9YyOQBSiJolVKsj4dU8vHrqzQn1qJ+ewoXqsWWgVJuax 3Ts9n7TLMJVaUZ2AiFZIS3WrE3c5wiiJTXlItOOpTI3cXRroX9a8vuMeWybkV59CtSW hjYa2jGAJQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793716522; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=pOSKyAChylafoFEVoO1WkaMPW69eK0iWYcRptcMqE9I=; b=CS5jKZ8jshHGk9aqAycE+L+GAter6zNBOxBJRp0834vY7IcR5wxkSAKdsiJVTW4J QHVQlOkJaGwviYGUz5/QbCPI5MfuHQI/iwcXZZTCUP3rumnSlsVVeWG7sorj0xbJGbx uv1QMTJfznFCvg6MIpimrG6C+vBPrXKyP+uIeMXA= Message-ID: <010701a1a1d60f30-c13cf530-2cf8-41d3-bba0-3eb7b814ab0e-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v7 35/35] VZ: vfio/migration: don't wait for stop-copy-only device state #VSTOR-141821 To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261103-vfio_v1-v7-35-4467fdccbbe6@virtuozzo.com> References: <20261103-vfio_v1-v7-0-4467fdccbbe6@virtuozzo.com> <20261103-vfio_v1-v7-35-4467fdccbbe6@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2026 14:35:22 +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: MI3PEPF00008482:EE_|DB3PR08MB8889:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c05bf911-5b5a-44d3-23b5-08df39b7b1bb X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-Transport-Rules-Loop: 1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|30052699003|376014|48200799018|61400799027|9140799003|32142699015|10067099003|5063699009|4143699003|5023799004|56012099006|261028144727099003|261009223027099003|261026121527099003|261026140227099003|261021121427099003|261022105027099003|5113699003|16102099003|55112099003|4113699003|261102123227099003|18002099003|22082099003|13003099007; X-Microsoft-Antispam-Message-Info: F9DLPJXWRVqEtzfILn+aJP89f/wHYB5GCMyeHbsu49QNIMuyqDIXp3f+HnPUQKwwlz94sb3Jutj3zs0JCvBfJzsWvUi27tz2E46TwL5dv0NdaujYfok3xAuIHTnwaP8fEDfiyP/q+I+oG5BJGwKgb0+/mTaaITeTpQHRAWEb7etw+1oQAd58PZEiPL47jc34Ugb9G0I2AN3t7vs3IbsqjHXU1xXc/dE8Fcmlz9Jc/9DH1EXt/lcjscxm3kgI5TIWpSMaKi5tHTBlk6blnPsGzHAhD83eUZYe1kuVt63EeJNqP1zp4OHj1egRoBs+aOP87hCJfWNdkUeJqdHtaOog21hBU56u3h2EZh3f3kzGEbbS6Br2nhgF8DNeTlyHnO6qIsWgB//PEV/yN//MMQQ8zgU2qVSoFKpJLlLAhgOrvL9ffYRs+b9KhLTsCTy8k9K1Gy2suHiHAx6cl2lchx7IlxyAHaGrPpaYKFV1em5IyjqUyMB7Amx+s0q9nKYyCg27J6lP07gUTm16S1OCXWlQ0Q6sE+2SVxQRAYeibzp81WIYsryfwp+nzYrnViv12TUYdehklCvPmfjd554RKAspx+TLz7E2fqQW9U98CrzPxOsRPl+xA8YjZhHiJGCXlNtoLYik82mNSR4mAqKuztmSH10yiEGtBsENEmHHfZ4xfdQYocqeYbYEH9+Tw6dojN06HSWUbPpdjW1MzxBSWApPAM4pjPZIkaF2ZGUtsl7J3UkLisdfrc+bFzAB89b0IF/82Z9rjc5geO9XHcujVTKNetkTTcHYYqm+6ua2bcMtwSonPXqH/R48zLh5dujv6g97 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)(30052699003)(376014)(48200799018)(61400799027)(9140799003)(32142699015)(10067099003)(5063699009)(4143699003)(5023799004)(56012099006)(261028144727099003)(261009223027099003)(261026121527099003)(261026140227099003)(261021121427099003)(261022105027099003)(5113699003)(16102099003)(55112099003)(4113699003)(261102123227099003)(18002099003)(22082099003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: rLKAN4TmjNVL5F8fQwxKquGFcHjm73D/n89vW9A7bBMXijdBfp+lp6bkIDE1tLA3IgDXAZPeiBH9dRJVyW9/7HmtvRWI6SFTqpLISOlXcP563yuzai+KtjPKwNmf9BiLlZjdrOpM5/pZl4NgHQpYGWkAgNASIanPQWyemqv5txSSv/8Zd6wu2R2ldHpMBdfBgEAoxWyVRnVEMZNP1Nu16RU2Zp2JUSMYm5rFQuB8CmtCDVIECXfti0mA363je6CWHFFyDnLB5VMEPf1crnTZ15j832LoftghCplQsXTztJYJM+TyVgg8OPL7aZLiImlLQGeNUssuucua+UNKSzt7rvswueU/7Z5JD0rKbb0Dox9bm1qgC6w6Ha8KCVaYynulFBvvZp2APDfpUznXeq0PA71kQOL0/TBq/ankrk47oQc1pwXxSfnWxf3bbiMyZF7J X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2026 14:35:23.2779 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c05bf911-5b5a-44d3-23b5-08df39b7b1bb X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF00008482.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB8889 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] vfio/migration: stop-copy size dropped from pending, so downtime= -limit is bypassed - [Low] vfio: comment in vfio_state_pending_exact() misdescribes error fall= back -- commit 4741edc5da3eca96f6669a6d5a3ce9d95caac4ae Author: Andrey Drobyshev VZ: vfio/migration: don't wait for stop-copy-only device state #VSTOR-141821 This patch changes vfio_state_pending_exact() so that the VFIO stop-copy si= ze is added to *must_precopy only when a query failed or the device still h= as pre-copy data. Devices without pre-copy support, and pre-copy devices th= at have drained, no longer have their stop-copy state counted toward the sw= itchover decision. > diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c > --- a/hw/vfio/migration.c > +++ b/hw/vfio/migration.c [ ... ] > @@ -569,16 +569,24 @@ static void vfio_state_pending_exact(void *opaque, = uint64_t *must_precopy, > VFIODevice *vbasedev =3D opaque; > VFIOMigration *migration =3D vbasedev->migration; > uint64_t stop_copy_size =3D VFIO_MIG_STOP_COPY_SIZE; > + int ret; > =20 > /* > - * If getting pending migration size fails, VFIO_MIG_STOP_COPY_SIZE = is > - * reported so downtime limit won't be violated. > + * If getting the pending sizes fails, VFIO_MIG_STOP_COPY_SIZE is > + * reported, unconditionally, so the switchover isn't taken blindly. > */ > - vfio_query_stop_copy_size(vbasedev, &stop_copy_size); > - *must_precopy +=3D stop_copy_size; > + ret =3D vfio_query_stop_copy_size(vbasedev, &stop_copy_size); > =20 > if (vfio_device_state_is_precopy(vbasedev)) { > - vfio_query_precopy_size(migration); > + ret |=3D vfio_query_precopy_size(migration); > + } [Severity: Low] This isn't a bug, but is the new comment accurate? It says that if getting the pending sizes fails, VFIO_MIG_STOP_COPY_SIZE is= reported unconditionally. That only holds when vfio_query_stop_copy_size()= itself fails, because only then does stop_copy_size keep its initial value. If vfio_query_stop_copy_size() succeeds and vfio_query_precopy_size() then = fails, ret is non-zero. The real stop_copy_length value is added to *must_p= recopy, not VFIO_MIG_STOP_COPY_SIZE. vfio_query_precopy_size() also zeroes precopy_init_size and precopy_dirty_s= ize in that case, so the trace event shows 0 for both. Could the comment be= reworded to match this? > + > + /* > + * Once there's nothing left to pre-copy, the stop-copy state can't > + * shrink by iterating: don't let it hold up the switchover. > + */ > + if (ret || migration->precopy_init_size || migration->precopy_dirty_= size) { > + *must_precopy +=3D stop_copy_size; > } [Severity: Medium] Does this gate let the switchover happen while a large stop-copy state stil= l has to be sent with the guest paused? The switchover decision in migration_iteration_run() depends only on the re= ported pending size: complete_ready =3D can_switchover && (pending_size <=3D s->threshold_si= ze); With stop_copy_size left out of *must_precopy, this can become true even wh= en the device state is much larger than bandwidth x downtime-limit. The com= mit message acknowledges that "the downtime limit no longer bounds the time= that state takes to send". Two cases make the gate false: 1) A device without VFIO_MIGRATION_PRE_COPY never reaches vfio_query_precop= y_size(), because vfio_device_state_is_precopy() is false. precopy_init_siz= e and precopy_dirty_size stay 0, so its stop-copy state is never counted, h= owever large it is. vfio_state_pending_estimate() also returns early for su= ch a device: if (!vfio_device_state_is_precopy(vbasedev)) { return; } so no other handler accounts for that state. 2) A pre-copy device whose query returns 0/0 at a single sampling instant i= s treated as drained, although the guest is still running. Can stop_copy_le= ngth grow after that sample? The comment "can't shrink by iterating" says n= othing about whether the size is final once 0/0 is read. There is no per-device or per-driver opt-in here, so every VFIO device is a= ffected, not only the vGPU case described in the commit message. Would it m= ake sense to limit this behaviour to devices known to need it, or to make i= t configurable? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261103-vfio= _v1-v7-0-4467fdccbbe6@virtuozzo.com?part=3D35