From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a110d22f9b-2bc514aa-aa87-4f14-9f9f-3cfde3d1fe96-000000@eu-central-1.amazonses.com> Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazon11023084.outbound.protection.outlook.com [52.101.72.84]) by lore.virtuozzo.com (Postfix) with ESMTPS id 7F78A8017D for ; Tue, 6 Oct 2026 10:46:19 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ge1htJ1hFHmJmjiHVH3hIBvvxfwcVSFlgRB1AY0zEYEo0w0jQ1T52XlbHWNuua9Jutsntngvz21djsHOtZ2Lu/W0Mpl6Lt2+KDpXa2h95nHV13bc+Jy8yG8McthZC45zugizhVU1SgozbsR15rQOyJ/E4hqC6tcApssi7BPwexoGGVsFabxpfFrD/95/IlSR7aK6MlGRFLvL5VRlrnuAZoTmCPZBFfnxNLiR5z2FBobMdqCvNf1yPfvBjrUJ0bWap6k8jFVYn89T9sDTQgsvpfgV0/RdD4j6BjOs1v1tBVmmF3bEgMytJPnbbpf4Fuiu4qLAyUFM0ZEOqZatQbQsUg== 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=4bIFyAAE+XiZj10MBB+jGsi5L25gkBIO6zy7UVnJXsQ=; b=OaxL1kjQGfSklqa2OCIEDKbcEEeBX2J/r+OZ3eOBoNqPYBzpxJZMafUioWXMUprUjzI/OEr2337Y+87NmYnOAYGUR42o8svzu6ejxeml4tgVsKhR5y5luip5wZuYEH8oUDlsHXmo9taWW9Y+z4ew4re4T20Opi5+FUFCiB2rydKBWej/gijaQF26Ikfnq+v4iZFZQe47vXLFMwJIKJytEvPsMwA/oWrLvQJgwYMRY/LJtQvGFREcORy065vrPQXv9lsZXxk1oe3dyQpnc+FjSYLeK0TQclTDR34THhi4qHqoUPrjzg0f6lt9HypKQfcNZz7Ho/jHkn3DB0w0TS/BUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.2) 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=4bIFyAAE+XiZj10MBB+jGsi5L25gkBIO6zy7UVnJXsQ=; b=nv/s1A17+znHSJLpnRYOQO3IC1gnFYsyUhV06c3VNFCPQ/+9QO9TKbAgBiPJS/1wy14m8jR53LgOLreoROOw3sEoCn1Xd3QJN9Ud4jjKRUuLKPigJBdG2ykq9CJL1n5B3gyp8LBHCHA9U84KCeB+s+QIXwZ9hTUvdx1VYfci/UI= Received: from PA7P264CA0166.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:36f::17) by AS8PR08MB6551.eurprd08.prod.outlook.com (2603:10a6:20b:319::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.27; Tue, 6 Oct 2026 10:46:13 +0000 Received: from MI3PEPF00008483.eurprd02.prod.outlook.com (2603:10a6:102:36f:cafe::16) by PA7P264CA0166.outlook.office365.com (2603:10a6:102:36f::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.21 via Frontend Transport; Tue, 6 Oct 2026 10:46:13 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.2) 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.2 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.2; helo=b224-2.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-2.smtp-out.eu-central-1.amazonses.com (69.169.224.2) by MI3PEPF00008483.mail.protection.outlook.com (10.167.240.170) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.14 via Frontend Transport; Tue, 6 Oct 2026 10:46:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791283572; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=Uzv2A9vev3+d7+tjjaW2sRsRpxqzS1jEJkJs41RTKfI=; b=gMTPvIhe8kZFbWCJ07BJOtuIme8T8EIQ5m9XVUz8uoQ0+rsG/uZ2irwIbpzYWgHF c1Fil26LiaJyL2KCcJTtsYXZmHt1iBzZ5hMIvsQ0NljXuGXK90EybJfmZhtsD3jAbLv YRF8U5iYsU4vb3eNnhGZrpBzx8cN4P11QJb1G8IKlQzLph2XkVO4HgBLeSS1TbJFlWJ PPn2vg4fFaTszPQn8N9AKxwV4XHxKCg955j2NUk5g1CaVdYG0K8334jv2QaLV0womkb uDuyE2GX8n2gkIVi8TvNe5chdDWWm8JKKs9QM9v2EtGzHWjOLv5nVaubMVsr6VsLdZj UMSidE/LDw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1791283572; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=Uzv2A9vev3+d7+tjjaW2sRsRpxqzS1jEJkJs41RTKfI=; b=TxsckxRcoSfRzk9+aP4IPHhRbs7dv4xHHxkmJnwa6lRkbpqXqCJKB/L+qGoBawRQ vBUEpzPF6cPtTUgP6lr+stGSQooYA1JasGt0FNqyCmfF9YIpzeUTl1P3C6mr5wIGBtQ bKTzZ+9Ds0pJozZ1cUz5YIX2bDyTX1eafZHC0i8I= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.0 v6 06/12] usb-host: re-issue drained URBs if CPR is aborted #VSTOR-137800 To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: andrey.drobyshev@virtuozzo.com, den@openvz.org In-Reply-To: <20261006-usb-host_v3-v6-6-8688ec9576d1@virtuozzo.com> References: <20261006-usb-host_v3-v6-0-8688ec9576d1@virtuozzo.com> <20261006-usb-host_v3-v6-6-8688ec9576d1@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Oct 2026 10:46:12 +0000 Message-ID: <010701a110d22f9b-2bc514aa-aa87-4f14-9f9f-3cfde3d1fe96-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.2 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MI3PEPF00008483:EE_|AS8PR08MB6551:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 10d88912-005e-41fb-0df7-08df23970a6b 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|376014|61400799027|32142699015|9140799003|48200799018|5023799004|56012099006|5063699009|4143699003|10067099003|55112099003|22082099003|4113699003|5113699003|16102099003|13003099007|18002099003; X-Microsoft-Antispam-Message-Info: +PREwUUR7AgBKQWH3MzokoCdQvXxbjcnOyxKMih827Rvynm6YwP7AZfo4dNhyQDrF1kIBFAnQ1MyT6g1CMa36lFkDPj1/g5nBvaPKUxJc5eYjasfLYOgOSLUHT75i/1Nv6w4sL3R49U30p+HBA6tJrGAPGDqxnydXpZgMr4Ow2V0oPtxrJhOWLOft1niKoKCr9jb7tDk1RPGW+hZ6+QmOr5vRPexc4gcqga1C2ydbpRTh3YjVOuhZYIK7Aeyz1K13XvtK6CEeRyU2bqiorA8cgl3Y/V/JAInYvbn9wd5o2qW6kb+oA3RfAZZmwh/LMALzw0kmYxpjn6VP1ZM7USsvCvxDsGz2jIVqK+aRCuwJ2y9Wsda3Brd90h2xSVt+1y6DPYpT2F02nRZ63zitc3h4GDJ99TB0T4YrobQBk3K8Io1YiGaVxYwrsZfEm7AHxOH+OIn5m7BFpdMwuS+cTMg3cUP4mhh/Z0GGKUSS7xjCGmDdAGiQ6hX8fG78q4n7fstDfX/fdHHvgQGwEsRNsKqEXb0rtft5DvUkH9ymXCRzbjjhhrK01ZOi9m8+toFwl61M6cTtXET4P01HFexyYznzymbXOmLvVHPa7yfijgYR1DkJCw7B2/L0QcjN3yPg+CsKNexBsEBKgtiVcwVy/8Ocw8248zv52o6Fz3XFpca22ZQHSlog7HfiJEQz01wXyjJzQzs8Mceax1bRiby906jFDP7fxrkBvK3oPphMl9fO8MgLkl9ngJIQEQBxclooZpKYmf4dB64EKIoV4jgD8/Jb5Rp88lSHqyVGpmHU8Ex49OMgVO4RS68ocTQdb2dbvhv X-Forefront-Antispam-Report: CIP:69.169.224.2;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-2.smtp-out.eu-central-1.amazonses.com;PTR:b224-2.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(376014)(61400799027)(32142699015)(9140799003)(48200799018)(5023799004)(56012099006)(5063699009)(4143699003)(10067099003)(55112099003)(22082099003)(4113699003)(5113699003)(16102099003)(13003099007)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: g9ViFwmXi98zfrPaHXpiSxfoq7AuXF1M1Jxv2dF5Sfu2AGbl8rgmlWuBk/pyblID+A6M4CasT5wszJSax7Cm2NktOvj1X5zlIs1XhjC4+po8N/G6DvlPLECKS5J+g0dq89ZgqIDnWe0OmdyDAQvED7C2fEFZHlhknT9TZ8+xkFam6L7pYK+SLtuDhI83Kq/PkAaSAOT7B2+PfJxRK0tDa13rZ9bIOZAgBJxWwpedbHK5ZgbvoAOMuuDzE3U5QWuluF+suRUp8twnr3SoaGXNjVkTB+cDF11D9fAHefRljw46LXRl1j825Ls0PEeEpuwmzTMangcHT/wWH+9j0LcGzAkVaSVN9lrU2uSjea8oZEnGOOmO3jgiILvui0pt60WvXWDoyDjcZLqbJGJk09YbG9cNald3VPW6yz6jzx3eSUMWd9C4i/JLoKvjDXLbX148 X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 10:46:13.0959 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 10d88912-005e-41fb-0df7-08df23970a6b X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF00008483.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6551 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Medium] usb-host: cpr_reissue() completes failed combined IN packets wit= h plain usb_packet_complete() - [Medium] usb-host: cpr_vm_state() returns on NULL dh before reissue, leav= ing CPR state stale - [Medium] usb-host: replay from offset 0 under cpr_replay_all duplicates O= UT data and loses IN data -- commit cf25e5a0b05e40289cd96941160f3044c5ee49c9 Author: Andrey Drobyshev usb-host: re-issue drained URBs if CPR is aborted #VSTOR-137800 This patch records the packets suppressed during the CPR drain on a new cpr_inflight list. If CPR is aborted, the vm-state handler's resume branch re-issues them on the preserved fd. Control transfers are completed with an error so that the guest driver retries them. > 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 [ ... ] > @@ -446,6 +448,9 @@ static bool usb_host_req_cpr_replay(USBHostRequest *r, > xfer->status =3D LIBUSB_TRANSFER_COMPLETED; > return false; > } > + if (r->p->state =3D=3D USB_PACKET_ASYNC) { > + r->host->cpr_inflight =3D g_slist_append(r->host->cpr_inflight, = r->p); > + } > return true; > } [Severity: Medium] When cpr_replay_all is set by usb_host_pre_save(), a cancelled URB with a non-zero actual_length is also suppressed and queued here: if (xfer->actual_length !=3D 0 && !r->host->cpr_replay_all) { ... } If CPR is then aborted, usb_host_cpr_reissue() restarts that packet from offset 0: /* Replay from the start of the TD */ p->actual_length =3D 0; Can this duplicate data? For an OUT endpoint, the part already sent to the device would be sent again, since usb_host_handle_data() copies the whole payload and resubmits it. For an IN endpoint, the bytes already read from the device would be discarded, so the guest would never see them. Also, cpr_inflight is filled in libusb reap order. Is that the same as guest submission order when several URBs are pipelined on one endpoint? I could not confirm this from the code. The commit message does not mention this limitation. [ ... ] > @@ -1254,17 +1259,26 @@ static int usb_host_cpr_drain_xfers(USBHostDevice= *s) > static void usb_host_cpr_vm_state(void *opaque, bool running, RunState s= tate) > { > USBHostDevice *s =3D opaque; > MigMode mode; > =20 > - if (running || !s->dh || state !=3D RUN_STATE_FINISH_MIGRATE) { > + if (!s->dh) { > + return; > + } > + if (running) { > + usb_host_cpr_reissue(s); > + return; > + } > + if (state !=3D RUN_STATE_FINISH_MIGRATE) { > return; > } [Severity: Medium] Can this early return on a NULL dh leave stale CPR state? Before this patch the !s->dh check only guarded the drain. It now also skips usb_host_cpr_reissue() on resume. Consider this sequence: usb_host_cpr_drain_xfers() suppresses requests and queues their packets on cpr_inflight usb_host_nodev_bh() or unplug usb_host_close() s->dh =3D NULL resume usb_host_cpr_vm_state(running) if (!s->dh) return; Here cpr_drained and cpr_replay_all stay set. A later CPR attempt then skips the drain, because usb_host_pre_save() tests "s->dh && !s->cpr_drained". In the base patch, usb_host_close() calls usb_device_detach(). The HCD then cancels the packets through usb_host_cancel_packet(), which drops them from cpr_inflight, so the packets are not stranded in that case. With the later patch "usb-host: hand off the device across cpr-transfer", usb_host_close() skips usb_host_abort_xfers() and usb_device_detach() when cpr_handed_off is set. In cpr-transfer mode, a device loss between the drain and the resume would then leave the guest packets ASYNC with no request behind them and nothing to complete them. cpr_handed_off would also stay true. Should the resume branch run the reissue and the state reset even when dh is NULL? [ ... ] > @@ -1356,6 +1370,45 @@ static libusb_device *usb_host_find_ref(int bus, i= nt addr) > +static void usb_host_cpr_reissue(USBHostDevice *s) > +{ [ ... ] > + } else { > + usb_host_handle_data(udev, p); > + if (p->status !=3D USB_RET_ASYNC) { > + /* Completed synchronously with error */ > + usb_packet_complete(udev, p); > + } > + } [Severity: Medium] Does this completion handle combined packets correctly? usb_host_handle_data() can return a non-ASYNC status synchronously: - USB_RET_NODEV when libusb_submit_transfer() fails - USB_RET_STALL on a halted endpoint - USB_RET_STALL when streams are unsupported For a bulk IN endpoint where usb_host_use_combining() is true, the packet on cpr_inflight is the first packet of a USBCombinedPacket. A plain usb_packet_complete() then completes only that first packet. The normal completion path in usb_host_req_complete_data() does this instead: if (usb_host_use_combining(r->p->ep)) { usb_combined_input_packet_complete(USB_DEVICE(s), r->p); } else { usb_packet_complete(USB_DEVICE(s), r->p); } Can the other sub-packets be left in USB_PACKET_ASYNC with p->combined still set, and combined->first pointing at an already completed packet? That could wedge the pipelined bulk-IN endpoint. The existing usb_host_req_complete_err() uses the same plain call, but this reissue error path is new in this patch. The later patch "usb-host: make CPR migration blocker conditional" does not change this code. [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261006-usb-= host_v3-v6-0-8688ec9576d1@virtuozzo.com?part=3D6