From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a1121a15c3-838dfbb7-16a2-407e-a0db-dda56b8f5726-000000@eu-central-1.amazonses.com> Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazon11021115.outbound.protection.outlook.com [40.107.130.115]) by lore.virtuozzo.com (Postfix) with ESMTPS id C66D7802A7 for ; Tue, 6 Oct 2026 16:44:26 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PSZUY4c+ljR3pQw7OHGwg9l+Hb3BSJnpcQUwfc04DKXoVeFZ3Y31h6Yqpv23E/V371RGlxXcO+xk0hwF5H6x/ucEJi41xbv+EuthKOfmvpq4nQi7b1TEicPGnnLylw04x/bXlqW7lq19tw5q+b5XHkojOSg8pTeLSmuvpONk2zNfFXANsEBgU7jCf/fsqXBF6maiU8udQg4Lb+QyOWS5504Nec4YOHGbMtygqBW9fW/O8+diqMjSWFNFk7Th+0h9+WsP9O2cyAqrq6NWzhnALzResXbz2EsY78EAw3S4Vap1XJnV6xoWVf670+ca19q1jU8xuV+uSnhEbsIlQ/SVLA== 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=iqdECd3QA640dVVcj4s0sn7XeffyyYoVhXv6084GkAE=; b=T8ZaNYcqcCT+lpk3J5Qx1rOGehSoUPTWIaODDZZxrwWg8JHC9P2vemUsUM60C9A7RiIr+kpKFumiVcv5waFiOLMAD1VmNqIZsJ/eGKmNZdb0nGDBomNZI6GEo4hiPMyKCpRgtD+71ps5tYCImUJ/xawR2wYnPV6inoPIEayZJ7DIY+KOQvhIcoXMkfpuG3Fqq61RZbXx/oJ5gG/H9QpN+VQOh3pzajUXYep8PFa626+/UapD98HcC8fzWGOlXtOaCB92NmtJmjXgmQOMmCX/XkzVjt6FbituS5Bv0LZfW9RloO2RYWaLep37ta+/eULJHSQPeBX/nyuJMLo1dBeiSw== 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=iqdECd3QA640dVVcj4s0sn7XeffyyYoVhXv6084GkAE=; b=b5+47ODeRh7NU9JgjMBoDbTFk8nXy017yYSADrno1kHIvaIZfH3F22IYvr9g0hXxGX3y8zycstfWCr8msZmK+ROEhrT5EP609k39uHo/WTdsrphRjtGeqXAVyuv5UVb4+kToelJeCv1ojj9BT5/SGuRMWWVnVIi4dAtq5cNVIEE= Received: from AM0P190CA0027.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::37) by VE1PR08MB5808.eurprd08.prod.outlook.com (2603:10a6:800:1a1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14; Tue, 6 Oct 2026 16:44:22 +0000 Received: from AM2PEPF00070CF8.eurprd02.prod.outlook.com (2603:10a6:208:190:cafe::57) by AM0P190CA0027.outlook.office365.com (2603:10a6:208:190::37) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Tue, 6 Oct 2026 16:44:22 +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 AM2PEPF00070CF8.mail.protection.outlook.com (10.167.242.10) 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 16:44:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791305061; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=1Hn9Ojw4VO9B0McjZjsrTInSzf67VFVzNo80RRTv/Qw=; b=jUfK7FNMUt0g0ZOKgiWy0OmVOIGGHnCZCeC1IaJu90pvE/2g0LqXJYQF0A9CzIOH Fc5YsIYKlXfcEnNk281jdQB3xrasP9BMU88qiFVPGfsPftE1k6uiO/ECeB+xd2Ht47B e3IBIOBeprTC9P0C3w4Rey+AO3TNG5Fw3q4ucEm3A/jgUuugo8Dg1yI60/qH1T/kD+K 9HNiekm28suEbzKGqi18LydPzZ/SOAGHOixWfi8K0IZScRjrlNOll2wDzJShlpmvP+1 0cAZ/2dAdhut0dwg5v2xo9Q2MFxXWh8bnoHiQkyD4wJ+mrsTQwG9QCQUSH8aOL2YTGn wx7gF7xbPg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1791305061; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=1Hn9Ojw4VO9B0McjZjsrTInSzf67VFVzNo80RRTv/Qw=; b=Y83i2WuoxFBUHmnX8onJDpy/xFK7dWIA9CEBNnWEoj1oew1QTJ4hsSkNe5n2Mcvc a7v/fzar/7YuaX0UPtKEHs0kETSajEYbQ1uZUn4oAB/tT03jXuUnc7k0pNWWjcVccM0 1BCd48AEiYaeDqfOdEnXFwoXUigl39FhwijGVDWI= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.0 v8 07/14] usb-host: re-issue drained URBs if CPR is aborted #VSTOR-137800 To: Andrey Drobyshev , svt-core@virtuozzo.com Cc: den@openvz.org, andrey.drobyshev@virtuozzo.com In-Reply-To: <20261006-usb-host_v3-v8-7-72ae4fb8977b@virtuozzo.com> References: <20261006-usb-host_v3-v8-0-72ae4fb8977b@virtuozzo.com> <20261006-usb-host_v3-v8-7-72ae4fb8977b@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Oct 2026 16:44:21 +0000 Message-ID: <010701a1121a15c3-838dfbb7-16a2-407e-a0db-dda56b8f5726-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.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM2PEPF00070CF8:EE_|VE1PR08MB5808:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2d55a450-8ebf-4aeb-bc09-08df23c912ee 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|48200799018|9140799003|32142699015|56012099006|10067099003|5063699009|5113699003|4143699003|5023799004|6133799003|22082099003|4113699003|16102099003|55112099003|18002099003|13003099007; X-Microsoft-Antispam-Message-Info: IaodpkfkYgU2GUdWnYtXy6FkHoSokgsLD7d9Mxk1X1zRjLyeMKyji4tdZDWJrG6NTq8C3koPBiVkZs/Y1hIgWnKLXaXgZzQGVgzNEoAMh/Z8STCPeIZ0LMVxuhu+I+SWpe8BLSQy9Da9FNqxKPfhFG+mp0ASGSeMyz/bNhay4wkwimAZCYzkechyQ33zNbVnkFRIK8joYYq2WVtjiwtjie4yCksAqpFncq+wZA+oXSy19+lU0cM+cf2l2+KFATPzIa+b6093xYNITgPzxD3bl1mRicrcVp7jFTpypfKDo+ZChQFXPWCz9t/qp5iF4iRbHuOqG4duL/oFWYms+ZATp8NSPaQiYb1MgnUbuvYHUZ7cR/ivq+DDhQ6F6/xLxoRr+w6UoqSRVQZuoO2z0JjpY8tqx1o6rGSDwOMEyDzM33KpG/lQfBKVVSzEODRZQW/hEg+KRReyuy4S/D629vwfr0VHNutpVXAf8f6AYFKF3rzXy77xFFsrrnzDwOB55aZI6FUX5qPUVWkJ9P33Bbej7Hol/VVOwr2G+HD4s/2ecFgTTW74qxt7EeCjC8ExDePEd0XH1JPxzv9aZUOZWp3BysdTNTcxWvbrdTcdDRmI39IsV1ckZ7UYHza2qcd9myEe2ahzbeRbjos77GFVqBi+BL2ebqUPU0oiTkmHGiCgmYGMfS1GJTXreLOxkWi0tQ1Wyi3+k3dVMA+hubLkEq/4r7kkThpyL2VBNQaJGfsH69sgKED6KBcHWaY3Cq/I5LHIfOpP9IdVnPRqVmEIfyKYHA== 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)(376014)(61400799027)(48200799018)(9140799003)(32142699015)(56012099006)(10067099003)(5063699009)(5113699003)(4143699003)(5023799004)(6133799003)(22082099003)(4113699003)(16102099003)(55112099003)(18002099003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: DFq2P0cIthe+PvLjoHX0pZXi1mPyldxx7p6jBaTszLQuVK1hn4sv855CS/JX+g9c/gmI8WQ3pFzsUFbQSCO/pBul2SiN+Y1Z5H5LRNhn/BS1EWScWr9kydspmPqY/Dcw/91PS/86NFk0PmvOEda/KrCSq/P8/4G128Q3GN4vhZle+4nPwPedPbiXyhaorP0hfsvWpey0BtuwuN8t0UWOpJVeCj4xC1QzKyLXxRoi5WEupth1ZwA7CEp6hkoCsk8ZgzNiOuwcPuOlXHA+IV3B9Bu5NF7ycNswdEF3MBeSL90SulDS2IbKdRIek/Ml7Oe1o9eX+R3TSAnjJ8Q/wDqq1fo1LIVq8c3b8c3eE1lLRctJ9nRV/coT0ODhLoUY337ky0oQA9PZVgLzOKcMJrPadPU6CJZDVhFxAril8v47Dpy/lNPQSJf/ZjzpB7OgwiHK X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 16:44:22.2321 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2d55a450-8ebf-4aeb-bc09-08df23c912ee X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: AM2PEPF00070CF8.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5808 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Medium] usb-host: paused-VM CPR drain replays fully completed URBs, not = just partial OUTs -- commit 9334effcb0d32b4173bab08303e8d2fef677d756 Author: Andrey Drobyshev usb-host: re-issue drained URBs if CPR is aborted #VSTOR-137800 This commit queues 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 USB_RET_IOERROR instead. > diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c > index 413ddc12ee43..9cc7d72aa63a 100644 > --- a/hw/usb/host-libusb.c > +++ b/hw/usb/host-libusb.c [ ... ] > @@ -433,9 +435,10 @@ static USBHostRequest *usb_host_req_find(USBHostDevi= ce *s, USBPacket *p) > /* > * Classify a reap during the CPR drain (r->p is still set). The paused= -VM > * fallback (cpr_replay_all) can't deliver completions, so it suppresses= every > - * reap for the target to replay; otherwise one that moved no data is su= ppressed > - * and one that moved some is kept as a short transfer. Returns true if > - * suppressed, so the caller frees the request. > + * reap; otherwise one that moved no data is suppressed and one that mov= ed some > + * is kept as a short transfer. Suppressed packets are queued on cpr_in= flight > + * for the target to replay. Returns true if suppressed, so the caller = frees > + * the request. > */ > static bool usb_host_req_cpr_replay(USBHostRequest *r, > struct libusb_transfer *xfer) > @@ -462,6 +465,9 @@ static bool usb_host_req_cpr_replay(USBHostRequest *r, > 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() (paused-VM fallback), the whole "if (!r->host->cpr_replay_all) { ... }" block is skipped. Control then reaches the g_slist_append() for every reaped URB, whatever xfer->status or xfer->actual_length is. That includes URBs that finished with LIBUSB_TRANSFER_COMPLETED. > [ ... ] > > +static void usb_host_cpr_reissue(USBHostDevice *s) > +{ [ ... ] > + for (it =3D s->cpr_inflight; it; it =3D it->next) { > + p =3D it->data; > + /* > + * Replay from the start of the TD. A transfer that already mov= ed some > + * data is re-run in full, so an OUT fragment the device consume= d may be > + * sent twice. Only the paused-VM pre_save fallback queues such= partial > + * transfers here; the normal drain delivers them as short trans= fers. > + */ > + p->actual_length =3D 0; > + if (p->ep->nr =3D=3D 0) { > + /* control endpoint: can't be reconstructed, so error it out= */ > + p->status =3D USB_RET_IOERROR; > + usb_generic_async_ctrl_complete(udev, p); > + } else { > + usb_host_handle_data(udev, p); Is the comment here, and the commit message, accurate about which transfers get replayed? The commit message says "an OUT fragment already consumed by the device may be sent twice. Only the paused-VM .pre_save() fallback queues partial transfers for re-issue". The code comment makes the same claim. The path is usb_host_pre_save() setting cpr_replay_all =3D true, then usb_host_cpr_quiesce(), then usb_host_req_cpr_replay() queuing every reap. In that path fully completed URBs are queued as well, not only partial ones. On resume after an aborted CPR, usb_host_cpr_reissue() then handles them as follows: - A completed OUT transfer is sent to the device a second time. - A completed IN transfer is resubmitted with actual_length reset to 0, so the data already read is lost and the device will not resend it. - A completed control transfer, for example SET_CONFIGURATION or another SET_* request, is reported to the guest as USB_RET_IOERROR through usb_generic_async_ctrl_complete(). Should the commit message and the comment describe this wider scope? Or should usb_host_req_cpr_replay() deliver URBs with xfer->status =3D=3D LIBUSB_TRANSFER_COMPLETED normally, even in cpr_replay_all mode, instead of queueing them for replay? > [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261006-usb-= host_v3-v8-0-72ae4fb8977b@virtuozzo.com?part=3D7