From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a19bf01e55-d6992272-464a-4117-9afa-34a8e7133286-000000@eu-central-1.amazonses.com> Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazon11023114.outbound.protection.outlook.com [52.101.83.114]) by lore.virtuozzo.com (Postfix) with ESMTPS id 1A23D8045D for ; Mon, 2 Nov 2026 11:06:14 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Nt9m5ISjaDslsYc27Q1as+U6l7CF11ao3fp5l4h7y32+RSlAkNOGms8IKTv/BQdWVyA4f7yVZgF/RyC69lAPEjktRHgsdVXqIodvppUSFIcRWmLWQAAzAuueJBHnv0yrvaY8UYMfK2OH+aWOW0aTuCAx6m+JPEJTb8dmDO8E7gni3fdWLR78xmZbzLFz4boLT9jCrhxdqksF0rqjOmNSl1GcZi9jKSkKS7Itw+NZ9gYlAtWLs6DkufUSAxjBdHHRlnP71et1Lps7UmQ/wOmSV5irMdFD09VyyAb43KCsJNEn+snHxn2RQ6PIm6CnRkGfBBHiD+pv4PSZV2cR/BX3Fg== 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=x3Kpv++kajqzW4lypsOQgl7Pk6GggASZmVUhtFmBKsE=; b=P3kQYqf4Yy8cGBI2KVEJjs6V1hSW1/5qFqwhb2O8gq2iwFjAm0jpdxD/um7fEwwu++VWhX5kSZZlDXfnH88+y9sJc22nTtC9MqtyIWp446S2x+LyV1GYdMZaVzhNmLvkOmgtVikYjxA6MbO9qfPNI9ENniJxd3aeOqgvhd9jXZ51WJPQjuKjrDkfmyE2twDWE+xFUx0D7p5my9e9VLJPs8T3y/tJnzBbwlbA1JGjUHmOqYkTSyDvXkj1E0nEnJqKZVSxpYGObOMJLj8F/32wg5qZlUW/pyAHFqlzzidhstsTlpoGxH57QM3C/BFTJaX8xYV3jfXrZX/Q4BS4bhVFDw== 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=x3Kpv++kajqzW4lypsOQgl7Pk6GggASZmVUhtFmBKsE=; b=gwu9otIPFT6OxsOD5ZHl30MNZ6HIN9Mwkzckd1UutyxmbjyDym3DPyaOCmcfvI5z0r6sf6/SwSs/EC/JM3zCIkGdPJQNA6QYJZGE3LJELxwae/6fYve4QWIZaX1Ntc/tjMISXJYt5IA5eOxyX8rrB7h+W+JplsOhbNLm7n60bjo= Received: from DUZPR01CA0008.eurprd01.prod.exchangelabs.com (2603:10a6:10:3c3::17) by PA6PR08MB10471.eurprd08.prod.outlook.com (2603:10a6:102:3d0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.12; Mon, 2 Nov 2026 11:06:08 +0000 Received: from DB1PEPF000509EA.eurprd03.prod.outlook.com (2603:10a6:10:3c3:cafe::87) by DUZPR01CA0008.outlook.office365.com (2603:10a6:10:3c3::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.12 via Frontend Transport; Mon, 2 Nov 2026 11:06:08 +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 DB1PEPF000509EA.mail.protection.outlook.com (10.167.242.68) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.592.5 via Frontend Transport; Mon, 2 Nov 2026 11:06:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793617567; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=+6Q3XpnhuOiISPQrnUbZPFYzB3GjsTbz/PxANGWAEHI=; b=NIIgTrOrnPlv9qC5v+atieh+C77P+dMMxiBqsGRI9+AjJe3hzRcn1aCVvOmse4QO BlXUOKQ1FEOUukadumhc+dFTZvTso/TE7DG4NpQ7w7cJBXT3mL4vO/EaRE2FLr5IB8M 9X444w0Ir8xcUcy2WVdlbQWHIrKNGm9LcWmDIvIh4yXTTntQmgZGWoAJH9aAis/OysK DyJDZt0qpEawIaJGbC7eD4vRjX/pHB4xCQl9zWASHgYQk+XXDK1k05fEOkXYNKElORC /DJPCtDvY9geyt1jz9EVkTTETs5jXgdghNRiR78kkTpNPmqf9koPcbsQBr4Bf6agH/R IS++FUqGiQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793617567; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=+6Q3XpnhuOiISPQrnUbZPFYzB3GjsTbz/PxANGWAEHI=; b=oTdVav7IYLjAJ+ibbtgXfyWZvkopfZm98L9l0yTo+NrGdNlKne9MXYqPQYY6Flh+ XIFYn3Tkq49eOV4L28LcrGYKhBWna1rqB4xkghcR1CQffopvZADyktf698jzaB3cijB uYv7kUrYPirpofxHKTDYDFuHDNMc6ujxH2TilaEo= Message-ID: <010701a19bf01e55-d6992272-464a-4117-9afa-34a8e7133286-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v6 26/34] vfio/migration: don't assume the device is running on CPR incoming To: svt-core@virtuozzo.com, Andrey Drobyshev In-Reply-To: <20261102-vfio_v1-v6-26-9bc7cabc850d@virtuozzo.com> References: <20261102-vfio_v1-v6-0-9bc7cabc850d@virtuozzo.com> <20261102-vfio_v1-v6-26-9bc7cabc850d@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2026 11:06:07 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.11.02-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB1PEPF000509EA:EE_|PA6PR08MB10471:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 79b83e78-0180-40ca-68d1-08df38d14bb1 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|32142699015|61400799027|48200799018|376014|9140799003|4143699003|56012099006|5063699009|261009223027099003|261028144727099003|261026121527099003|261021121427099003|261026140227099003|261022105027099003|261022075727099003|10067099003|16102099003|55112099003|18002099003|22082099003|4113699003|5113699003|13003099007; X-Microsoft-Antispam-Message-Info: Z6J1+rozRURrJAy0tIfmiqZR/g/kXuKkLMYo/W+ucDE2GlUW+KGDigzkYdPoCz5/enRA7rEyvObIyvhp4HtTjGSVZBgVOkDXdEK3fanrLDPJ7AyXGuTPhRMT5PTsuYLZiL1Rx6gjOJJ67t6kSbkLL/+FXK+6ThV+sLHMWawFDzfaEkSl4jDK8tbZ60i5lszujj2tpGw01ko87I1LMbCoTBuplVQbF3O8Aq7Cu4mXgNZkpkjWw+IosHzAbJzgR49EeeFK4l4mL1+ft1LavyONUwwUTrrl5lz8Uxi6+nHoaWqVU5oYHlZHXHmSYbQ1TnBosUJrRNzuoJkrFQhYEsXjat9IvS9x0UJ358tErEnpWQz84+j/KD/L1UD4dV7bHLlAVZqtikeixilB1OvSMKOXY6PCFzligZu03L+JeoF3KNHVYjis9wHi4h9UzPby2qdQOQqaGlUDWBJ/Qm8J37xeDCCLe8frvb7KkIPcCGLgSbYYxrsME/Fsh0o71sz+YXaJ533EPQwOT8HJAMDca7YdfyVRJvVKDEhGquRNbl0KcN5V0+iK1KracBpC9dR/CUmhc5HddmVHhrHz4PEOMvnpNZUwKFoSoCZ2JV2QEn3wlP74ahAjYuRIswgtnCf9+G5YwJsYslFEfOT61sgLv+GywWGjYt41s7jl6ujKHSnO/FwtuhQpxz9L+C2+jaiNA+VRLGl1Dn7uwEyk5N8EF/tmzWExWFlv5qliXs30o3MgtZdKW5V8aMKDfOnn1AxPsk3yn8ylHx6Gyz9fFfYteSlaKMdls58gyCVLXm6JcCz8s717gvN/UEtgB6r4eTVDfYqFg9Alfm4T6WavqCgRsGj0cTNarWtUGj8h3EqeA+uv093S2SaCLFaCS+ZHQSLKKoxK 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)(32142699015)(61400799027)(48200799018)(376014)(9140799003)(4143699003)(56012099006)(5063699009)(261009223027099003)(261028144727099003)(261026121527099003)(261021121427099003)(261026140227099003)(261022105027099003)(261022075727099003)(10067099003)(16102099003)(55112099003)(18002099003)(22082099003)(4113699003)(5113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: x+qma7Q1ko2pjigGC0KEiEmiFS1dWu6oeiypmBeev+BOeGNM0wOnmjbs3yjQoU3a2yKx8dlxBXJrVyBJ78P4/4nO93lECU1n4VgRAHZWG35aNgOkXLNCmFcje1+lNVKAOlw+92eExnJB2fk0Qc+3jGBeaFo33kgTFaRuoS9MgT1MHTZjGJCzW0YLf1KjJpOq9SEKg819ZiBOzCZJDBZYuaX7JwqmpVOxd4NDkzed2VbFQb5hCQDlVlToAOiB60zEb35GgnBbz2TIfVl8UIb3v44VpRxZMjiW4IkJHuHtsPrE448xHhuHw4IdgbBjYprZrd2NZpNKpkDjqPzktU2QcY6Vbmy4NF4GyhyIFpVM9n846hZxFvgwyeUjDpZFn5QaWO6JepxoBb15OVgEwx9q3RBso4DfgK+BMyENcm/9exZnVdn7wzUJh8Fni6jl36jT X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2026 11:06:07.8237 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 79b83e78-0180-40ca-68d1-08df38d14bb1 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: DB1PEPF000509EA.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR08MB10471 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Medium] vfio/migration: CPR incoming caches STOP even if the device is R= UNNING -- commit 198a3c353e05a9a3251b20ef27d8db4a03370b16 Author: Andrey Drobyshev vfio/migration: don't assume the device is running on CPR incoming This patch makes vfio_migration_init() cache STOP instead of RUNNING for a device inherited across CPR. It also makes vfio_vmstate_change() record RUNNING or STOP on the CPR target, depending on whether the VM is started. > diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c > --- a/hw/vfio/migration.c > +++ b/hw/vfio/migration.c [ ... ] > @@ -914,6 +914,14 @@ static void vfio_vmstate_change(void *opaque, bool r= unning, RunState state) > Error *local_err =3D NULL; > int ret; > =20 > + /* CPR target only: the device kept its state, note where the VM lef= t it */ > + if (cpr_is_incoming()) { > + vbasedev->migration->device_state =3D running ? > + VFIO_DEVICE_STATE_RUNNING : VFIO_DEVICE_STATE_STOP; > + return; > + } > + [Severity: Medium] Can this handler leave the cached state wrong when the target stays paused? This branch only runs when vm_state_notify() fires. On the target, process_incoming_migration_bh() takes this path when the VM is not started (for example with -S or autostart off): } else { runstate_set(RUN_STATE_PAUSED); } runstate_set() only validates and records the transition. It does not call vm_state_notify(), so vfio_vmstate_change() never runs. If the source VM was running at CPR time, the device was left RUNNING. This is because vfio_vmstate_change() and vfio_vmstate_change_prepare() return early under cpr_is_in_progress() on the source. The target is paused but the device is still RUNNING. [ ... ] > @@ -1039,7 +1047,9 @@ static int vfio_migration_init(VFIODevice *vbasedev) > vbasedev->migration =3D g_new0(VFIOMigration, 1); > migration =3D vbasedev->migration; > migration->vbasedev =3D vbasedev; > - migration->device_state =3D VFIO_DEVICE_STATE_RUNNING; > + /* A device inherited across CPR is in STOP unless the VM gets start= ed */ > + migration->device_state =3D cpr_is_incoming() ? VFIO_DEVICE_STATE_ST= OP : > + VFIO_DEVICE_STATE_RUNN= ING; [Severity: Medium] Does this cache STOP for every CPR-incoming device, even when the source left it RUNNING? If the target stays paused, the cache stays STOP while the device is really RUNNING. The commit message says the device is "STOP if it stays paused", which doesn't hold when the source VM was running. Is the real state ever queried, for example through VFIO_DEVICE_FEATURE_MIG_DEVICE_STATE GET? As far as I can tell, no later patch in the series does that. The stale value affects these callers: hw/vfio/migration.c:vfio_migration_set_state() { ... if (new_state =3D=3D migration->device_state) { return 0; } ... } Any request matching the stale cached state is skipped without consulting the kernel. vfio_device_state_is_running() and vfio_device_state_is_precopy() also return wrong answers. The dirty-tracking check in hw/vfio/listener.c uses them: (vfio_device_state_is_running(vbasedev) || vfio_device_state_is_precopy(vbasedev)) The vfio_save_setup() switch uses the cached state too. With the target paused, 'cont' sends a redundant STOP->RUNNING request to a device that is already RUNNING. This is probably benign. A live migration out of the paused target before 'cont' still issues the STOP_COPY request, since STOP_COPY differs from the cached STOP. I did not find a proven data loss on that path. The stale cache also persists after the incoming migration finishes. migration_incoming_state_destroy() clears the incoming mode, so the cpr_is_incoming() branch in vfio_vmstate_change() can no longer correct the state when 'cont' runs later. Could the cached state be taken from the device itself, or could the paused target case be handled explicitly? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261102-vfio= _v1-v6-0-9bc7cabc850d@virtuozzo.com?part=3D26