From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a121473f63-bc9d7461-1290-40c0-9c89-2fdba9c59ffb-000000@eu-central-1.amazonses.com> Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazon11023074.outbound.protection.outlook.com [40.107.159.74]) by lore.virtuozzo.com (Postfix) with ESMTPS id 526A5802A5 for ; Fri, 9 Oct 2026 15:28:05 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=G+yVDbz2gklMtMTJBRaQKy+7bkW7rkhGt4QZl2IGatMEzn3tQXpRHj/WCz6BpQK9o7fwukp2Ozxxy9uCzDjguftqyJaFrrTzpLWn/7Z3us36yEanvdJjP/5rKKWpMq75M74bABZrT9eT7ZJpmKBjpsQVZit/Ni26i+VWMLobgy6jjil889lxn7qZaLIr6JjqkSmiN7eGxz8F+OVYLveC/sfLfr9InHc6/HG8AC54NFkEvrHFY8iBGGZGYM5cQVhNjqV3lVSfl1yMyldskZd6MdqHI0j9fDWNpQqcqEgtXZwmOpxb1dpVY2yT6DPBiufnem2CCf43iiof6i+CCO1VDw== 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=Ul6To06kh3q3RoxPxKE006yosAp5gOQDhbaOWb63p1g=; b=O6iT23VfQbTsLhty0ODUz2Sg0gkKcJM4K+2GxMWR6qyJ4dwv9KlgZ0KcyXn9WX+nbuXBkK6V6nJwNeHjF91K4qSE6OTtFkIklO2CQsuftOQSe7nHYMfXo93GOTRZLHdL/+FXgGqkRl+ipCBe1K8Uv1b4CQG1+FNebSK712GxyAi0TS91+v8ktAJy4hQWdtlyzqa4xCR+KbsDUm2UHwq+SY54GuAfTPIZO28CJgo855ll5OZMeENJjYNPcuyxDd3fk9SGgDiAXCH5Qpwj6erKI8KuNrn2SlYEzno+9O850VLamz+zRFk/OK8wWqwxst9nU8Ys9OtGnyeedpfzwx7aWA== 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=Ul6To06kh3q3RoxPxKE006yosAp5gOQDhbaOWb63p1g=; b=mQdnSbSh0RaG8CpR3BQLbO03O/srrVHonB8f9uExnwlzHZNXwzqgH+NrcIImel/DG8Z2/xM6HkcN5VxqCzkIBJoOlOJOhpp4JWfvhQWQZAzCAjRi13RJdropCff38peIWIu/2UJw4m62x+iisxxIuWjik81ePsTk/BW6Lu4blPo= Received: from DU2PR04CA0266.eurprd04.prod.outlook.com (2603:10a6:10:28e::31) by PAWPR08MB11438.eurprd08.prod.outlook.com (2603:10a6:102:50b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6; Fri, 9 Oct 2026 15:28:00 +0000 Received: from MAD0EPF000008B7.eurprd04.prod.outlook.com (2603:10a6:10:28e:cafe::7c) by DU2PR04CA0266.outlook.office365.com (2603:10a6:10:28e::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Fri, 9 Oct 2026 15:28:00 +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 MAD0EPF000008B7.mail.protection.outlook.com (10.167.241.139) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Fri, 9 Oct 2026 15:28:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791559679; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=T/LCMD0arr8pXiq+UzBvoO73H+/qq22AxaC7wJGZp+0=; b=eDxLENS6gAZOIvQhqm7e6k5LhIMGKrLrQz3L8jvj2Ev4zC02oiKj2zRFGtYuHi48 jpdFB66kv00v2stdykVxbmTRuUpina0vuoFea5Dk0bNMH98xyhJW7IzeRBnznmoiPDd qcMpwlGMM+M8rYI1GEI40I5UPqU2xzeEwG9/nkJ8xdGNqHFO3U52mIBGBcSgkyNGI/X u1fXMB0Z2be6rBNnXTiN1tyrF0KOK4AjYiAqAheR7XJtzda9soYCb0tJqTNaWywfANO 1Fv9wAnjZV5g97xbf6Vj0zlWmuolAcUKxjib+eJz54WXRIRFxHSq3sbBznAYxthxqZR c1t1KQbxlw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791559679; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=T/LCMD0arr8pXiq+UzBvoO73H+/qq22AxaC7wJGZp+0=; b=BZmmfRjPblw5S00EO9kabeLeueSckhdargWep/U2tZa4ifA+N7YxfQ/MD86UFcm3 6ejjl1nqDqrXPEDCSZo4B6FyCryrA6lG0r/kAy8A632L7kzlZVVDIvfdzacZdLhn041 OPDGWThHHtjj4pbNa2t9URDOK9rRisVpWPQ0Uq8Q= Message-ID: <010701a121473f63-bc9d7461-1290-40c0-9c89-2fdba9c59ffb-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 17/21] vfio/listener: skip dirty page tracking during CPR To: Andrey Drobyshev , svt-core@virtuozzo.com In-Reply-To: <20261009-vfio_v1-v1-17-2ae91d5b8048@virtuozzo.com> References: <20261009-vfio_v1-v1-0-2ae91d5b8048@virtuozzo.com> <20261009-vfio_v1-v1-17-2ae91d5b8048@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Oct 2026 15:27:59 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.09-69.169.224.5 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MAD0EPF000008B7:EE_|PAWPR08MB11438:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 54a0defc-112f-418b-2d2c-08df2619e72d 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|704161211799003|48200799018|376014|32142699015|9140799003|61400799027|10067099003|5113699003|4113699003|3023799007|13003099007|22082099003|55112099003|18002099003|16102099003|4143699003|5063699009|56012099006|5023799004; X-Microsoft-Antispam-Message-Info: +uDCas+LEI8jSzHqZir0NFyVjYrEujxKCKIm880sVetXhIO3KRv5+rNFHOAHcmKzs3VzhrUa7fu0YZ67ey4fmvB4fOnh6jlX+50ZG3JLoF1q/Sfb5bM1YeZB6Yq0ux/bTZrTsNPJBM8DuvvGtok5XSJecK3L3HSguqTLHAUNyHlT7BBTKnVHUaShQsdSVRQK0CQFL8GrpCoxt2kIEHeeeZUxMOnIMgQpNz2ILLcAQVnitOHrsBQ6irPivaMC9gPyCpEZdh9PxPZ77IYTVHJrIVeuatxDEyfDx1lpfJYQOW4Tml9iQm6vmwGcSlIlmqqNBZXdVaGdUCSIfWUHnYCQiGzgqKzNmBEWnzw6q+/psZcCUfUfPt3LaYpdcPn/EzBBZBwGzUXfY/BuJIEDWwo8xu9hvruTls5cj63WfYQWY1ZUiAe80L97E2OfSB8xLla1ACFMQJJ3Wks9TpA3yEbKIgpwf8TNqU9e363l0agrcNRMxWpAK1S6QVPDax3HpHhWQykBQ67+TT6QQqo+kwoSRysEByu/s4WdXJDvqbqh2+8szPFqH7dOXUa2lLMtEPD1zKzAnIqnztzhge0X0YQs4POB0ZdMkxoCntaMULjVRE6/cQ/VISdQPza4f7awIJqTm103utU5QgGOKoSBguT/qzR0phJgd5VObUnYcaH/wEm4u29bkPxx8OpwG66jolpm8uFTvq4RHkjpKe/AP9CLHqDQv64XT7zQyW7PahLDQE9cpb9MMG6n+5f6DsFhGR8KUieUwhf9eAtduVTqLiuDASNOlpXKfn7OQXE2L8+AVxVBOOxZ19moVvB5h7+sCS6ifa/gvFa/18DrxHXf4rz5gBwhHrOSRjdWJKROTVxgIR68dj48xhzJN237/T2DzdaOLTwqoG12CPcZSL70SId9VA== 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)(704161211799003)(48200799018)(376014)(32142699015)(9140799003)(61400799027)(10067099003)(5113699003)(4113699003)(3023799007)(13003099007)(22082099003)(55112099003)(18002099003)(16102099003)(4143699003)(5063699009)(56012099006)(5023799004);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ViWULuw6ne0FvnO+Q+oETN9HGgF68Md+0ft1V/y6/oUUkKs2Hka1MLXCgcMBApAeXTe3udESpTg0XWPNfAkHCzyaI6bIoduhWrwgrj0oQIjc4l2R4CWFD3Nvm7fIrfkCr/kzOV+Rsb4LNayErKpMZtbO0E0nauSQNjN3m76juiTBrPN9uIOsFXKio7rBYLvLu1WuWtTGIccUqrHETtYusOMDiNzieFNG75EWCl21iVEgp6WxSlPw6lQtLaCAs7l+JBwG1ZpsVgFgiADdf6eJqWYIpInddnajeidndgLPWhOo2c3CU61BGbi6XnTgkRb4dnRx6m3Ge9yqf5Qly43NEIZcealc3pgNfjS311paiPqQd8v0mTS/iSmRi292XGvDXAXJYyFvC3mpMqk0oRXQqBPYzBAXwlzb1rzZCyAtvpQVkFrOhie3mcCoeJMFM576 X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 15:28:00.3414 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 54a0defc-112f-418b-2d2c-08df2619e72d X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008B7.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB11438 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] vfio: log_global_stop() gated on live migrate_mode(), can leak d= irty tracking - [Low] vfio: log_global_start/stop skip tracking by configured mode, not b= y CPR migration -- commit 6ce52b002b526df0523d3f2c394521c467727df4 Author: Andrey Drobyshev vfio/listener: skip dirty page tracking during CPR This patch makes vfio_listener_log_global_start() and vfio_listener_log_global_stop() return early when cpr_incoming_needed() is true. The goal is to avoid starting or stopping VFIO dirty tracking in the cpr-transfer and cpr-exec modes, where guest RAM is preserved in place. > diff --git a/hw/vfio/listener.c b/hw/vfio/listener.c > --- 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_incoming_needed(NULL)) { > + return true; > + } > + [Severity: Low] Is the cpr_incoming_needed(NULL) check the right condition here? cpr_incoming_needed() returns true whenever migrate_mode() is MIG_MODE_CPR_TRANSFER or MIG_MODE_CPR_EXEC. migrate_mode() falls back to the persistent parameter when no incoming mode is set: migration/options.c:migrate_mode() { MigMode mode =3D cpr_get_incoming_mode(); if (mode =3D=3D MIG_MODE_NONE) { mode =3D migrate_get_current()->parameters.mode; } ... } So the check is true whenever a CPR mode is merely configured through migrate-set-parameters, whether or not a CPR migration is running. The listener callbacks also run for the other global dirty-log clients. One example is calc-dirty-rate, and dirty-limit reaches them through global_dirty_log_change() in migration/dirtyrate.c: ret =3D memory_global_dirty_log_start(flag, &local_err); With a CPR mode configured, those clients no longer start VFIO container or device dirty tracking. Because vfio_log_sync_needed() requires vfio_container_dirty_tracking_is_started(), log_sync is skipped too. Can the dirty-rate and dirty-limit results then undercount writes made by VFIO devices? Would a check tied to a running CPR migration, or to the GLOBAL_DIRTY_MIGRATION flag, be more precise? The commit message says "during CPR" but does not mention this wider scope. Also, cpr_incoming_needed() is the incoming-side VMState predicate, and here it is reused for a source-side decision. That is not obvious to a reader. > @@ -1031,6 +1037,10 @@ static void vfio_listener_log_global_stop(MemoryLi= stener *listener) > Error *local_err =3D NULL; > int ret =3D 0; > =20 > + if (cpr_incoming_needed(NULL)) { > + return; > + } > + [Severity: Medium] Can this early return leave VFIO dirty tracking running? The stop is skipped based on the current migration mode, not on whether tracking was actually started. Consider this sequence: memory_global_dirty_log_start() vfio_listener_log_global_start() /* mode is normal, tracking starts */ qmp migrate-set-parameters mode=3Dcpr-transfer (or cpr-exec) migrate_params_apply() s->parameters.mode =3D params->mode; /* no check for active tracking = */ memory_global_dirty_log_do_stop() vfio_listener_log_global_stop() cpr_incoming_needed(NULL) /* now true */ return; Neither vfio_devices_dma_logging_stop() nor vfio_container_set_dirty_page_tracking(bcontainer, false, ...) runs. vbasedev->dirty_tracking and the container dirty_pages_started state stay set, and DMA logging stays enabled on the device. That is the vGPU situation the commit message wants to avoid. The window can be wide. memory_global_dirty_log_stop() postpones the stop when the VM is not running: if (!runstate_is_running()) { /* Postpone the dirty log stop, e.g., to when VM starts again */ so the mode can also change during that gap. The reverse case (start skipped under CPR, stop run under a normal mode) looks harmless, since vfio_devices_dma_logging_stop() checks vbasedev->dirty_tracking and vfio_container_set_dirty_page_tracking() returns early when the state already matches. Could the cpr_incoming_needed() check be dropped from vfio_listener_log_global_stop(), given that the stop helpers are idempotent? Alternatively, could start record whether tracking was actually started, with stop testing that state? I did not find changes to hw/vfio/listener.c, migration/options.c, system/memory.c or migration/cpr.c later in the series that address this. --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261009-vfio= _v1-v1-0-2ae91d5b8048@virtuozzo.com?part=3D17