Re: [PATCH QEMU HCI-8.0 v5 00/13] usb-host: support CPR migration

["Denis V. Lunev" <den@virtuozzo.com>]

On 9/25/26 16:11, Andrey Drobyshev wrote:
> v4 -> v5:
>
>   * Patch 5: deliver URBs that already completed in the kernel instead
>     of dropping their data, and error out any a drain can't reap in
>     time;
>
>   * Patch 6 (NEW): drain each usb-host before its host controller is
>     migrated, so a shared-context completion can't advance xHCI after
>     it was saved;
>
>   * Patch 7: remember the packets to replay from the reap callback, so
>     only the genuinely in-flight ones are re-issued.
>
> v4: http://lore.virtuozzo.com/qemu/20260924-usb-host_v3-v4-0-1cc48bf630e7@virtuozzo.com
>
> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> ---
> Andrey Drobyshev (13):
>       usb-host: don't leak hostdev FD on open failure #VSTOR-137800
>       usb-host: add migration blocker for CPR modes #VSTOR-137800
>       usb-host: preserve hostdev FD during CPR migration #VSTOR-137800
>       usb-host: factor out usb_host_reap_xfers() #VSTOR-137800
>       usb-host: drain in-flight URBs across CPR #VSTOR-137800
>       usb-host: drain before the host controller is migrated #VSTOR-137800
>       usb-host: re-issue drained URBs if CPR is aborted #VSTOR-137800
>       usb-host: skip product-string read on CPR incoming #VSTOR-137800
>       usb-host: hand off the device across cpr-transfer #VSTOR-137800
>       usb: migrate the interface altsetting #VSTOR-137800
>       usb-host: reconfigure endpoints on CPR incoming #VSTOR-137800
>       hcd-xhci: resync isochronous endpoints after CPR #VSTOR-137800
>       usb-host: make CPR migration blocker conditional #VSTOR-137800
>
>  hw/usb/bus.c                |  36 ++++
>  hw/usb/hcd-xhci.c           |  20 ++
>  hw/usb/host-libusb.c        | 512 ++++++++++++++++++++++++++++++++++++++++----
>  include/migration/vmstate.h |   1 +
>  4 files changed, 530 insertions(+), 39 deletions(-)
> ---
> base-commit: f2f4b3de1a1be3360a77ca6ab79762466d238804
> change-id: 20260914-usb-host_v3-bbfea86d1dad
>
> Best regards,
> --  
> Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
  What v5 fixes from v4:
  - Draining now happens before the xHCI controller's state is saved
(new patch 6).
  - Transfers that already finished in the kernel are delivered to the
guest instead of dropped.
  - If migration fails, only the transfers that were really cancelled
are sent again, so none go to the device
    twice.

  Blocking:
  1. The guest can lose an interrupt and USB stops working on the
target. The CPU state, including the KVM
     interrupt controller, is saved (migration/savevm.c:1668) before
usb_host_pre_save() drains. Any transfer
     completed during the drain makes xHCI send an MSI
(message-signalled interrupt) after that snapshot, so the
     new process never sees it. The saved xHCI state still has ERDP_EHB
set, so xhci_intr_raise() sends no more
     interrupts until the guest writes ERDP, which it only does from the
handler that never runs. That kills the
     whole interrupter, not just delays one event. v5 makes this more
likely than v4, because it now delivers
     completed transfers during the drain.
  2. A transfer cancelled halfway is re-run from the start. For a bulk
IN transfer, the bytes already read from
     the device are lost. For bulk OUT, bytes the device already
accepted are sent again. This is the normal case
     whenever the VM stops under I/O. The fix is to deliver a cancelled
transfer that has actual_length != 0 as a
     short transfer, and replay only the ones that moved no data.

  Proposed direction: drain from a VM state change handler when the VM
enters FINISH_MIGRATE in a CPR mode, and
  re-issue from the handler that runs when the VM starts again. That
runs before the CPU state is saved, which
  fixes item 1 and makes patch 6 unnecessary. It also closes the window
from the v2 review where vm_start() runs
  before the failure notifier. That window now has a second problem:
with pipelined bulk endpoints, newer OUT data
  can reach the device before the re-issued older data. I left one
question open for Andrey: a VM already paused
  before migration starts never gets that handler call, so it still
needs some fallback.