From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazon11021138.outbound.protection.outlook.com [52.101.65.138]) by lore.virtuozzo.com (Postfix) with ESMTPS id EA45680726 for ; Tue, 20 Oct 2026 16:59:07 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dL6qmLS1K92LCKhfn05HoLJTJE4okEA8x4+Co56J5icmOiMVQajrwt+48LWwuyMNIjBlk9Vbjb5jkVRjkPBPGmt/zhIzJouWmcPIxOCBb2Uh99EztY6kDXOudMMwGYASvCMq9UfoEpVGZyeAgRZ+VIUkOkqY5mhqhpb0RzHHOKriRfensnXVcz1+Qh69WlmH2pX958JKsg30UChg6XC0DJ8IvrsaFxXMvvnJggRoh2+X1ShAgGHpXD0U9cGFoskeIyfjIsExFJZ+KWmhpeWFTJaz0e0Bq0G/M2B4YaLadwhjLYhBFufT7r13joDMBjxQK/0/HMBcEkfqwpNUrcUCMQ== 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=EoroluifKnt3BgEXmdONAHSMXOpwssrUhE3qMDNrvzs=; b=ptM84/XFO2s7yFnU8QF56H8SC/JkbGb+rDTwaJrUmr4qqPLOYQh+ktP14aCMPgLOcEy6Fi2SsHCweCL45a29tQlsHMewoaRKfhHThQH+zvdRM23c8zjgH4lxv+yUDjnXk+k/zGZUsve1HT45aZvqOHNaXPgJmDkNH5IMlNTA3j7hk8pPd7dxSD0ms01iTPRpE6+iYonGyrB+Q1n6LkcuXWl+Ef9wX4aQxQLneslTEyvMeTTk+tJYWad3ZnV3MyC7ukLpTEt1PwnmSGuS5ey83kHsQeT4NPNNbqz8BcuuHlRc9m/j0MxNRbsd4crgG9aWwlLBMczULCEcioywHoAvCg== 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=EoroluifKnt3BgEXmdONAHSMXOpwssrUhE3qMDNrvzs=; b=I82cwwJpmWmRkyG62sWHlQ5OIeSFMz/8chV6VYpcXCGnOoY1KtPhav765b2Gc5YzFhzeKPwOi8HdSxsUkc6g+goNjrU1EUmnI0QByveDpRQhk/UMjFlXpgNe86bVuVLXYTMKfLkT017rzR0FxPQ5sATusFpjtBvDiLRYNoB8RBI= Received: from MA3P292CA0033.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:46::11) by PA3PPF8A914B0EB.eurprd08.prod.outlook.com (2603:10a6:108:1::12d) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Tue, 20 Oct 2026 16:59:04 +0000 Received: from MAD0EPF000008AB.eurprd04.prod.outlook.com (2603:10a6:250:46:cafe::a9) by MA3P292CA0033.outlook.office365.com (2603:10a6:250:46::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.20 via Frontend Transport; Tue, 20 Oct 2026 16:59:04 +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 MAD0EPF000008AB.mail.protection.outlook.com (10.167.241.183) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Tue, 20 Oct 2026 16:59:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1792515543; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=xn0ahTmbeUkUULp1djDfuTIJ85j1YPoIUJmKK6V/JiI=; b=MhHKNUS5vbDEhpyWJsC7B38gRErsoty+yayYG0I60BgHCzYp8dG9aHn+jD2zYTX7 7Er0CaT2AfS63LYCf0WC+5JOAxLKZ+sHioFMCPFvcI6fq375NQCLA9yWzqwBdrd/49Q nEKFwWcaHsIhOr4+fzu5rsGMtdGwPIIX1/LE7JMd3p65lAOgz/c+r6EWs06X2iMFcWT vDWQQ9aKQhFCLLqNxmZ2VonRoxExbqWPBQqpRzaLxpU3b0EX6YklubiJY9Vk5LID32m 5FUYGy+bnHqQpInldsXB9UbzUi/zI7LQ4FpEg0SYbo8LDelfQBhyK7UQpnGU5XMfIkk LQ/vRcs6/g== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1792515543; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=xn0ahTmbeUkUULp1djDfuTIJ85j1YPoIUJmKK6V/JiI=; b=DZMcCPpHO/A3SKw2ndJcnvU3rNuqn7cGdbC/tvCu6KEcH2LQrnOS0EmwJGyrJ27b CSy5BkDb3ve1AfuLMtq0+j/gp6SBHJtaaVGwHn5qJdR0uS8kIEhfVTEp+LXXQkPEkJ9 u/H+qV173dZ984PUuiyinsI/5lugL/mFP68cP8R4= Message-ID: <010701a15a40916f-2d756fd2-63ca-4304-beba-7eec7ff8b145-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v4 24/31] vfio/listener: skip dirty page tracking during CPR To: Andrey Drobyshev , svt-core@virtuozzo.com In-Reply-To: <20261020-vfio_v1-v4-24-83a5668230e5@virtuozzo.com> References: <20261020-vfio_v1-v4-0-83a5668230e5@virtuozzo.com> <20261020-vfio_v1-v4-24-83a5668230e5@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2026 16:59:03 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.20-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MAD0EPF000008AB:EE_|PA3PPF8A914B0EB:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 45436c55-812e-494a-b879-08df2ecb7241 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|48200799018|376014|32142699015|61400799027|9140799003|56012099006|5063699009|4143699003|5023799004|261009223027099003|10067099003|18002099003|22082099003|16102099003|55112099003|5113699003|4113699003|13003099007; X-Microsoft-Antispam-Message-Info: cwXQ1Le4/VMft5B+DWIsFufqzKpVIIpjnGfyK9+ISCvkd/gT1Cc3c0QdxOJtrjNsO9W3WY8yBnRHkQ0fjzUF/stD5hKiCszdR09MN4YPjPS9z6C4tSsS1ENC5KM5drKaVpcNW+IaRWCUSjx3vjpP+1K87/yQTPliitMty8ZNB74YE0eH6rzvsbB2MSviD+mID6cO3l9b69edFnucgpbPW/vtEgQNdPjQ54EtZO07BLd8KxpfAuEX3dam/JAHh1ZoBd+gfB8Euce96OArL5RxwzFiyzgY3P22wOO21ku/o8FQHexp5vgD9xnD1VauxcUxAV82y9syWAExrZ9GOAiftQ0+tXX9cJQ0kCS0hgWY3A2o/WWCNZDVnApNuQsp4+ahID8goKM9CcAq2NJBNL7CNqGfodzrJUFIm+vqZ2iQzXj69RCku3YZS2vNiAmyowHHnD1vbb/ywOJMaytIecnJPqIDqGgW+DB01gj11jWhCucOKEEiBIzPr2kV2IU3gNWmxhyVdZ/yiplqBMZem5l9QSJPuEszyWcPyG9nJanQjDH0LroB4wBtUutFYHME5pPp5Op4DZ/lrubvYkQTXwgEqDtQ3rJAxj5zwCkiYf4mRbIEqTL3ikGeFDjl7rud3qLeKHetYlfdb54Qlfc0zIwQ6xBWkeW16UoSxDavCOs2eY1PSbu372yTlQQf+xkhOVusZSlDc8jIkmW2+8v9ZE7eeLGfN/WXvw7q5eOgynmh2ZscFUmXeX1gVuttPZ3vewG6ONn8SJwYpl2CPJd/4SyQbi0N9FxMa+h13UBTBAjsEztEIINYMlG7ibIujVIrHQ557S6R+Jf2orCGK8FnigPpkaLAj+ARXRlg9A/6E5CWF2A= 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)(48200799018)(376014)(32142699015)(61400799027)(9140799003)(56012099006)(5063699009)(4143699003)(5023799004)(261009223027099003)(10067099003)(18002099003)(22082099003)(16102099003)(55112099003)(5113699003)(4113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: /kzSkcwnSnOiC4y9f8fOjD0gjdnNrLx/98WfvxSNGgbWSTCiisTFWV6cLyfTjdsjNOH85DpOymzd2RMgyM0iLmVABsiR2UbzSXpCl1Z5slmuBAPN1yYn5ZF3X5x31d9yc6Ic/6bs42VHHMeBujgTZzdiZUTgNBjBhalBS0qEiMHEgyMt16TSj185MPDXwkh4+yuE1OHzcWKd33b6SB6wudJaQ6idbKktijCNngQKhE5VfONRqeL949ChsdxfW98oJbPXRxOHEGYt0NGOpYaWnvZMBux+8Ns3IPuM3g/P2dllO5BUgZquzrmHKU6N0QN38YaVENVgUnDuaShFBHzEdh16dGKsQ/hd0MIMeIzW0wtEF/eQE6opI3HDogd+3omsqKFgMN7/B2JmZiqeqH+krLEIQzeTCYyS0cl4JZlIVZyDs6xZ82JlxBmZnKVuyr9x X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 16:59:03.9110 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 45436c55-812e-494a-b879-08df2ecb7241 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008AB.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA3PPF8A914B0EB Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] vfio/listener: CPR gate in log_global_start() is already false f= or cpr-transfer - [Medium] vfio: skipping log_global_start during CPR leaves VFIO tracking = off while global flag stays set -- commit d3cf7e64855bb765e2ec55a6878e79a36d8d4b81 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 tracking while cpr_is_in_progress() is true. The goal is to avoid starting container or device (DMA logging) dirty tracking during cpr-transfer and cpr-exec migrations. Stopping stays 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 check effective for cpr-transfer on the source? On the source, cpr_is_in_progress() ends with: migration/cpr.c:cpr_is_in_progress() { ... return cpr_state_file !=3D NULL; } For cpr-transfer, qmp_migrate_finish_cb() closes the state file right after starting the outgoing connection: migration/migration.c:qmp_migrate_finish_cb() { ... qmp_migrate_finish(addr, NULL); cpr_state_close(); } The dirty log is started later, from the migration thread, which takes the BQL for setup: migration_thread() bql_lock(); ret =3D qemu_savevm_state_setup(s->to_dst_file, &local_err); ... ram_init_bitmaps() memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION, errp) vfio_listener_log_global_start() Since the migration thread cannot take the BQL until the main loop callback has returned, cpr_state_file already appears to be NULL by the time vfio_listener_log_global_start() runs. cpr_is_incoming() is false on the source, so cpr_is_in_progress() would return false and dirty tracking would still be started. The comment in cpr_is_in_progress() describes the window as "from cpr_state_save() to cpr_state_close()", which does not appear to cover migration thread setup for cpr-transfer. The commit message says the patch covers both cpr-transfer and cpr-exec, but the cpr-exec case seems to be the only one where the state file stays open until migration_cleanup(). Could the gate use a predicate that remains true through setup for cpr-transfer as well? I did not find a later change in the series that alters cpr_is_in_progress(), the placement of cpr_state_close(), or this listener. [Severity: Medium] Does returning true here leave VFIO tracking off while the global dirty tracking flag stays set? memory_global_dirty_log_start() only calls the listeners when the first flag is set: 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)) { ... } Consider this sequence: 1. A CPR migration is the first dirty log user. vfio_listener_log_global_start() returns early, so VFIO tracking is not started. 2. calc-dirty-rate calls memory_global_dirty_log_start() with GLOBAL_DIRTY_DIRTY_RATE. old_flags is non-zero, so no listener is called. 3. The CPR migration fails or is cancelled and drops its flag. global_dirty_tracking stays non-zero, so memory_global_dirty_log_do_stop= () does not call log_global_stop. 4. A normal migration then starts while calc-dirty-rate is still active. old_flags is non-zero, so the VFIO start hook is not called. In that state vfio_log_sync_needed() returns false: hw/vfio/listener.c:vfio_log_sync_needed() { ... if (!vfio_container_dirty_tracking_is_started(bcontainer)) { return false; } ... } so DMA writes by VFIO devices would not be reported to later dirty log users, including a subsequent live migration. The commit message acknowledges this ("Known gap ... VFIO tracking stays off until QEMU restarts"), and I did not find a later patch in the series that addresses it. Would it be possible to make the decision in the migration layer, or with a per-listener opt-out, so that the global flag and the VFIO device state stay consistent? > if (vfio_container_devices_dirty_tracking_is_supported(bcontainer)) { > ret =3D vfio_devices_dma_logging_start(bcontainer, errp); > } else { --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261020-vfio= _v1-v4-0-83a5668230e5@virtuozzo.com?part=3D24