fix(loongarch64): repair IRQ delivery and SMP zone startup - #365
Conversation
Keep per-CPU events in a FIFO and coalesce physical IPI doorbells so queued work is not discarded. Align guest wakeup with the smp-la VcpuState lifecycle.
Merge guest IPI action bits, publish blocking sends before return, and keep the virtual IPI line asserted until all pending actions are cleared.
Maintain asserted HWI bits per physical CPU, update only GINTC.VIP, preserve PIP and HC, and remove timer-driven global injection cleanup.
Route the clear-inject hypercall through zone and IRQ arguments so concurrent guest HWI lines are not cleared together.
Use the LoongArch split-offset mapping consistently for device discovery and direct MMIO access. Perform sub-dword configuration accesses through aligned 32-bit read-modify-write operations, and retain each bridge own configuration base for later bridge control updates. Co-authored-by: ZhongkaiXu <3605832858@qq.com>
Configure the supported system page size, reset and latch VF routing fields, and enable upstream ARI forwarding before exposing VFs. Use the actual routed VF count and avoid creating disabled VFs. Co-authored-by: ZhongkaiXu <3605832858@qq.com>
|
This draft PR is intended only as a temporary reference and for validation. It is not intended to be merged in its current form. The related changes will be split into multiple focused PRs and submitted separately for review. |
|
I noticed that you seem to be using only 4 cores during SMP debugging. If so, board-level configurations and CPU-related code will need to be modified. |
|
During testing, I triggered the following error. On the surface, it appears to be a page fault occurring on a secondary core; however, this issue has only been observed once so far. [ERROR 5] (hvisor::panic:24) panic occurred: PanicInfo { |
Thanks for the report! I appreciate you bringing this up. |
|
Thanks for the feedback!
The board-level configuration and CPU-related code need to be adjusted when using a different number of cores. The corresponding SDK and JSON configuration files also need to be updated accordingly. The configuration details can be found in the hvisor doc.
For the guest Linux VM restart issue after shutdown, I will investigate it further, especially the interrupt cleanup and timer-related parts. Thanks for pointing this out. |
| pub fn cpu_start(cpuid: usize, start_addr: usize, opaque: usize) { | ||
| let start_addr = start_addr & 0x0000_ffff_ffff_ffff; | ||
| let ipi: &MMIODerefWrapper<IpiRegisters> = match cpuid { | ||
| 1 => &CORE1_IPI, | ||
| 2 => &CORE2_IPI, | ||
| 3 => &CORE3_IPI, | ||
| _ => { | ||
| panic!("loongarch64: cpu_start: invalid cpuid={}", cpuid); | ||
| } | ||
| }; | ||
| ipi.ipi_enable.write(IpiEnable::IPIENABLE.val(0xffffffff)); | ||
| let entry_addr = start_addr; | ||
| mail_send(entry_addr, cpuid, 0); | ||
| ipi_write_action(cpuid, SMP_BOOT_CPU); | ||
| } |
There was a problem hiding this comment.
This implementation currently hardcodes IPIs for cores 1–3, which limits SMP support to exactly 4 cores and doesn't scale with CONFIG_NR_CPUS.
Additionally, the _ => panic!() clause makes the function brittle.
There was a problem hiding this comment.
Thanks for catching this issue. The hardcoded IPI mapping problem and the limitation to only 4 cores have already been fixed in #368.
The new implementation supports scalable SMP startup based on the configured CPU count. Thanks again for the helpful review.
3 participants
Summary
Validation
make ARCH=loongarch64 BOARD=ls3a6000 MODE=debug all