fix(loongarch64): Fix Virtio using too much CPU

[weifenjihe]

Summary

Fix excessive VirtIO backend CPU usage on LoongArch64.

• Enable VirtIO wakeup IPI for LoongArch64.
• Use CPUINTC IRQ 4 (HWI2), matching the device tree.
• Prevent repeated wakeups and HWI update races.
• Allow hvisor-virtio to sleep in epoll_wait() when idle.

Tested by building hvisor, hvisor-tool, and hvisor.ko for LoongArch64.

[li041]

I made this follow-up change for two reasons:

1. GUEST_HWI_ASSERTED was already accessed under GUEST_HWI_LOCK on every path. Using AtomicU32 therefore did not provide any additional guarantee for the critical section, which must serialize the bitmap update together with the corresponding GINTC.VIP update.

2. The name sync_guest_irqs_unlocked was misleading. Although the helper itself did not acquire the lock, it could only be called while the caller was already holding the per-CPU lock. This precondition was not documented, making the locking contract easy to misunderstand.

The refactor replaces the atomic bitmap and separate lock with a per-CPU Mutex<u32>, and keeps the bitmap update and GINTC.VIP synchronization in the same critical section. There is no intended behavior change.

[li041]

Thanks for the contribution!

This PR improves LoongArch VirtIO interrupt handling by addressing excessive CPU usage, aligning the LS3A5000 VirtIO IRQ configuration, and moving guest HWI synchronization to per-CPU locking. These changes make interrupt delivery more accurate and reduce unnecessary cross-CPU contention.

Appreciate the work on this!

[weifenjihe]

I made this follow-up change for two reasons:

1. GUEST_HWI_ASSERTED was already accessed under GUEST_HWI_LOCK on every path. Using AtomicU32 therefore did not provide any additional guarantee for the critical section, which must serialize the bitmap update together with the corresponding GINTC.VIP update.
2. The name sync_guest_irqs_unlocked was misleading. Although the helper itself did not acquire the lock, it could only be called while the caller was already holding the per-CPU lock. This precondition was not documented, making the locking contract easy to misunderstand.

The refactor replaces the atomic bitmap and separate lock with a per-CPU Mutex<u32>, and keeps the bitmap update and GINTC.VIP synchronization in the same critical section. There is no intended behavior change.

Thanks for the explanation. I reviewed the refactor, and it matches the original intent. Combining the guest HWI bitmap with the per-CPU mutex makes the locking contract clearer while preserving the existing local synchronization and remote IPI behavior.