From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazon11023120.outbound.protection.outlook.com [40.107.162.120]) by lore.virtuozzo.com (Postfix) with ESMTPS id 55FD080474 for ; Fri, 23 Oct 2026 17:27:29 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hHWl3LtzvMP0gY5zg5x8Wc9gRR80yll7tf7hCTLkU1nY+IQqlcIK9nOo2r5D4NX9pRb7/G0CXNPMwHwAm88zwfFitNHukJjJAecmfMuFRk00AjCo4m24dj4OiCc/VsEWMH8rEwhDTmv/xzKXE2d0FXWwOxE+sN/dbEjqfmfgL+D5nxKuiyx4HMP/1Gw6QKb41emBQi6OkQx1CQZ/wLnYnyi7HkF6HVsbP1s7NWNl5uU8l/Fg3qKFMflUDsJOeTGVV/RZfITDuNLNjlAboB4B5jOegvqexXqTFJk7lFvorSmg2enht8bbUpNq/SASCWZD/67u+99piqmafKxQmoDYzA== 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=dy2fJouVg/y/aIAnJfUfIf5uiR6wBwVM3JsCe2VJSxU=; b=h8ltZTzNZBvW2S9kzLKQvq0G4bRjIDRknPUYzO3NCsLMJRSdheBznw2Iuo4Ws6nIFjYjyzwJmbGrmIeGJcRx7Yc5RPB7yQ0YTZkKKh62CU2LbjLEnTCa7zFqJqozk3TTLbJ63njPL1/cTpGCQZk2vOAf8LJf1fPFXWybtMCJ5amQh0RTlQLxxYnp2NTw398S8GMUfWV+VM1C7rlbO27X4KPicfe38+ETAlD+dYXqvejeXVT2FDPauFJgDoXX7LoGvZy7jxrT6ZneLmuZLixa5BBEGa5DxFaXV88Ay68/dJZnHHoj3OD4ZfmLFImZre8A5G9DiVUt1yKJRUt0Bn7VYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.6) 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=dy2fJouVg/y/aIAnJfUfIf5uiR6wBwVM3JsCe2VJSxU=; b=FrNPQwxdVaQuZM8qJoWpo3pOLcboTFIYtF2qaKp1uOOMXAwkOxSuj3SNWVKvuER4CMezPstCY2ZU0Kl8RhFp/1YJAxp/WPjOOwjzeDyc3mrw8m1Rior2cS+BkicYW2OAmS41zEng90EN9ro99C1cCz9+ao1WjodfauJ7cf072M8= Received: from OS6P279CA0167.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:38::20) by DB9PR08MB8673.eurprd08.prod.outlook.com (2603:10a6:10:3d3::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.18; Fri, 23 Oct 2026 17:27:23 +0000 Received: from CPH1EPF0000051E.eurprd04.prod.outlook.com (2603:10a6:e10:38:cafe::9f) by OS6P279CA0167.outlook.office365.com (2603:10a6:e10:38::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.19 via Frontend Transport; Fri, 23 Oct 2026 17:27:23 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.6) 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.6 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.6; helo=b224-6.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-6.smtp-out.eu-central-1.amazonses.com (69.169.224.6) 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.569.4 via Frontend Transport; Fri, 23 Oct 2026 17:27:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1792776442; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=TMhYTBLk1poh/m8yfUoWM5EGEmlRlyLKml+r0snKzE4=; b=3APTf8E3x6owBy7AnXmn6daXa759dQVNj+I6+BHSV/eCaVRzgMbmP1j5f949Gm3G mmxhWSdLZ+tRomew4e9nd6R49Kg42TCzIfnAtD0Rz8S+RTt28XDAqZFN6VCL3AWV2mS I0MukZA1cBcDewKpOFjJjTvbo42KpzBW1otq/5qFlV3W46Kmf6SK/0MkDy6mCUbrXyH kiXCgqOhA8WS2X8eWZ9Ki+J/sVFOJ18CxScw/oWeZhU0hDs8TvtYzFoVvGvVU2DeHoo J1ZaKwanTqFehgnt/6aU2xqEH9C3w96R4gHjAOkTiZ6BE2F8dIArn6D11ylWzZY3Sdl Iu9Mrvn7VA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1792776442; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=TMhYTBLk1poh/m8yfUoWM5EGEmlRlyLKml+r0snKzE4=; b=QHCjnapccDIdTmQBBIUWOrVig4FcGyvoLk7vr5CGbhYuptVkfoHDL/BJphmZek1U CNDHNxT/mBAH45TC37Qv+8/wN6gg99jqXhbG1kpGEnAP/dCsfTVxupdzR1JnV8frG4t vAu2KiIwyaZXcAldHvqJ7Z4zniIhjPUesvy5voSs= Message-ID: <010701a169cd9312-a8bf7ba8-1f77-4b43-b277-a2a5c576866d-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v5 27/36] vfio/listener: skip dirty page tracking during CPR To: Andrey Drobyshev , svt-core@virtuozzo.com In-Reply-To: <20261023-vfio_v1-v5-27-ba0bf3c6d122@virtuozzo.com> References: <20261023-vfio_v1-v5-0-ba0bf3c6d122@virtuozzo.com> <20261023-vfio_v1-v5-27-ba0bf3c6d122@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2026 17:27:22 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.23-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CPH1EPF0000051E:EE_|DB9PR08MB8673:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 412e6195-46a1-488a-9b58-08df312ae656 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|61400799027|32142699015|9140799003|376014|48200799018|55112099003|6133799003|18002099003|5113699003|4113699003|22082099003|16102099003|13003099007|56012099006|5063699009|4143699003|5023799004|261022075727099003|261009223027099003|261022105027099003|261021121427099003|10067099003; X-Microsoft-Antispam-Message-Info: C8jHEZm6YjIQ4c3ax9MetQ1xyaZQEJ+KO4Jt39lY5jvp628L9ADaWS297gh14GPxi+nbLvxoVvf0wY9uiPGXnLj5xO48mFFXGikUziAvfX1LUs19xbfDpW3HQHfOsHdn21qR5i2+4bJjwexZixYtX2O1g8ME5g61mYfot8WKV46YqCSUGsbbC9VFT/9vCuQpPh69eCVIi+XKgsgKPJT7Y5TNJq1TA8Tv6PcEtfsjK9mUxbSJRpOekgMdiU5zYBToUhTZCDkvM6ycUqWMYHZk9X5NwhdSXs6rv175gkvyG7EXdgkhFOM1b1fZvY1bH2Gq1aDmgTIxRDlnAezYLTBG+pnKkGgmGSd1324J+1DjzNZncrR8QDuG6Ydn5oVS+NEps1sfpPFDYvQrX529x8+Mr46dsA60h8UY0jqJa93JoQ+9smI//cO3gW6XBBvwWYeyfHFt++PAypQlWV/XSFcN+6t/RHE8pAVMGLiqFf/RbpK3E5SiTXeBcS/Z9kdwBSxRaTbzFBujWseM6cugP+q72udopf2j+jN33B5t5UtWcdruSZGW3ZDFzl5geBxiSvcf0VRIDMbPMwCJ3tSDAKLKodAT0qrRxD9bbeYgpLyeeEgfLSyU2ewQzatxVNByzVVPiCaHaUjFVjRyySToysh6fakzxnKwTR7yfsE7oqw64TM8ieQzBbSoV6seQ6QJf9hOBWWXZSWJ4FoecJ3pDgVyiIHZ+xHyNY77J1kr9DM6QVFxpql5RhEjkPCzY19kiEYBMggFtAcFAKfZY0ibedDkFsIJZcyLqKHDSZA1bPe1WmMQWY0ihWbWq8pUjcXY8wmH7Yz/HntNKz3RokBVTKaa9GkIhet11Q8GZOqo1iYU7tRHd9xmJ1DrxjVNbm3+pRCe X-Forefront-Antispam-Report: CIP:69.169.224.6;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-6.smtp-out.eu-central-1.amazonses.com;PTR:b224-6.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(61400799027)(32142699015)(9140799003)(376014)(48200799018)(55112099003)(6133799003)(18002099003)(5113699003)(4113699003)(22082099003)(16102099003)(13003099007)(56012099006)(5063699009)(4143699003)(5023799004)(261022075727099003)(261009223027099003)(261022105027099003)(261021121427099003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: tEudSi1k9uQ30lPzokODvO0CVs5d4Ao2q+GqEvjarVWy4noiOONSdru7CeyfZ125ECBbWIBexBIQq4t3i7dyFnQAvHpgRWaBCXVlBbmehLyHqmoqGJORi+j0ZNlWQTVdjHg1z2npavqKF5SLvreZmCffRCsdfWCokLLXjF44RZiU7IpuHOrhPD675M8SC2XhLcDaepxKevupJh/X0cA3CrQcVZ4AVIPHo1S+Rgn58r07a1Zojz/1HPtra07D3emLrUcrlUZGe5txn3AnrkG7MWcX9ncXC/zzcY9JhpCcUMZUTU9YKNtb5nFOvUGKrj2rQL39DlGBuE8SByS7apFThZg2STIJnmq27aUpqwsOGgI8GZczbsHW+55y/hJaEsKrOGGyMdHWxpg9d81i/gCfrpBeTjUKEevnfbucD9TdBd/o0792T7CCSzbfqpX/FeHz X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 17:27:23.1799 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 412e6195-46a1-488a-9b58-08df312ae656 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: DB9PR08MB8673 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [High] vfio: CPR skip in log_global_start() leaves VFIO dirty tracking of= f if dirty log stays on - [Medium] vfio: CPR dirty-tracking skip is ineffective on the cpr-transfer= source -- commit b54c3b90944a2a7cd1a56e7739cf8ea66b19d6c9 Author: Andrey Drobyshev vfio/listener: skip dirty page tracking during CPR This patch makes vfio_listener_log_global_start() return early without starting VFIO dirty page tracking while cpr_is_in_progress() is true. The aim is to avoid leaving DMA logging running after cpr-transfer or cpr-exec. Stopping tracking is left unconditional. > diff --git a/hw/vfio/listener.c b/hw/vfio/listener.c > index afcf518f567f..1270b9d5f3aa 100644 > --- a/hw/vfio/listener.c > +++ b/hw/vfio/listener.c [ ... ] > @@ -1012,6 +1013,11 @@ static bool vfio_listener_log_global_start(MemoryL= istener *listener, > listener); > bool ret; > =20 > + /* Preserved devices keep DMA-ing into preserved RAM, nothing to tra= ck */ > + if (cpr_is_in_progress()) { > + return true; > + } > + [Severity: Medium] Is this skip effective on the cpr-transfer source? On the source, cpr_is_in_progress() reduces to this check, because cpr_is_incoming() is false there: migration/cpr.c:cpr_is_in_progress() { ... return cpr_state_file !=3D NULL; } For cpr-transfer, qmp_migrate() only arms a HUP watch after cpr_state_save(). When the target closes the CPR socket, the main loop runs qmp_migrate_finish_cb() with the BQL held: migration/migration.c:qmp_migrate_finish_cb() { ... qmp_migrate_finish(addr, NULL); cpr_state_close(); } So cpr_state_file is already NULL by the time the migration thread gets the BQL and runs setup: migration_thread() bql_lock(); ret =3D qemu_savevm_state_setup(s->to_dst_file, &local_err); bql_unlock(); The call chain from there is: qemu_savevm_state_setup() ram_init_bitmaps() memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION, errp) vfio_listener_log_global_start() When that chain reaches the new check, cpr_is_in_progress() returns false. VFIO dirty tracking would then still start on the cpr-transfer source, even though the commit message says it is skipped for cpr-transfer. cpr-exec does not appear to be affected. I did not find a later change in the series that alters the timing of cpr_state_close() or the predicate. Could the check be based on something that is still set when setup runs on the cpr-transfer source? [Severity: High] Can VFIO dirty tracking stay off after a failed CPR when another dirty log user is active? The early return sets neither vbasedev->dirty_tracking nor bcontainer->dirty_pages_started. The memory core calls the listeners only on the transition from no dirty log users to one: system/memory.c:memory_global_dirty_log_start() { old_flags =3D global_dirty_tracking; global_dirty_tracking |=3D flags; ... if (!old_flags) { if (!memory_global_dirty_log_do_start(errp)) { ... } A possible sequence is: 1. A CPR migration starts and global_dirty_tracking goes from 0 to GLOBAL_DIRTY_MIGRATION. vfio_listener_log_global_start() returns early. 2. calc-dirty-rate starts and adds GLOBAL_DIRTY_DIRTY_RATE. 3. The CPR fails or is cancelled. Only the migration flag is cleared, so global_dirty_tracking stays non-zero and log_global_stop is not called. 4. A later live migration calls memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION). old_flags is non-zero, so VFIO log_global_start() is not invoked again. After that, vfio_log_sync_needed() returns false: hw/vfio/listener.c:vfio_log_sync_needed() { ... if (!vfio_container_dirty_tracking_is_started(bcontainer)) { return false; } ... } The VFIO dirty bitmap sync is then skipped without any warning. Could that cause a later live migration to send stale guest RAM for pages dirtied by the device? The commit message acknowledges this as a "Known gap", but I did not find anything in the series that restarts tracking. Would it be possible to restart VFIO tracking when the CPR ends or fails, or to avoid the early return in a way that does not depend on the first-user transition? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261023-vfio= _v1-v5-0-ba0bf3c6d122@virtuozzo.com?part=3D27