From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a1214d3cfa-a9847f13-0214-4f8e-9c66-abec2dacb519-000000@eu-central-1.amazonses.com> Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazon11021075.outbound.protection.outlook.com [52.101.65.75]) by lore.virtuozzo.com (Postfix) with ESMTPS id 243CF8017D for ; Fri, 9 Oct 2026 15:34:41 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Z06SNpAdAzXTavtsi2SMOKnau72WRYgOq3ZudQXGo9I1coxV7xZurwxW997gzsDN/WPcN6BsJs/J/itMfALLjW2v2tG1ZEfLD0phFp//PqdvKmBWGTljAEwz+k3/etpgqiVNDwxRjAfTXUSOT8Nk0brC7++fMU5ptWZMjoVFNdTxton/kXThI+jE44vbIgPqJ0ZvENxfGX9VXM8Eg41fe/xVtJyczjAgg8ABUNAlno7c35fHN8uu9yfthA4D3FXQ2G0oZO6zcTCziDhZa5pu23jkjnoFpj6Pki/1P0uW5IBjkSI6YKDP83v3hS8ziiliLxQpQ5/vl8+1JOyqo9BfJA== 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=hvAgffDH92MXr/lYpNcse10Kd8yN3ejmLDZt57eHcuI=; b=Lbe6q3vx3H9eERPRnOrNco1joSXS4v+2dT8huF+x0oNj1OYQ9KOvx7d1ow3Ri90wCRjPDF0I54gEVkOel8BsigiJZFb5L/aNIWtzClU/c3shOlzQ1HGCHgmdTcs7XcG5B0mduy9GiJH4UpKGe/wDCHEjegQjybv1y+pP3T5Rtqu5JD5cVQe20kDU33TceVqEjk29l0ZmlflV27XmQujsrxmgXS/xvmiIF0v4TW0SwO/Nb7vk9rNEjnae8Tu0LprIOW/WXNF+x7DkB+kSJWB16S5TKXROJeZP4k+oNd6/V+VR22Cl0fL4e6VNU0bVAogh87pOFVfeWikYRCi0Wx5CWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.1) 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=hvAgffDH92MXr/lYpNcse10Kd8yN3ejmLDZt57eHcuI=; b=dubu8OCVWJHbpBmuL1L+wgIeJVKRbfL93rhIXSD8tgQCFCJmukPpeLQNppl4DEarjSbzKOW8f5+qtOUm/071RqVLAJlKglk6YDonprHJiGWk0wnDtunPw7r1k3hfeI/lmHoOSgcjlmhQPogEDLlGThmDAtgGbg0vitNY3J6mMpw= Received: from AM0PR10CA0013.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::23) by AS8PR08MB9906.eurprd08.prod.outlook.com (2603:10a6:20b:564::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.18; Fri, 9 Oct 2026 15:34:33 +0000 Received: from AMS0EPF00000566.eurprd02.prod.outlook.com (2603:10a6:208:17c:cafe::58) by AM0PR10CA0013.outlook.office365.com (2603:10a6:208:17c::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.21 via Frontend Transport; Fri, 9 Oct 2026 15:34:33 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.1) 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.1 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.1; helo=b224-1.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-1.smtp-out.eu-central-1.amazonses.com (69.169.224.1) by AMS0EPF00000566.mail.protection.outlook.com (10.167.242.116) 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:34:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791560072; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=yHL/9GUwNoBjNuz3hRcFRylj1InXl+dIhjhDwfDwal0=; b=26dP9tocrZMLkfnxQ7Nwkdrvo/fcY/+1BwaMhn0sDKkxZV+QZcjDBQNRUFxhnmFY JERwz+umPcdRymUSTHdZWBCwE3ZYH1BrV5OK4g0joE3RApi+TIjCJIoRMLiCeCfxrPq vr0INQiRtxFYkIPdgBXzBLOUvCrsVgHYQsBILayj9E1A8lwROqKGmqmu6Vxdq04tkfl vBwmwPZ6evZPC1yvOAGEbH+dsugHdrJ+4d/BPd/Bdj7XEig3QV5GuwGdee1oPxBOCy8 ieWgB1lsbVY7FLBGLpzqHf13c1QL0RLV2bFzG7Q5JhWoydesHqSbxqwUDwzFg7UBxnQ 4M634v1ZJg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791560072; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=yHL/9GUwNoBjNuz3hRcFRylj1InXl+dIhjhDwfDwal0=; b=VJDj6ZvIshkge9gb+piz6hTgp4/aC0Qe9G0udYUjSOqGEQrHYsTiEznttqutgMaY ad8QON5aF2/CHf3LYpzVsvVbc5KJjQuiT+1HmOsLq5+V1x1WNPUXqbfVz8tL3Z3u5Yu vxR3dn5HHg/SI8Cr4ggzjVb1GrJ9P+AdvJLm50f0= Message-ID: <010701a1214d3cfa-a9847f13-0214-4f8e-9c66-abec2dacb519-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 21/21] VZ: migration/cpr-exec: allow cpr-exec with VFIO devices #VSTOR-103860 To: svt-core@virtuozzo.com, Andrey Drobyshev In-Reply-To: <20261009-vfio_v1-v1-21-2ae91d5b8048@virtuozzo.com> References: <20261009-vfio_v1-v1-0-2ae91d5b8048@virtuozzo.com> <20261009-vfio_v1-v1-21-2ae91d5b8048@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Oct 2026 15:34:32 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.09-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AMS0EPF00000566:EE_|AS8PR08MB9906:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: da4fe832-b6ee-475f-7245-08df261ad12d 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|9140799003|32142699015|61400799027|376014|48200799018|5113699003|4113699003|16102099003|22082099003|10067099003|55112099003|18002099003|13003099007|4143699003|260925022911599003|260925021311599003|260925021911599003|5063699009|5023799004|56012099006; X-Microsoft-Antispam-Message-Info: p6snVqHgFy7IFGKv2G0yqVc2XJmIyeBb5FIVH7togQmSP29n7rNAy9fwHzWpjuIITU5dK01KGZr/6Z8uKVVarToShdgJj1j28TMMQ/AuxkBcPcBOMa/cAnZk8qzC5ssM8kYqdITJ5S8bA+XlziEqU0fT8s1vZPamGwMf+0O/lBrL4xkIS8wkz1068f9uRsYsF67PSH1zPDL2QzM01UVjb8HGt2ews4e7BmuFuVI/968cbVNjRExmyxWTllPnQN4jdDy8WF3Cfh5Tcs5OpU9pGVC1+6oOOt90UdE/9HYhst4V751/RgCC7++bhu8vtSInIrYc17NClmTla8fnLu1z8Z35Y4IGHHMYPO5kH2pSk5Kp8WtYVFVB09sp58qqTcgRp5cR8CS12ceUmFchK4x5Kds/T4FGwoipZRRpRJvt7DIwohoqwCuft+a2YhTkFXEoopOQE1+qLz1Tz/GaWTuANqI88ZQ5gqHumpL9VFuGWNQylpQtBVLb2wYQ4jg+Nd4MZr14tuZAPpLB9IvIpnl6exPZN+bgNvkkOW+NAm5a4/Ouzc7j4OtKMHPpdIqbBxCbjs4CgW70YoaAKjbtqPD6QmO3IYrWZHFe02C2FNh6JxKyY8mjD9GZT4WUnFNlxEHpqKQUkIy7+ybGI54j+dvtXtBpTMZ49xz7asY9bstKQAog0cJ4Ur9sq+ZvcamBe9xGDgZ1k8TrThQuOdxKViexRYGF2v6JM/6vQkLoWH9wcwtB+l9d5gjpm+c3k8lPIw2fxJN/3mwKw5YET52UKRK+Vnocn3Ub5U9TycpqZGOXcGDCfTq8pk5qiE8Wj4z+9jYuVAQZkU1rOdu2JddJ9ez5mMeuK5LgAFWwR394SJYSvHS9e8vKN3hZZ0/WnHVgZPfytLSe0eEwDB57SBfIBD7/ig== X-Forefront-Antispam-Report: CIP:69.169.224.1;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-1.smtp-out.eu-central-1.amazonses.com;PTR:b224-1.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(9140799003)(32142699015)(61400799027)(376014)(48200799018)(5113699003)(4113699003)(16102099003)(22082099003)(10067099003)(55112099003)(18002099003)(13003099007)(4143699003)(260925022911599003)(260925021311599003)(260925021911599003)(5063699009)(5023799004)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Y2FbuOOXURVXvev2nyNFHKG4VzfZheGSp9M4wMdL7WwNQ9mD7qCPVTdit+KDnqeGdGO9TSjLeFmAN+oJrbBtuu4XdL/Yo+s25wVM49fIdqIerzmiKEy11dE9BR2jFV/zEACwDYXBOxvbr+bEjhtLnHfjMms44ntoU7IxMpl59yp6Y7D2+TbCXGKTTD8y3QqmpnHM0EkvUr8b6iamVFDbVPMUxT10/kSoylpZanx7N0VhwMhRrQ+EEF4VDMGkD2BsfTOeCuanDh9Uw7d3HgN+Fu5Y1XKboTuCKTXVHqKZEw4pXYK4p3GCJF22qPRSg42zVJALun6W1BHnu6lcVTItFNRch+hKWpBUCXN59Z9dl1PbhEsZo2t33k0JD8oTJZB/M23POir5Y3hDr+m3iJyP3pZZQGwxTilSsKYj29e2mZzhIdPUH3qAZl+QaMdjdZGx X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 15:34:32.9344 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: da4fe832-b6ee-475f-7245-08df261ad12d X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: AMS0EPF00000566.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9906 Thank you for your contribution! Sashiko AI review found 4 potential issue(= s) to consider: - [Medium] migration: cpr-exec VFIO blocker removed with no check that RAM = is shared/memfd-backed - [Medium] vfio: removing vfio_devices_present() leaves vfio-user devices u= nblocked for cpr-exec - [Low] migration: cpr-exec with VFIO has no up-front check for MADV_DOEXEC= support - [Low] migration: stale hw/vfio/vfio-device.h include left in migration.c -- commit 3953515702dee287eb17eba476062c856bd30dd8 Author: Andrey Drobyshev VZ: migration/cpr-exec: allow cpr-exec with VFIO devices #VSTOR-103860 This patch removes the check in migrate_cpr_is_blocked() that rejected cpr-exec migration whenever any VFIO device was present. It also removes the now unused vfio_devices_present() helper and its declaration. > diff --git a/hw/vfio/device.c b/hw/vfio/device.c > index 5a14a7d5c0a2e..9689f40daa172 100644 > --- a/hw/vfio/device.c > +++ b/hw/vfio/device.c > @@ -36,11 +36,6 @@ > VFIODeviceList vfio_device_list =3D > QLIST_HEAD_INITIALIZER(vfio_device_list); > =20 > -bool vfio_devices_present(void) > -{ > - return !QLIST_EMPTY(&vfio_device_list); > -} > - > /* > * We want to differentiate hot reset of multiple in-use devices vs > * hot reset of a single in-use device. VFIO_DEVICE_RESET will already [ ... ] > diff --git a/migration/migration.c b/migration/migration.c > index ab1f1641c2170..c513427df4367 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -2103,9 +2103,6 @@ static bool migrate_cpr_is_blocked(Error **errp) > } else if (cbw_filter_present()) { > error_setg(errp, "CPR is prohibited: active block snapshots (CBW= " > "filter) present"); > - } else if (vfio_devices_present()) { > - error_setg(errp, "CPR is prohibited: passthrough (VFIO) " > - "devices present"); > } else { > res =3D false; > } [Severity: Medium] Can this corrupt guest memory when the guest RAM is anonymous or private? With the VFIO branch gone, migrate_cpr_is_blocked() accepts cpr-exec for any RAM backend. cpr_exec_cb() then calls cpr_walk_ramblock(preserve_ram), and preserve_ram() only does: migration/cpr-exec.c:preserve_ram() { if (qemu_madvise((void *) ram.addr, ram.length, QEMU_MADV_DOEXEC)) { ... } It does not check that the backing is shared or memfd. ram_block_add() in system/physmem.c registers anonymous RAM through cpr_save_ramblock() without any restriction, and cpr_exec_cb() then calls execvp() with the VFIO mappings still pinned. The sibling commit "VZ: physmem: align fd-backed RAM like anonymous RAM" says anonymous RAM preserved via MADV_DOEXEC and pinned by VFIO_IOMMU_MAP_DMA is replaced by copies on first guest write after exec(), while the device keeps doing DMA to the old pinned pages. Would that leave device DMA and guest memory incoherent? The remaining VFIO blockers do not seem to cover this. In hw/vfio/cpr-legacy.c, vfio_cpr_supported() only checks VFIO_UPDATE_VADDR and VFIO_UNMAP_ALL. In hw/vfio/cpr-iommufd.c, it only checks IOMMU_IOAS_CHANGE_PROCESS. The qemu_ram_is_shared() check in hw/vfio/container.c only selects IOMMU_IOAS_MAP_FILE for iommufd, and the legacy container has no equivalent. The sibling commit relies on using memory-backend-memfd for such VMs, but QEMU does not enforce that. Should the blanket VFIO blocker be replaced with one that rejects cpr-exec when a VFIO device is present and any RAMBlock is not shared and fd-backed? [Severity: Low] Is there an up-front check for MADV_DOEXEC support on the host kernel? With the VFIO check removed, migrate_cpr_is_blocked() is the only gate and it no longer verifies this. On a kernel without MADV_DOEXEC support for shared PFN mappings of device memory, the failure shows up late: migration/cpr-exec.c:cpr_exec_cb() cpr_walk_ramblock(preserve_ram) preserve_ram() qemu_madvise(..., QEMU_MADV_DOEXEC) fails migrate_set_state(..., MIGRATION_STATUS_FAILED) By then the guest has been stopped and its state has been sent. The rollback at the fail: label in cpr_exec_cb() looks correct, but could a capability probe be added so that the migrate command is rejected up front? The dependency appears to be documented only in the commit message of "VZ: vfio/region: preserve BAR mappings across cpr-exec". [Severity: Medium] Does removing vfio_devices_present() leave vfio-user devices unblocked for cpr-exec? vfio_user_pci_realize() reaches vfio_device_prepare(), which inserts the device into vfio_device_list. That list was what vfio_devices_present() tested, so it used to reject vfio-user devices. The other blockers do not appear to apply. vfio-user attaches through vfio_device_attach_by_iommu_type(TYPE_VFIO_IOMMU_USER) rather than the legacy container, so it never reaches the mdev blocker in hw/vfio/container-legacy.c: if (vbasedev->mdev) { error_setg(&vbasedev->cpr.mdev_blocker, "CPR does not support vfio mdev %s", vbasedev->name); if (migrate_add_blocker_modes(&vbasedev->cpr.mdev_blocker, errp, MIG_MODE_CPR_TRANSFER, MIG_MODE_CPR_E= XEC, -1) < 0) { A grep for blocker, cpr and CPR in hw/vfio-user/ finds no matches. Can a cpr-exec migration now proceed with a vfio-user-pci device attached, even though its connection to the external server has no CPR support? Should a blocker be added for vfio-user devices? [Severity: Low] This isn't a bug, but is the include of hw/vfio/vfio-device.h in migration/migration.c still needed? It appears to have been used only for vfio_devices_present(). The remaining VFIO helpers used in that file, migration_populate_vfio_info() and migration_reset_vfio_bytes_transferred(), are declared in migration/migration.h. This has not been confirmed with a build, so could the include be dropped if it compiles cleanly? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261009-vfio= _v1-v1-0-2ae91d5b8048@virtuozzo.com?part=3D21