usb-host: isochronous passthrough degrades after ~6.2 days of VM uptime (suspected 32-bit microframe counter wrap) — guest softirq saturation, affects UHCI and xHCI

Description

A VM with a USB audio device passed through via usb-host and a continuously running isochronous stream degrades severely at almost exactly 6.2–6.9 days of VM uptime: the cost of servicing each isochronous transfer completion in the guest explodes, saturating one guest core in softirq context. The onset time is consistent with a 32-bit microframe counter wrap: 2^32 × 125 µs = 536,871 s ≈ 6.21 days.

Environment

  • Host: Proxmox VE 9.1.9, AMD Ryzen 7 7800X3D
  • QEMU: QEMU emulator version 10.1.2 (pve-qemu-kvm_10.1.2-7)
  • Machine type: pc (i440fx), cpu: host, 2 vCPUs
  • Guest: Home Assistant OS 17.3 (Linux 6.12.85)
  • USB device: C-Media USB audio (0d8c:013c), usb-host passthrough
  • The guest's PulseAudio keeps capture+playback streams running continuously (~1000 isochronous packets/sec) from boot — see cross-referenced issue below

Symptoms

  • For the first ~6.2 days: ~950–1000 HI softirqs/sec in the guest (isochronous URB completions), negligible CPU cost. Guest CPU ~11%.
  • At ~6.2–6.9 days uptime: guest CPU0 saturates at 100% in softirq (52% sirq of 2 vCPUs in top). Audio stutters. The HI softirq rate drops to ~425/s (consumer saturated) while each completion becomes drastically more expensive.
  • Reproduced twice at the same uptime with matching cumulative HI counts (~568M), once on emulated UHCI (default USB controller) and once on qemu-xhci (usb3=1) — so the defect appears to be in a layer shared by both controller models, presumably the usb-host/isochronous scheduling path.

Key isolation facts

  • Unbinding/rebinding the USB device in the guest does NOT clear the degraded state — freshly started streams are immediately expensive again.
  • Unbinding/rebinding the host controller PCI device in the guest (/sys/bus/pci/drivers/xhci_hcd/unbind + bind) fully clears it: back to ~1000 completions/sec at ~0% CPU.
  • A VM reboot also clears it. Host uptime is irrelevant (host had weeks of uptime across both events; the trigger tracks VM uptime).

Reproduction

  1. Pass a USB audio device through to a Linux guest with usb-host.
  2. Keep an isochronous stream running continuously (e.g., PulseAudio without module-suspend-on-idle, or a looped arecord/aplay).
  3. Wait ~6.2 days of VM uptime.
  4. Observe guest /proc/softirqs HI counter rate and top sirq%.

Real-world impact

Home Assistant OS on Proxmox with a USB DAC is a very common home-automation setup; HAOS's PulseAudio keeps device streams open 24/7, so affected users hit a guaranteed "VM needs reboot every 6 days" failure that is very hard to diagnose. Cross-reference: https://github.com/home-assistant/plugin-audio/issues/222