From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a1122276a6-8ce4d6a0-292d-4bf1-a23d-706b549512bf-000000@eu-central-1.amazonses.com> Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazon11023138.outbound.protection.outlook.com [52.101.72.138]) by lore.virtuozzo.com (Postfix) with ESMTPS id 5A319802A5 for ; Tue, 6 Oct 2026 16:53:35 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rInhLqT7a3aUCZE3utd5hC0h6XNFN6jRfaGx3te91PIyeN4mvQOpntzxZpbR/2ef2tq31eYHvNwipvRp1UGF/ZVyIvFwpOYpOoQV4MfV8oKwAKU24SK1h7vnwe4EOLT+VZWNfDJCWEKUkbntHznbDXoFMLgiyJdvXHpJ8vq/0RH5GdcMNN9FAJEZDlpX4zoVkA/PqTVoTvNjxjOA476PIBSACWVrNvtk6ZTRDR1/qE/jDUp83P8M3iJOftN7ow5MF8VLEkGl8Xaf5Ko7YL5J+DCFeiWSwGLdAOXR52Ymf2SgfnvG4+Uhit63DqOaSuSexmxDJIkp0mkT906X3xSd6g== 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=YyPT3BkshIxA7GltfeXViZQTvBDIGxSzTkvtT3c8G2g=; b=kK+bhvqO6u+DWyld7KfuombBUZDgv32/37tYohvrMyTxYj2Lufufr3nFEOUmg5Dvpt7pX2XmMyfMg3vmyi8903BlTudhr3wtZoOIjl9nb8uWcJX5DVs9bVfcL75pCM+dZF5dfeiNI1RP1r21jrzMahg9VtWQVeJxtmMna9pc79Hx6V/8qDMN71y3w2ubGD+ekGEbpTxqDOkrcj/dEL5P+MYEARkukLf98z7a3g+ae1OV+A+VszFMB6SfE+9JLaj5RCNVGSWOmBlSRQh+sKK6E5/QL8pH8ootVFbHH0kpb01jVv3aWDiC/oTRI5T5G8PZK3CI+nwL3riLrYbNeXvwlQ== 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=YyPT3BkshIxA7GltfeXViZQTvBDIGxSzTkvtT3c8G2g=; b=pV1PWDLOTu1jhQeq09zO9VCvr3hFhlGzEvWLGLs/oJxpLe/q/sFyPRRBvp5/u3/8jkGTy0pWAHm4s44Ah1OMl+Ddawh07NxKPmdfX8ljN0H12MGgJ1knivbnWvA5VgtunE1iNw5gGldxhKU51gc3yo3oNitYjvLQtE1IuI5Ie68= Received: from DUZPR01CA0349.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b8::14) by DB9PR08MB11364.eurprd08.prod.outlook.com (2603:10a6:10:60f::9) 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:53:32 +0000 Received: from MAD0EPF000008BF.eurprd04.prod.outlook.com (2603:10a6:10:4b8:cafe::28) by DUZPR01CA0349.outlook.office365.com (2603:10a6:10:4b8::14) 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:53:32 +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 MAD0EPF000008BF.mail.protection.outlook.com (10.167.241.168) 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:53:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791305611; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=FPLF3d8Pn3o8rcigzXfgAkWdRJ4jm+/9sYKEwVg0QcM=; b=FJMpkVt1mwhE6q5akxBH44aRWNkubL9OKxCW8iF7PgtxLZEwGA2S0avBUVsfjMKC tDSob83TG63+5WxbKDidPf15SbUcw5nFlvG7MWCa4tKLEJvDMB0Ih2GW9W4KXtCiTgS RzCbLdVgHA0ZqCC/Pargl7rLRrJOE9WE3btZebow0dcodF3cobNsqgFuzMz5hjzlBkX 7MTZgoxs/DyxWVN3sld0vvWn6vaeXYd8CWjKvKIUhtAj6CmCeUUz0/aUH9CualmwJen P+119Pou+hoptZQvvb599DDugI41nAcPDCBuoZk9xrA3LennKkX+herVpTb4HnSNeSQ aNmV/B5S3Q== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1791305611; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=FPLF3d8Pn3o8rcigzXfgAkWdRJ4jm+/9sYKEwVg0QcM=; b=EaM002As5xlqzFTovVX0ROldvGaFekVlX0Em61hCUfCsKMYBrOFZvosUPa0u6dUi U2i8Dh4SaaCcyv3n8Od4Vdeeb8ltUogBPdZKQudZxYn6fKUW+Ng5XLkcSucpuHyi6nB v+EBGNrpXkQphFxU0mqk3Bau9uYyngdt6UeGpDt0= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.0 v8 13/14] hcd-xhci: resync isochronous endpoints after CPR #VSTOR-137800 To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: den@openvz.org, andrey.drobyshev@virtuozzo.com In-Reply-To: <20261006-usb-host_v3-v8-13-72ae4fb8977b@virtuozzo.com> References: <20261006-usb-host_v3-v8-0-72ae4fb8977b@virtuozzo.com> <20261006-usb-host_v3-v8-13-72ae4fb8977b@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Oct 2026 16:53:30 +0000 Message-ID: <010701a1122276a6-8ce4d6a0-292d-4bf1-a23d-706b549512bf-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: MAD0EPF000008BF:EE_|DB9PR08MB11364:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a1d8480a-67bc-4718-ab95-08df23ca5a4f 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|9140799003|32142699015|48200799018|6133799003|4113699003|5113699003|16102099003|55112099003|22082099003|18002099003|10067099003|13003099007|4143699003|56012099006|5063699009|5023799004; X-Microsoft-Antispam-Message-Info: M2pfOjD62BmtUA7sQBzNS/g+yzzIhcH38JiJZs2yapXy+QgY6gIoUg73N4E2AaXn9X0RLk0N/LAYkAJYQiKRsJT7OouKGuuGNhoO7OotmXcLAKwuXxE0Uw3wO0ojoM3bkCY66X9zOlYtXMlZV8PP+lJuRZnVlHu6NwsTX2RlApE/10V3Mgc8rS13XnbDXhkAMT/aJj2nmiMf0j58uRfa6RlAfLmxGKnHNRSeL+OoabcyH6cRA3AjLUP3TV6B8ZhWPbDS1yDc4XY5mwTPHphnKUnaDYb72kTjdarhtxvgqBw5691KLCQQIdMRhXZJ224Qsk2uI0+8rRvbmMGMr27Y+HJ6bzAvk5jgp10WrKHIV7PEP7FtM5aFImWjNgzFL4frlY/UrJZAtx/iMTVEQP0nt65lVbpTnJYEkQUnCvTsXAZACfuuKFdVwnx7Aq4NO+LGoF1ieU539FQitzvhpmXz5YBFrAuDRrrKLxMS5AjJFvzyZVdtDQlZ6RnzbfebeX7XYzqQdt0MY1T0LzjVIRgxoUnfivz315/mzc6us9tMcWcbuOw1dypCDSEZ1bCGgt/wH0FMtdTRVeEolJhMzECyRcGXVN3OgnHMYwKJZU1kGBDmgzcYlb/Y/bjE5TDnvnpPH65SsXg50urExDltnQyGP1ZKUG/OzmYyTk5iYh6lTv0dUqWcglhRCWPgaRt03bPOqZ/mhMoke+U5ecc0NIYmGW6c3usCbqzlKbyVQ6ivc766sFQ4AgKh+y2NZpcT0S7l7e3nKEF6FB3syNLk+5PYcYvV48fgvftXV4eSSLDxtWV8ws6d5JVFk3Zo36C3WqGv 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)(9140799003)(32142699015)(48200799018)(6133799003)(4113699003)(5113699003)(16102099003)(55112099003)(22082099003)(18002099003)(10067099003)(13003099007)(4143699003)(56012099006)(5063699009)(5023799004);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: T1IGBkpS7Wz7JB7dt6q1/ko1iQm+AsNho734w+p7Xo+1KGJbHEb274LFesXTHZvNhNCgcdppocW/JNvTeTf3NUt6Cn/rv9dVF0PnemFXgheVKBU6AKgLy2f2GSEUMUhB67n2wqfpFk2Tkrjo3P8e6ZHQ3aqjihWFnVKtIZiI8r1mqmbuH7NmLxo00Ef1Givdl/PdyqY85R8bEyi/3ifV5hROAgVTpObmBvkKM2+ERBNlLbVMGQM1wMJQhgzWyNurd8eaAJSoo6Fdl9q4IAHRfl+I8AQ0qg2ZhGgqFm7erBO1vcz0vEjSS3q4wzgFbG7IJnsFRb9Qy12NKzeoCsmJi0LpL2dkftawc5cy2bzenu7A5D1pxrlVL8ueY5WJkDLBgpA+txMtzEqEe+E8ZVt3YYOW6aLoYWRx0cCyYnDjPde0fwu3XkxiL5CDqOlnxyh1 X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 16:53:31.4542 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a1d8480a-67bc-4718-ab95-08df23ca5a4f X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008BF.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB11364 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] usb-xhci: cpr_iso_resync flag is not consumed by an empty-ring k= ick and drops a later valid TD - [Medium] usb-xhci: CPR iso resync relies on a fabricated CC_MISSED_SERVIC= E_ERROR that only Linux guests may handle -- commit b3cbde381fc3538ebb617db181b3540f42917e1d Author: Andrey Drobyshev hcd-xhci: resync isochronous endpoints after CPR #VSTOR-137800 This patch sets a per-endpoint flag in usb_xhci_post_load() for running isochronous endpoints when CPR is incoming. The first isochronous TD that reaches xhci_submit() is then completed with CC_MISSED_SERVICE_ERROR instead of being sent to the device. The aim is to make the guest driver skip and resync. > diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c > --- a/hw/usb/hcd-xhci.c > +++ b/hw/usb/hcd-xhci.c [ ... ] > @@ -1047,6 +1049,11 @@ static void xhci_set_ep_state(XHCIState *xhci, XHC= IEPContext *epctx, > ctx[0] &=3D ~EP_STATE_MASK; > ctx[0] |=3D state; > =20 > + if (state !=3D EP_RUNNING) { > + /* a stop/reset before the first kick ends the post-CPR resync w= indow */ > + epctx->cpr_iso_resync =3D false; > + } > + [ ... ] > @@ -1811,6 +1818,19 @@ static int xhci_submit(XHCIState *xhci, XHCITransf= er *xfer, XHCIEPContext *epctx > xfer->pkts =3D 1; > xfer->iso_xfer =3D true; > xfer->timed_xfer =3D true; > + if (epctx->cpr_iso_resync) { > + /* > + * First iso TD after a CPR resume: our transfer state was > + * rebuilt from guest memory and no longer lines up with what > + * the guest consumed. Report a missed service, like real H= W, > + * to kick the driver's skip logic into resyncing. > + */ > + epctx->cpr_iso_resync =3D false; > + xfer->status =3D CC_MISSED_SERVICE_ERROR; > + xhci_xfer_report(xfer); > + xfer->complete =3D 1; > + return 0; > + } [Severity: Medium] Can a later, correctly ordered isochronous TD be dropped here? The comment in xhci_set_ep_state() says the resync window ends at the first kick. The code ends it only at the first isochronous submit or at the first non-running state change. The post-load kick runs xhci_kick_epctx(). That function can return without reaching xhci_submit(): - it returns on !xhci_slot_ok() - it returns on !ring->dequeue - it breaks out of the loop when xhci_ring_chain_length() <=3D 0, which for ET_ISO_OUT/ET_ISO_IN only reports CC_RING_OVERRUN or CC_RING_UNDERRUN xhci_kick_epctx() then calls xhci_set_ep_state(..., EP_RUNNING). The new clearing code only fires for state !=3D EP_RUNNING, so cpr_iso_resync stays set. The next isochronous TD the guest queues may arrive long after resume and be in sync. It would hit this block in xhci_submit(), never be sent to the device, and the guest would get a CC_MISSED_SERVICE_ERROR. For iso OUT this loses one chunk of data and makes the guest run its skip logic needlessly. Should cpr_iso_resync be cleared when the post-load kick finishes, rather than only on the first iso submit? [Severity: Medium] Does this approach depend on guest-specific handling of CC_MISSED_SERVICE_ERROR? The commit message says the error "arms the guest driver's skip logic". That matches Linux xhci-hcd behaviour (ep->skip). Nothing in the patch shows how other guests would handle this fabricated event. If a guest treats it as a hard error or ignores it, the endpoint could stay wedged, and the first TD's data is dropped anyway. > @@ -3510,6 +3530,11 @@ static int usb_xhci_post_load(void *opaque, int ve= rsion_id) > xhci_init_epctx(epctx, pctx, ep_ctx); > epctx->state =3D state; > if (state =3D=3D EP_RUNNING) { > + if (cpr_is_incoming() && > + (epctx->type =3D=3D ET_ISO_IN || epctx->type =3D=3D = ET_ISO_OUT)) { > + /* only iso streams need resyncing; see xhci_submit(= ) */ > + epctx->cpr_iso_resync =3D true; > + } Also, usb_xhci_post_load() rebuilds the same transient state, including mfindex_last via xhci_init_epctx(), for ordinary incoming migration. Only the cpr_is_incoming() case gets the resync here. Is the difference between CPR and regular incoming migration intentional? If so, could the commit message explain it? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261006-usb-= host_v3-v8-0-72ae4fb8977b@virtuozzo.com?part=3D13