From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazon11022104.outbound.protection.outlook.com [52.101.66.104]) by lore.virtuozzo.com (Postfix) with ESMTPS id 6486E802A5 for ; Tue, 6 Oct 2026 15:56:45 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=O1dQgRZIIyae41ePOASpaOyPSo5e3ZOqKFYPMHS7okIO+EMvVqRp5TsC7I+1rpJ61UmEi0i10MCBwBqlOmbxvhI/gjPdhV3ID0WvJA0IfZr2k5sv71AgEFoir7qoXSs1hBl1+4U6cQTgM88k1A1Psplfak6z44VqOuUDOQ+fonKrzL9rA9wBjvCFDsbpK4/v/WDN7PbyE1EIGfqW9Cy95brnIPrwM8GsAtxh6K50nWAjduI7kvngsZd6dr4kcSAQ84J6PK31MgETQM6pZNJBOPW6oFo4tSGN41TW4dKb0BcIJ/IbSJ2D42umsT5JBj7b4REUhWMoNpQ06+O4OfknUA== 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=aQCamLP3BawJwxP7I6KVLJ91mQ2ppvoFHWlpwBtf0hI=; b=Jvo6kE5YjemQwPPHskRm/3R48wPkP3YDTZgZU/Z/HyqSnbk8BimTZi4txRfJtI3/lfKEBNDqwpsjCccPb7vBAGpBdNVBvKUve9oKxxmMvQeUnHo68u5dQNe3zqgvJIfqV/Lg5hCOt8FBY9VloEUKggcKqcgoF0Oa49cgDi8hfc6sNw0yp/rZ1ggiY1PICPzDWnR0YUecQrFORMXh9X/1hAcDUdEBCalwecmHbDia4RU7AlgT8iFf3eG8HmiUlM427bcPDvpCyueRUw59L5BJaiYBTOw7k8Xr8MNYZBIO2WvQUtA8/H46LPifot2rOxdYE5LX3RcWQGuo3PI2LwHU8A== 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=aQCamLP3BawJwxP7I6KVLJ91mQ2ppvoFHWlpwBtf0hI=; b=av6kNB5aa3qlO9pWHcpgwYOEOC02kT7YOg+XXW0yVZwPsWCp4tAbnpGYUHWzf7jRqq7hfnMH6lGkiPTqsjuGsg7peZKUWJe6EUP4b5pkbHt87BrbqlU7jC3wKz4ZcquY3P6tnLDFZUNS6q1WYwTbyassPk9MIUkijSam1WiO2ak= Received: from DU6P191CA0057.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:53e::15) by PAVPR08MB8800.eurprd08.prod.outlook.com (2603:10a6:102:2fc::6) 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 15:56:38 +0000 Received: from DU6PEPF0000A7E1.eurprd02.prod.outlook.com (2603:10a6:10:53e:cafe::60) by DU6P191CA0057.outlook.office365.com (2603:10a6:10:53e::15) 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 15:56:38 +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 DU6PEPF0000A7E1.mail.protection.outlook.com (10.167.8.40) 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 15:56:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791302197; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=yMogQSZ9S6t/IgPyoZy59wCYKxe2FzeseHkUzWgFk1g=; b=IZMbL2KX76lc5BJet2VE+GLh0y3Uwf67G6Co8Y7OIDDUEUUk5zxcjENlQde5SzMP p42lmRPhF2zhRL47k/TA9tmWws01/EEuTmx8pcqf2Sxy83QppigBk8WU7+pmdbuzApI K8A9DSVegvPTCT/zc/Q7MGbkWyf2WVAVsvJduyckC2azww8DK4lgS7JBc9eorHckBUi bdbRr+xPCLgjOeELrWTG22EsYyqkvd+s0srp1GZ1bVedJpKbWsla/YB6BoDyb34AG5W v/3WpstqYIxezvmBQVoKuTNbV7x2Vqy2yeYeUCwXztQGqyYe9r5wtOd3QVXxSHhR6kb l99OPbRlfw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1791302197; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=yMogQSZ9S6t/IgPyoZy59wCYKxe2FzeseHkUzWgFk1g=; b=i5U9R0NFCydnEWEswhC3YzIhILygbqiiZgWU/sKwM27ghu1M1bp/dKkrlxW5poYJ e5wIovWhq/K5QLEx19AAwsR1MPLX97iiK6tpWylwlt/ZoMMChc38fz2iGb8LMnM3UEa v9ojVtoZji1E9KLcaCmava6dJlv0WF3YAksMVHLk= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.0 v7 13/14] hcd-xhci: resync isochronous endpoints after CPR #VSTOR-137800 To: Andrey Drobyshev , svt-core@virtuozzo.com Cc: den@openvz.org, andrey.drobyshev@virtuozzo.com In-Reply-To: <20261006-usb-host_v3-v7-13-044f668789a1@virtuozzo.com> References: <20261006-usb-host_v3-v7-0-044f668789a1@virtuozzo.com> <20261006-usb-host_v3-v7-13-044f668789a1@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Oct 2026 15:56:37 +0000 Message-ID: <010701a111ee60bc-99f119c5-6eac-48fd-822a-2ef85eefc6d5-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: DU6PEPF0000A7E1:EE_|PAVPR08MB8800:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 27ffd781-9ad2-4d25-0e32-08df23c267bc 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|704161411799003|32142699015|61400799027|9140799003|48200799018|376014|56012099006|5063699009|4143699003|10067099003|22082099003|18002099003|55112099003|16102099003|6133799003|5113699003|4113699003|13003099007; X-Microsoft-Antispam-Message-Info: zPGuKW8TooMN10Azl41RHkX4NFTKPu1AeCksRlEofaTXOvBpw5Qf35GZfzvdPsNGe5446ihPnw2y3GHBUpFTg0f1SNekbeJf4JiA3H5ROzqOdFgtexDF7J2trskpW9VmfHZUWW+kRId/3UxfEoxA+Jbr/A8/lK2Qc8ZDvH1ZsD8yeq3M7s9nEuTt19E3j/pZOU+9XlpeUbyYo4DsUnFDY3wcKHVAUy4yG/AD+2TdN5t5PxXl8cLNFr9o6j3Ecw0ZHPD2eNzKohuXPz6Q8YBIStNAwT/z0vr20yTCeBdeLo/ToVsKtd6GxW0E+/n6WK+QOPjSlPOBa+o7HQAEK7R/oWIeyu9G9hrHsULU9UxlzrFqc6pl53ws2z/W6/RNz/SulQUX66yRE0BPF7sa/zmj81plmi3hJRFoJCIoma/m4vOrv5GDVTmpeSsB7mp+fOfNPPdBIro6tRysQRUzuVJ5NB/Vu5JRGhBPSaXr7HHuS/dVtkMfZzNmfFgwc47bs41dlLbP8YXl/Be3g+HaGTFthsgSwj0ygpMjXFZEkXos+WAgiaw37rqX7+xee9M9+e8VZ8yJIvqvE7unPu3A5ZQhKZZ1Up7p+lnDyNLP2m7YBQe/HFKPFkdHGTZc/GvS28H2xOeaJA8Kztloys3gCe8yRtzgxPzIxcmnvy1i3Tchnspa6MDc7VhCn9SnE2ypZPRxwc3K6okyHd9/mmMiwUWfyu97XEWTDFgl81MaEfBENBboxFHiS1SNzoR5UMRNGKXYM6zckZV+UgHHuQ480UJ2rUp3770OwJZYTT8qI5VPLzj1VFouCgZzu9rh/NDaoZhC 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)(32142699015)(61400799027)(9140799003)(48200799018)(376014)(56012099006)(5063699009)(4143699003)(10067099003)(22082099003)(18002099003)(55112099003)(16102099003)(6133799003)(5113699003)(4113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: wU4+WI8mHxObdm7arYU9ZgcOkmisY6lYS3yM7nd5TpYInSbR1BvKYqgUI51L+oTGyYNdFgfMW35K4SlCWtAMiSjaUrTCTLczk1zSfFT//XGjeqbWe+IE/aQDYIXKp3Iphu6oJKQyPedTOYjDpZx5OVhcqVhTQr7m9901vgLvOGeIW2q7mZ28tta+GqgkpaNHcyMj9ahBZJIUVhoLwDEflNUlaZ0zwjQSFWbub0K57Q/Gk4OPljM7c8co+aUqBzIGO6z0VfW6yVE20CsQFQe+x8YlPqAT1J8NwF0xqabXLT0fR6rORuBqeJzVLz8rz1lUl+sp1aEh3XqB8z6oJm9FeDrTz5fAUhGjdgMoynS2Ecg/yCDLzTb9Rh0W/9lWn/NoxpS6BQemBjVkbmXtfuoqPWYUYQWDDBMJYg00bYRAIew2fUfZ4LsS85YBAArXPq4x 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:56:38.0039 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 27ffd781-9ad2-4d25-0e32-08df23c267bc X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: DU6PEPF0000A7E1.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB8800 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] usb-xhci: cpr_iso_resync flag stays armed if post-CPR kick submi= ts no ISO TD - [Medium] usb-xhci: CPR iso desync worked around with fake missed-service = error -- commit 775b0f619a3e5117de7a9bf189a6e7024d14f114 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 a CPR resume is incoming. The next isochronous TD seen by 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 ahead 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; > + } > + [Severity: Medium] Can cpr_iso_resync stay armed after the post-CPR kick? usb_xhci_post_load() sets the flag for every EP_RUNNING isochronous endpoint, without checking whether a TD is pending, and then arms kick_timer. The kick reaches xhci_kick_epctx(), which calls xhci_set_ep_state(..., EP_RUNNING). The clear above only runs when state !=3D EP_RUNNING, so the flag survives. xhci_kick_epctx() can also leave without calling xhci_submit(). It returns early when xhci_slot_ok() fails, when the endpoint is halted, or when !ring->dequeue. It breaks out of the loop when xhci_ring_chain_length() <=3D 0: length =3D xhci_ring_chain_length(xhci, ring); if (length <=3D 0) { if (epctx->type =3D=3D ET_ISO_OUT || epctx->type =3D=3D ET_ISO_IN) { ... CC_RING_OVERRUN : CC_RING_UNDERRUN; } break; } It also breaks out when xhci_ep_alloc_xfer() returns NULL. None of these paths clear the flag. If the guest queues an isochronous TD later, long after resume, will that TD hit the resync branch in xhci_submit()? It would then be completed with CC_MISSED_SERVICE_ERROR and never sent to the device. This differs from the comment and the commit message, which describe the window as the "first kick" or the "first isochronous transfer after a CPR resume". As written, the window ends at the first isochronous TD submitted, however late it arrives. An isochronous endpoint that is EP_RUNNING but idle across CPR, for example an opened USB audio device with no TDs queued yet, would lose one valid TD this way. Should the flag be cleared at the end of the post-CPR kick, whether or not a TD was submitted? [ ... ] > @@ -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] Is a fabricated CC_MISSED_SERVICE_ERROR the right way to handle this? In xhci_submit(), the first isochronous TD per endpoint is completed with an error and never sent to the device. For ISO IN the data is lost, and for ISO OUT the data is never sent. Recovery depends on the guest driver's skip logic. The commit message describes Linux behaviour. Will other guests such as Windows or BSD resync from a Missed Service event? That is not established by the patch. The commit message says the controller's "transient transfer and scheduling state" no longer matches what the guest consumed, but it does not say which state diverges. It also does not say why the dequeue pointer in the endpoint context is insufficient. In usb_xhci_post_load(), the endpoint is rebuilt only through xhci_alloc_epctx() and xhci_init_epctx(): xhci_init_epctx(epctx, pctx, ep_ctx); epctx->state =3D state; After this, mfindex_last is 0 and the transfer list is empty. Could restoring or re-deriving that scheduling state be a better fix than discarding the TD? [ ... ] > @@ -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; > + } > /* kick endpoint after vmload is finished */ > timer_mod(epctx->kick_timer, qemu_clock_get_ns(QEMU_CLOC= K_VIRTUAL)); > } --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261006-usb-= host_v3-v7-0-044f668789a1@virtuozzo.com?part=3D13