From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a110dcb4ca-2df721c4-58ba-41f5-a335-1f00a5a78ec4-000000@eu-central-1.amazonses.com> Received: from AS8PR04CU009.outbound.protection.outlook.com (mail-westeuropeazon11021140.outbound.protection.outlook.com [52.101.70.140]) by lore.virtuozzo.com (Postfix) with ESMTPS id 59F398017D for ; Tue, 6 Oct 2026 10:57:50 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UG3SafEtvHXPbF6WmYQVe9XXGH08pwsRIFq8M/XssvES4PVafZ67T2LKtcQUJ+1/hokiIZc2k15aa6UlVWXLTIUWjRt6Zlpii5Cb/iOaRJQ6BNufJBvOLtyvssWAnsgtnuPdbWdMesIT4HQeCS/9Cr/bQomhhEyZjB8xwVFQzzoveAuDb+EV6jb/rUdNWfFx0bWtc7JgKF6EC2KvQLMkdSx0EzXe9hgSgThszzt9iorcjfyX155x2SQa1B7QD91XGIpqFZaIZb9Cr3Mu7/MGUjzVyLoRWah9Rfrj3EcAWkDzCwBYRFfjKdEmesvm/SEe7rjD1fIHAop13JQTDeGGaQ== 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=Y9EzU1bqBjYmCIsSRxPtGXpTMg6XC0DzWMqsA5rqOJQ=; b=siOMvid57F+rGzPiqyZMDAd1R4ezw2vAO5FSD//WYrgx+0hY7M9cvbS8EeIrPU1RuzmnRmcniBcXwjyoTZTI7N2JXMlp3J0wbiwCpgm1XJnChmSMrOImVP4ErFNOyN5wVHuE8Tj1hxweTSPw+fCIex3Rh4cgzbWmK5z7Hx4MiMx8wn5ehyNhi658yOua472zsx2YCwuqPLkfULCFo/8UUOSbl6kla8sYCpeKfBD+v1kwZS8SoAGTXYoIFuGKk7M1nx1uKkpb4EzhGmfNL5pYFil+LJJSuW45hDfs7eqLuz2lVmmCXWS5w+x5/w/ouHYr1Z+GzW855tYMdhcKrspapQ== 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=Y9EzU1bqBjYmCIsSRxPtGXpTMg6XC0DzWMqsA5rqOJQ=; b=jLCCvzAVO4Sn/fTQ2wjn1fdEvH2pZxlY1FrQx7tOA7+97298y8trf9dOKGL4MmSck47jwTY3xzcWnSTEAALVdZv6BFnMgLg/kpyJKx8sKP3vcHmP+RKthDFA2hWzAvh4gOQAFYtl1UzrNqVh6+aDhK4N543aNgpgnlqHYW5qRKQ= Received: from LO4P265CA0248.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:350::8) by PAWPR08MB11039.eurprd08.prod.outlook.com (2603:10a6:102:46c::11) 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 10:57:43 +0000 Received: from MI3PEPF00008494.eurprd03.prod.outlook.com (2603:10a6:600:350:cafe::53) by LO4P265CA0248.outlook.office365.com (2603:10a6:600:350::8) 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 10:57:42 +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 MI3PEPF00008494.mail.protection.outlook.com (10.167.240.155) 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 10:57:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791284262; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=FEjOwJVgQAhv0bgnz39oNSbYE73h4Je0w4D/+YRq1VQ=; b=NSHy+ILBoh+D/KX6bsgf/NMgmmHJCNDUKuYMNnifQjcyQspAejKzoPQBc+hNQMkI bbaXz3lhr6pYvpXyLkEU/of/SaWjwOhJ/ZbPmwQHiUk8hui+ssW30/w9B63dl70lFy1 OkGXnx9FDhplVX03C7Hx5X4BFdfnUWjnvtYUU/u7S9BPL4h4OK+PgHuips5uVf3sHEa ptmsA/IoW4Ie7yYIqXaew6Szk/sH9vOkZt6ncZUeSI9Qm3le600IAJpXJrrctSKv+Ug jzoiQBeoEhwMiV60t8iIoDs/558A31vMr1ZU4kt7CNDEE4nj2zgBhPsx/ITMx9/WlCi kqy/PM2dng== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1791284262; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=FEjOwJVgQAhv0bgnz39oNSbYE73h4Je0w4D/+YRq1VQ=; b=NEHoUdkulqSLvHlIyFhyJGUmvRR3UmlMhIeq1BVGr+Lo+ESWSJ4dvedSUxMZaNm1 sxAjkZ9OgClWZf/nqmECup2/EdfECYJg/7ITsr6FW4uXY1+3TAxqdW+m8aYU1qQmolz aChA9Z/RTPRTQUxCsepHsr0mofVuwUiMWx0ly7lU= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.0 v6 11/12] hcd-xhci: resync isochronous endpoints after CPR #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-11-8688ec9576d1@virtuozzo.com> References: <20261006-usb-host_v3-v6-0-8688ec9576d1@virtuozzo.com> <20261006-usb-host_v3-v6-11-8688ec9576d1@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Oct 2026 10:57:42 +0000 Message-ID: <010701a110dcb4ca-2df721c4-58ba-41f5-a335-1f00a5a78ec4-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: MI3PEPF00008494:EE_|PAWPR08MB11039:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c5aacafd-8900-4f75-f37b-08df2398a546 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|32142699015|9140799003|48200799018|61400799027|376014|5063699009|4143699003|56012099006|10067099003|16102099003|55112099003|22082099003|18002099003|5113699003|4113699003|6133799003|13003099007; X-Microsoft-Antispam-Message-Info: 4VD0a56q3w/ewzb73DtCPY3eIPgP7/53Yh30VeYIXaitg0Hgt8mrl34iL0Y9ifSv/Hvd9zoz0+T/H2C3L0iyYrt5sTygoVO8wJEOLKdyCMm1abnjYvBmDjbfWQ99ScczAS8nyM+CBhzkKAyHDfHCqZ6hqvlYpX0M+uG32RoqaRbChZyWDzfymzHnA634kL4kIwsjl0OHRpssz6Z0+e16/SAqaI98IwxSffPQBCF6SXyCXaSrRe3A8VTJOzyOGhAykAPp6XFdszPNHLkH949A4fDX4ss3gW5ItwXdTL1JGLkZPQMpIdzQ30Yqa783R1yuO4TY34Xl/ArizKnEsC/0Dfx9SSceKJHodAPgbWZyT8gDHVMbLu2c2AJG/LIg2rfC3Sz8I6KIrxZnLodcTXJDk2ZWUhqGWKmuBodxPpCLNxFUApQNnNbrjF/eAm00ufAo/ymZigozR9bPcl8bxIUk/sr+RNpCGFWk7dS5iYutEZVfiYHYqKXneYZUZMrQ7K7QiGwmRv7Xx0qAhp4LVBZMwX6myy9HvuDQfVDdJfpYcdInFOR3POqylwBYOeuYbDHmdTxdRGpEYkPYcnlwLOwZedtKd1XxM7ZGNAp/CWaoNasEyctjFkBlAiXg7iOZkku/rXOTgOy2+EvO69YrJdXcc1PmS8PHylySfWwbbyQItp1peKo8JYbHONt2fHagw9aPR5bFFmGZJNGJz9oKlmrrA/YvCz96gKM2QoQRmeFlsy1jjYtI2GO3ZPC1G9Qo8NFxjRBH+p6WNJEoeITnNCge2MW1gJoXqWef8AXKDTaSwl0h9D8GXSpxe74f8xrQWdPJ5pv+hPFXbZ7U5uyowPfAFjqOu7bbk08F5e8Nmz7Fy+U= 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)(9140799003)(48200799018)(61400799027)(376014)(5063699009)(4143699003)(56012099006)(10067099003)(16102099003)(55112099003)(22082099003)(18002099003)(5113699003)(4113699003)(6133799003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: f+32zT8ZBe2/e/tUNCw78IqlhfktWdnIzAA6fJcp6wZ1fwT4OqBUTxiK7JDVNAYeq01cccY45hku2PHMn0PlCOlYYZ5rv/0iUc29j8Cp2PaVrXwDCHWm4PgeDVSOmW+LLoBemofE2FDAFekvmOo5r0GL2tOvRUhjGT2FlshJHtB6mZA3J2w+bGBGkmOXNRvfm9bFPyMtaYPRMjDHZJybLosFU7r2Uj/fLzkzLv51KBRbh4bsQlcgNZqwAoAOPVm/8i/cGpecC5NXb9HmZ0gw/HsFthCu0VInpJUrGxY+k5Zwvd+Pkxig9NU4n2ICK6FrCv9hP4eXRrxrSiwElTk3h9zx3nCGtw+BDgGnUPQGYxK5ax9Ua4LPNLv3uyHkdfMh/KCnnU8/FVogEY7g4gMlHfUi0q2//T/PE51RpvYw/IEfNMl73DwozYIcdUa07RqB X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2026 10:57:42.4122 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c5aacafd-8900-4f75-f37b-08df2398a546 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF00008494.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB11039 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] usb-xhci: CPR iso resync fakes a missed-service error and drops = the TD without fixing iso state - [Low] usb-xhci: cpr_iso_resync flag is never cleared on idle, stop or res= et, so a later in-sync iso TD is dropped -- commit ff20d366f72942427c2474f20e5f7aa84692f640 Author: Andrey Drobyshev hcd-xhci: resync isochronous endpoints after CPR #VSTOR-137800 This patch adds a cpr_iso_resync flag to XHCIEPContext. usb_xhci_post_load(= ) sets it for running isochronous endpoints when CPR is incoming. The next = isochronous TD submitted through xhci_submit() is then completed with CC_MI= SSED_SERVICE_ERROR without being sent to the device. The aim is to make the= guest driver resync after resume. > 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 [ ... ] > @@ -1811,6 +1813,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 this early return leave the isochronous scheduling state unrebuilt? The branch returns before xhci_calc_iso_kick() and xhci_check_intr_iso_kick(), and before xhci_setup_packet() and usb_handle_packet(). So epctx->mfindex_last is not updated for the dropped TD and stays at its initial zero value. The TD is also never passed to the device. An ISO OUT frame is lost, and an ISO IN buffer is never filled. Does the resync then depend entirely on the guest driver reacting to CC_MISSED_SERVICE_ERROR? The commit message only describes the Linux behaviour. Would other guests handle the synthetic error the same way? [Severity: Low] Can the flag stay set for longer than "the first isochronous transfer after a CPR resume"? The flag is consumed only here in xhci_submit(), on whichever isochronous TD is submitted next. Consider xhci_kick_epctx(): 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 event } break; } If the ring is empty at resume time, the loop breaks before xhci_submit(). The same happens if xhci_slot_ok() fails or the endpoint is halted. The flag then survives the resume kick. The stop, reset and set-dequeue paths do not clear it either. Can a later isochronous TD that is already in sync then be dropped with a spurious CC_MISSED_SERVICE_ERROR? [ ... ] > @@ -3510,6 +3525,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; > + } [Severity: Medium] Why is the resync restricted to cpr_is_incoming()? usb_xhci_post_load() rebuilds the endpoint contexts through xhci_alloc_epctx() and xhci_init_epctx() in the same way for ordinary live migration. The commit message says that "we rebuild the controller's transient transfer and scheduling state out of guest memory" across CPR. A normal-migration destination gets the same rebuilt state but no resync. Could the commit message explain why only CPR is affected? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261006-usb-= host_v3-v6-0-8688ec9576d1@virtuozzo.com?part=3D11