问题
在 PR #1775 当前 head 004536f80 上运行 AArch64 Starry 定向 QEMU 时，内核在用户态启动前长期停在：
Initialized 6 tracepoints
kmod subsystem initialized
触发命令：
cargo xtask starry test qemu --arch aarch64 \
-c qemu/system/syscall-test-aspace-teardown-reclaim
首次正式运行在该位置 90 秒无新输出后主动停止。使用同一 kernel/rootfs 手工增加 -s 再次运行可稳定到达同一停点。
GDB 现场
三个次核都正常进入 ax-task idle：
CPU1-3:
__ax_task_0_7_wait_for_interrupt
-> ax_task::facade::idle_current_cpu_once
-> ax_runtime::task::bootstrap::run_idle
CPU0 不是丢失 wake，也不是停在 scheduler 锁上；它仍在同步初始化 USB host：
ax_plat::irq::dispatch_irq_on
-> __IrqIf_handle
-> ax_hal::irq::handle_irq
-> exception_vector_base
-> crab_usb::backend::kmod::xhci::hub::XhciRootHub::init::{closure}
-> crab_usb::backend::kmod::kcore::Core::init::{closure}
-> ax_task::executor::LocalExecutor::run_ready_batch
-> starry_kernel::task::future::block_on_with_abort
-> starry_kernel::pseudofs::usbfs::manager::initialize_hosts
-> starry_kernel::pseudofs::usbfs::new_usbfs
-> starry_kernel::entry::init
在 ax_plat::irq::dispatch_irq_on 断点读取 AArch64 参数：
x0 = 7 # IrqDomainId
x1 = 0x25 # hwirq 37
x2 = 0 # CPU0
另一次采样落在 virtio_drivers::transport::pci::PciTransport::ack_interrupt，表明 CPU0 持续进入 PCI/USB 相关 IRQ 路径，但 XhciRootHub::init 没有完成。
当前判断
建议后续工作
- 在
XhciRootHub::init 的状态机边界记录 command/event ring producer-consumer、interrupter mask、ERDP/EHB、pending event 数和 hwirq 37 ACK/EOI 次数。
- 检查 IRQ handler 是否只 publish 有界事件，以及初始化 future 是否在释放 controller/ring gate 后 park；避免 IRQ 与初始化线程互相等待同一 gate。
- 对照 Linux xHCI 的 interrupter enable、event-ring dequeue 和
xhci_handle_event() 顺序，构造可控 fake event-ring 的确定性红测。
- 将 USB host 初始化从 Starry 主启动路径的无期限同步
block_on 改为有明确完成/错误状态的 worker 生命周期；不能用轮询 fallback 或放宽调度安全边界规避。
- 修复后复跑四架构 Starry QEMU，尤其 AArch64
qemu/system，并验证 IRQ 无分配、无睡眠锁和 publish-before-signal。
完成条件
- AArch64 上能稳定复现旧实现的具体 xHCI 状态机停点；
- 同一确定性测试在修复后通过；
cargo xtask starry test qemu --arch aarch64 -c qemu/system/syscall-test-aspace-teardown-reclaim 能进入用户态并终止；- 修复不引入 polling 兼容路径，也不修改 ax-task 的正确性边界。
问题
在 PR #1775 当前 head
004536f80上运行 AArch64 Starry 定向 QEMU 时，内核在用户态启动前长期停在：触发命令：
cargo xtask starry test qemu --arch aarch64 \ -c qemu/system/syscall-test-aspace-teardown-reclaim首次正式运行在该位置 90 秒无新输出后主动停止。使用同一 kernel/rootfs 手工增加
-s再次运行可稳定到达同一停点。GDB 现场
三个次核都正常进入 ax-task idle：
CPU0 不是丢失 wake，也不是停在 scheduler 锁上；它仍在同步初始化 USB host：
在
ax_plat::irq::dispatch_irq_on断点读取 AArch64 参数：另一次采样落在
virtio_drivers::transport::pci::PciTransport::ack_interrupt，表明 CPU0 持续进入 PCI/USB 相关 IRQ 路径，但XhciRootHub::init没有完成。当前判断
do_exit执行，本停点尚未启动用户态，因此与该逻辑无直接调用关系。建议后续工作
XhciRootHub::init的状态机边界记录 command/event ring producer-consumer、interrupter mask、ERDP/EHB、pending event 数和 hwirq 37 ACK/EOI 次数。xhci_handle_event()顺序，构造可控 fake event-ring 的确定性红测。block_on改为有明确完成/错误状态的 worker 生命周期；不能用轮询 fallback 或放宽调度安全边界规避。qemu/system，并验证 IRQ 无分配、无睡眠锁和 publish-before-signal。完成条件
cargo xtask starry test qemu --arch aarch64 -c qemu/system/syscall-test-aspace-teardown-reclaim能进入用户态并终止；