From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazon11023123.outbound.protection.outlook.com [40.107.162.123]) by lore.virtuozzo.com (Postfix) with ESMTPS id 93F0B802A7 for ; Tue, 6 Oct 2026 15:52:17 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OvKQrmjJz6IjRlooz4L2iQ7ZVlVzCavzKd5O8SWEvOo7fJOlNYxxJmr4qGGl16zuK2jhyDRy1K5cVmh1Gccvx+44ZtSX+2roGVnvVIe83761OGwlE2zFC+7erDNXPkRNDj1XimzlH4j8DYVkdwBOQJIGsxt4E2gPjlubOFBtKOeCfh2O9GGwLcAQGmioNlLqSe24o4PWoJrLw6urt9Sp9KXbHErKaAipSqUG0tciVrpH1VGqsXnOmIm18142f1mrfeEOk6mfIDrFjuxIBRWe0BcpGL0SCCngFupmbnIhU1aWSx2u+dgDczN+KLbWRCCryaSDhU2qNhY6inLrP5rzGw== 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=6lcHASbuX2eDrob1gngCggzUW23Mpv+2iB3mYXQOV2E=; b=DNhr/2lGudlECGgr9YQ/75AcodPV8BmCJfoKU+CeBhM+/5Ot/ZfSece+n+Yj90DZJmJVo4uN2UOtxVSpHsBVL3zf0T85deo4WYLiNBSpzvjTMl6Y5yEulkRAzAN39le7levfuPz//yGotFHljG7OjJLtEuhCQXafyiPeHm4z/nSYC55YTlkNUO/ygzsiEVuNW2iPz0q4lslHToo0hWTdEVpeS2tt6Jt9lbgPhc5whly/lBl+ti61pVckQSFXAM6PBNnrUTYUnMPAm69XPPF1VAl44z0eR7+Laz/0AnFCp7qgKC8+VlX6fvk7sU9BwQMo/gZQaG5BnplBkeeVoLceHw== 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=6lcHASbuX2eDrob1gngCggzUW23Mpv+2iB3mYXQOV2E=; b=h3YjyDpgfq7aeZseSVmX0iMHf0Ap2aR2b1hZiMa3Xp0FzxEFpRpHhYfo/O9bwn0QIrWQMx/eScI7xhScq3rKCr7h+6P3OKyMtlYyTPhhhUqmt5CkniCNP6dmue4UB9RO63oVgnWKy9uf9rReQhx7lYfTSQwpWbReI7FnElB/fU0= Received: from DU2PR04CA0278.eurprd04.prod.outlook.com (2603:10a6:10:28c::13) by DB9PR08MB9564.eurprd08.prod.outlook.com (2603:10a6:10:456::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.15; Tue, 6 Oct 2026 15:52:12 +0000 Received: from DU2PEPF00028D01.eurprd03.prod.outlook.com (2603:10a6:10:28c:cafe::98) by DU2PR04CA0278.outlook.office365.com (2603:10a6:10:28c::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Tue, 6 Oct 2026 15:52:12 +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 DU2PEPF00028D01.mail.protection.outlook.com (10.167.242.185) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.14 via Frontend Transport; Tue, 6 Oct 2026 15:52:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791301931; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=AyIqNGZb48MPuL2GO2uloYvxSikYPjrRKKkypLqvvVo=; b=Xo5Ujx9uc4raMWeHT90uzLd1P36iZ4PJ0vNFQN+GkMlv53/XHvC7w0BlUCTGALRU w1wKCt9K7D95O631qwOsKmtX6XuTvssWUCMvm/R++Nt+yPBuvwpAlAQoFVhrdV5NJbq kmASo8WW4HgsyxL6OqNLF64X7kqqp2gDrAWoM9GGrV4JuGkil9bGjNzKsAW1dDlJIem miAx9GpPUlxa6iW8GsJ6E1GfgupuMLY7o1QLFArxOKEXyP6NyuTGEbiolI+w1DmLOqu XhmracqWFTI8Z6x+3QPlP60TNNr1SF+DTffEkBzwzqP5piqQ1DqlZ+1wdRYpg9iSShx QbE2Y0aNrQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1791301931; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=AyIqNGZb48MPuL2GO2uloYvxSikYPjrRKKkypLqvvVo=; b=KPSulwcRsYPsvX9fr18GjMQpnvvXirvhnKpDAkmzkvyVYcOBI1e2gUJ/gjbbyzlm +SrXlxuHpvty0ySFm/uJ0cpNMWMXMV2q1PRF+zcUrxlYcvM/TRglWEGY73UmOF2WdvY QhRkzztydwrw1UFlf0UJHerMPFyQkMNvPA1xI5Rk= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.0 v7 10/14] usb-host: hand off the device across cpr-transfer #VSTOR-137800 To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: den@openvz.org, andrey.drobyshev@virtuozzo.com In-Reply-To: <20261006-usb-host_v3-v7-10-044f668789a1@virtuozzo.com> References: <20261006-usb-host_v3-v7-0-044f668789a1@virtuozzo.com> <20261006-usb-host_v3-v7-10-044f668789a1@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Oct 2026 15:52:11 +0000 Message-ID: <010701a111ea5277-f87b3df8-9b09-4ef0-9041-fa9d05c7d972-000000@eu-central-1.amazonses.com> Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.06-69.169.224.6 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PEPF00028D01:EE_|DB9PR08MB9564:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a3e79c62-b234-4778-64ad-08df23c1c942 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|32142699015|376014|9140799003|61400799027|48200799018|5023799004|5063699009|56012099006|4143699003|10067099003|55112099003|18002099003|16102099003|22082099003|5113699003|4113699003|13003099007; X-Microsoft-Antispam-Message-Info: iR9cHiwLro3OTMCarSBOxzyLQ1MLSahEFKI1VxslC9b2O0vrDNwGBKgMs4WKQ83GVR1zJUzK6jOrM/FnjZAneoeS8Y+ayjDGFWx/GFB9icKhiNqK/7hhHOngAJMK5BtEdemspOWJwhQSmT4lyfDGGzl9eghWgYnqF96A4zmDXYJArwC+xNNP0zaUIzHwryKJNmIghTZ/KRzyTIHEkgBpPyBIvFGFHfCnZBlNw1TiAjYSniNA7AwVjI9QGoeaKF440H9R6DhAbr7gNWofLGuKpBvlxxKX26WIXyAZaagdNNa/rhUHq0psu5/+0/U4XiqqIPUY/Z0HrLZYQFS8xrO6/JMO7NE6eC2KeZtKAz9koG84KZ4Xzq61mNRCMRTGe+fUNSfsTmrrAOvLg8phEwPrDODrdBtw8YoncCVf6+RenIIv2t5R+8racEXdlljptvFoguKjLRjjsSm58zZ1B9VDG5KJZ7MVDgB4OKrGve+l4rcli4TVWmKrqD449lP8ikUBkkNld4X4qqRIQUAGIjDlI7pSrzLg1Ok4AWFQWpyygwcAsKFBY1tfkWebUi+Hxa4Y+msqp90FrqETrkJ6Xa33LAl6GBMFzQTruKHmk28MamM9YiO4O+bu6fxBcicG6ici/gDQp/IKJkU/EogKVukEJ7cK7vo+p3wxgwTvHVUojpt/m9SnAVaamgRO3NkW5rVUH/niZ0rBHZi/Ao5BW0O9MB9ZT3sSBWZryjh3INEmesqUmqR2ouFY1sdkCN0cOjS6jtlI3jeRldQfZz9j3xCxQEJEPFsm9jqO8XtAw8yl1kTrGqnbugsX6amBvYjf2CmVwSl6/IvP0jlQC5Kx6cxIhiqCVeloweE190sMrCu+7H0YfNOiyTY5m4k+OM1BviCbH1tBTPc8gtF7nkzGh5boTOpplNQEexllrnI7Q4rFfG1uDasIeNcv71f11kL1szOj 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)(376014)(9140799003)(61400799027)(48200799018)(5023799004)(5063699009)(56012099006)(4143699003)(10067099003)(55112099003)(18002099003)(16102099003)(22082099003)(5113699003)(4113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Z+VG0OWKPMQ+Oe2Jdlxva0Hk/6LbHyfWDonym9WsJQC3T8WccUjekvHkwJWu12qW1NcGyIUpjWVw3LKTLK0uTKW4CO8EOz9wkLEZSSM/GRv/XSlj0ka1bbKM1xgulfl7NXgt9Fzb7igsY61Ao0nlIumRuBvERlWVPpY1XnhJqJDcLQzI3RGiea4m85fYA7uHUY2pTGgdtg3pROerRLetS4JAhWDtc2WQK63N9AtMAC8YU069V+yXKpMNavFUW7907XwNNjoRcgqMEglpbUAFX8Fq8c+9elPj+nvx1TO60eEl+Yf9Vw5Z75xvHFdXvQvkHSFeypdDVS13/OpF6X61s3yj6zA1ClAVDKZAWbZKZTH0yJ6IL3Qudw+4jF/sJWX1HVPhGjJc0Qddln8evRPd7HqGWb8BvMgibyXJ+z8J1389+2NsmmuBj8FxXYBLTJvO X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 15:52:12.1248 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a3e79c62-b234-4778-64ad-08df23c1c942 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF00028D01.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB9564 Thank you for your contribution! Sashiko AI review found 5 potential issue(= s) to consider: - [Medium] usb-host: cpr_handed_off set before migration outcome is known, = skips cleanup on failure - [Medium] usb-host: cpr_is_incoming() in realize() stops global event reap= ing with no restart - [Medium] usb-host: unrealize() clears handoff flag without restarting the= global event reaping - [Low] usb-host: unrealize() forces full reset even if the target may alre= ady own the device - [Low] usb-host: commit message does not match where reaping is stopped an= d restarted -- commit d5825316f822699756346d45e052e4ba605a47fe Author: Andrey Drobyshev usb-host: hand off the device across cpr-transfer #VSTOR-137800 This patch hands the usbfs FD and URB reaping off from the source QEMU to the target QEMU during cpr-transfer. The source stops reaping at quiesce time and skips device reset, interface release and driver rebind on exit. The target stops reaping in realize() and restarts it in post_load(). > diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c > --- a/hw/usb/host-libusb.c > +++ b/hw/usb/host-libusb.c [ ... ] > +static void usb_host_stop_events(void) > +{ > + const struct libusb_pollfd **poll =3D libusb_get_pollfds(ctx); > + > + libusb_set_pollfd_notifiers(ctx, NULL, NULL, NULL); > + if (poll) { > + for (int i =3D 0; poll[i] !=3D NULL; i++) { > + usb_host_del_fd(poll[i]->fd, ctx); > + } > + free(poll); > + } > +} [ ... ] > static int usb_host_cpr_quiesce(USBHostDevice *s, MigMode mode) > { > if (usb_host_cpr_drain_xfers(s) < 0) { > return -1; > } > + if (mode =3D=3D MIG_MODE_CPR_TRANSFER) { > + usb_host_stop_events(); > + s->cpr_handed_off =3D true; > + } > return 0; > } [Severity: Medium] Is it safe to set cpr_handed_off here, before the outcome of the migration is known? The flag is cleared only in usb_host_cpr_reissue(), which runs on a running transition, and in usb_host_unrealize(). Consider the case where usb_host_pre_save() calls usb_host_cpr_quiesce() as the fallback for an already-paused VM, and the migration then fails. Nothi= ng resumes the VM, so cpr_handed_off stays true. usb_host_exit_notifier() then skips the following on every later quit and only calls libusb_close(): usb_host_abort_xfers(s); usb_host_release_interfaces(s); libusb_reset_device(s->dh); usb_host_attach_kernel(s); Can this leave the device without a reset and without the host kernel driver rebound after a failed or cancelled cpr-transfer? The commit message says the skip happens only "On success", but the exit notifier cannot tell success from failure. [ ... ] > @@ -1371,16 +1402,19 @@ static int usb_host_close(USBHostDevice *s) > > trace_usb_host_close(s->bus_num, s->addr); > > - usb_host_abort_xfers(s); > - usb_host_iso_free_all(s); > + if (!s->cpr_handed_off) { > + usb_host_abort_xfers(s); > + usb_host_iso_free_all(s); > > - if (udev->attached) { > - usb_device_detach(udev); > + if (udev->attached) { > + usb_device_detach(udev); > + } > + > + usb_host_release_interfaces(s); > + libusb_reset_device(s->dh); > + usb_host_attach_kernel(s); > } > > - usb_host_release_interfaces(s); > - libusb_reset_device(s->dh); > - usb_host_attach_kernel(s); > libusb_close(s->dh); > s->dh =3D NULL; > s->dev =3D NULL; [Severity: Medium] The cpr_handed_off gate here also skips the QEMU-local steps usb_host_abort_xfers(), usb_host_iso_free_all() and usb_device_detach(), not only the reset, release and rebind that must not run under the target. If usb_host_close() is reached while the flag is stale, for example via usb_host_nodev_bh() or usb_host_auto_check(), s->dh and s->dev are still set to NULL. Can that leave a guest-attached device with no libusb handle? Should the gate cover only the device-affecting calls (release, reset, rebind)? [ ... ] > @@ -1487,6 +1528,14 @@ static void usb_host_realize(USBDevice *udev, Erro= r **errp) > + if (cpr_is_incoming()) { > + /* > + * The source still owns the shared fd until it hands off. = Don't > + * reap URBs on it yet, or we would steal the source's in-fl= ight > + * completions; .post_load() restarts events once we take ov= er. > + */ > + usb_host_stop_events(); > + } [Severity: Medium] Can this stop event reaping permanently for a device that is not migrated? cpr_is_incoming() is "incoming_mode !=3D MIG_MODE_NONE", and incoming_mode does not appear to be reset after the migration completes. If a usb-host device with hostdevice=3D is hotplugged on the target after t= he CPR migration, usb_host_realize() takes this branch and calls usb_host_stop_events(), which clears the pollfd notifiers and fd handlers on the shared libusb ctx. usb_host_post_load() is the only place that restarts events, and a hotplugg= ed device has no vmstate section to load. Would URB completions then stop bei= ng reaped for that device and for every other usb-host device? [Severity: Low] This isn't a functional problem, but the commit message and the code differ in a few places: The target doesn't reap until it takes over: it stops events right after opening the FD in .realize() and restarts in .post_load(). The condition used is cpr_is_incoming(), which is true for any incoming CPR mode, including cpr-exec, where the fd is not shared. The source stops reaping in .pre_save() and, since it stays alive, restarts reaping from the vm-state handler's resume branch on failure. The stop happens in usb_host_cpr_quiesce(), which usb_host_cpr_vm_state() calls on the FINISH_MIGRATE transition. usb_host_pre_save() reaches it only as a fallback for an already-paused VM. Could the commit message be updated to describe this? [ ... ] > @@ -1550,6 +1599,12 @@ static void usb_host_unrealize(USBDevice *udev) > + /* > + * An explicit device_del means we still own the device (a successful > + * cpr-transfer handoff exits the process instead), so clear the han= doff > + * flag to force a full reset/release in usb_host_close(). > + */ > + s->cpr_handed_off =3D false; > usb_host_close(s); > migrate_del_blocker(&s->cpr_blocker); > if (s->cpr_vmse) { > qemu_del_vm_change_state_handler(s->cpr_vmse); > } [Severity: Medium] Does this path leave event reaping stopped for the other usb-host devices? Suppose usb_host_cpr_quiesce() has called usb_host_stop_events() on the who= le ctx, and the migration then fails or is cancelled while the VM is paused. = No running transition occurs, so usb_host_cpr_reissue() never calls usb_host_start_events(). A later device_del reaches usb_host_unrealize(), which sets cpr_handed_off =3D false and removes cpr_vmse without calling usb_host_start_events(). usb_host_init() returns early once ctx exists, so nothing else restarts reaping. Can transfers on the other usb-host devices (hostdevice=3D, autoscan or bus/addr) hang here, since the stop applies to the shared context? The commit message says only one hostdevice=3D device is supported, but nothing= in the code appears to enforce that. [Severity: Low] Can this unconditional clearing of cpr_handed_off cause a reset of a device the target already owns? The comment assumes that unrealize means the source still owns the device. During the handoff window the source has cpr_handed_off =3D true and the ta= rget may already be reaping. If a device_del or guest eject reaches usb_host_unrealize() then, usb_host_close() runs usb_host_abort_xfers(), usb_host_release_interfaces(), libusb_reset_device() and usb_host_attach_kernel() on the shared fd. Is it intended that this disrupts the target's session? [ ... ] > @@ -2033,6 +2088,7 @@ static int usb_host_post_load(void *opaque, int ver= sion_id) > if (cpr_is_incoming()) { > + usb_host_start_events(); > return 0; > } This is the only restart point on the target, and it runs only for devices whose vmstate section is loaded, as noted in the usb_host_realize() comment above. --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261006-usb-= host_v3-v7-0-044f668789a1@virtuozzo.com?part=3D10