add Loongarch init support

[yzewei]

What was done

Completed a single-core (1 vCPU) guest VM for LoongArch64:

1. Completed the basic integration path of LoongArch64 in arch/devices/vmm:

• LoongArch startup/register initialization, FDT generation, MMIO/interrupt chip integration, memory layout and loading process adaptation.

• Completed LoongArch branches for critical paths such as builder, vstate, and mmio, ensuring the VM can normally enter the guest and run test cases.

2. Completed test and runtime chain adaptation:

• Supported the LoongArch guest-agent running mode on the test side (including runtime dependency handling), and fixed console startup timing issues.

• Improved relevant test cases under LoongArch.

Tests Passed

Integration Tests (LoongArch, Single Core)

• configure-vm-1cpu-256MiB

• configure-vm-1cpu-1GiB

• vsock-guest-connect

• tsi-tcp-guest-connect

• tsi-tcp-guest-listen

• multiport-console

Unit Tests

• All unit tests in vmm passed.

Future Improvements

• SMP (2+ vCPUs): Currently, due to the lack of an upstream version of the interrupt mechanism (IPI) on both the host KVM and guest kernels, startup with 2 vCPUs fails under SMP.

About LoongArch

The LoongArch architecture (LoongArch) is an Instruction Set Architecture (ISA) that has a RISC style.

Documentations:
ISA:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
ABI:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
More docs can be found at:
https://loongson.github.io/LoongArch-Documentation/README-EN.html

[jakecorrenti]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces support for the loongarch64 architecture, encompassing core architecture definitions, EFI system table setup, IOCSR emulation, and a specialized KVM interrupt chip. The implementation integrates LoongArch into the microVM builder and updates libkrun to manage architecture-specific kernel loading and vCPU constraints. Review feedback identifies a critical register mapping error regarding the Linux boot protocol, logic errors in IOCSR mailbox indexing, and the need to manually assert interrupts since irqfd is disabled for this architecture. Additionally, error handling improvements are suggested to replace unwrap() calls and provide more accurate error variants.

[jakecorrenti]

Hi @yzewei thank you very much for the contribution. I'm working through a thorough review at the moment, but I have a few questions:

1. What's the best way for me to test this considering I don't have loongarch hardware?
2. Are you willing to provide some sort of commitment to maintain this architecture? I would like to avoid adding a bunch of code to the repository for an architecture that I don't believe any of us have any knowledge/hardware for if we can't have someone address bugs/issues

[yzewei]

Hi @yzewei thank you very much for the contribution. I'm working through a thorough review at the moment, but I have a few questions:

1. What's the best way for me to test this considering I don't have loongarch hardware?
2. Are you willing to provide some sort of commitment to maintain this architecture? I would like to avoid adding a bunch of code to the repository for an architecture that I don't believe any of us have any knowledge/hardware for if we can't have someone address bugs/issues

Hi @jakecorrenti, thank you so much for taking the time to review this document 🙏

I will be working towards remote access to the LoongArch hardware environment.

Regarding testing without using LoongArch hardware:

I will attempt to run a LoongArch QEMU virtual machine on an x86 machine to complete the basic environment for reproducing the libkrun host environment. Of course, I'd also be happy to test any changes on my LoongArch hardware and report the results as soon as possible.

The goal is to ensure LoongArch runs on libkrun without using physical hardware.

Regarding long-term maintenance:

Yes—we are committed to continuing support for LoongArch, and my colleagues will also be involved in this work @wxpppp .

We currently have various LoongArch machines for testing/debugging.

We plan to assist in following up on issues, bug reports, and necessary updates related to the LoongArch architecture in libkrun.

I understand everyone's concerns about adding unsupported architectures, therefore I am committed to maintaining this code and ensuring its availability.