RFC: Does libkrun support LoongArch64 Linux/KVM?

[yzewei]

Hello,

I've been developing a LoongArch64 port of libkrun, targeting native LoongArch64 Linux/KVM hosts. I'd like to first understand if upstream support for this architecture is warranted before investing more time in refining this project.

From an ecosystem perspective, LoongArch is now much easier to upstream support than it was a few years ago:

• Linux already supports the upstream LoongArch architecture and provides dedicated KVM documentation.

• Rust provides host tools for loongarch64-unknown-linux-gnu as a Tier 2 target library.

• QEMU provides support documentation for qemu-system-loongarch64 and LoongArch KVM.

• Debian officially announced loong64 as the official architecture on December 20, 2025.

Regarding libkrun, I've created an initial startup branch covering the core architectural foundations of Linux/KVM on LoongArch64, including memory layout, interrupt chip settings, FDT generation, serial/legacy device handling, virtual CPU settings, and kernel boot path. This work is still in the validation phase, so I'm not considering it for merging yet; at this stage, I mainly want to confirm whether this direction is suitable for the project.

I have the following questions:

1. Is libkrun willing to merge LoongArch64 Linux/KVM support upstream?

2. If so, what do you think the initial release should at least include?

3. Is the main consideration long-term maintenance/continuous integration coverage, or are there architectural reasons why libkrun is unsuitable for adding another KVM architecture?

If the project is open to this direction, I'm willing to assist with the subsequent maintenance of the port, including preparing and rebuilding patch sets, fixing regression issues on LoongArch64, and assisting with validation/continuous integration.

Thank you.

[slp]

• Is libkrun willing to merge LoongArch64 Linux/KVM support upstream?

As long someone volunteers to stick around to review future PRs, and it's at least possible to have some minimal CI (code-quality tests with cross-build, at minimum), we can merge it.

• If so, what do you think the initial release should at least include?

If it's just another architecture without changes in the API nor significant changes in common components, it can be part or 1.18.

• Is the main consideration long-term maintenance/continuous integration coverage, or are there architectural reasons why libkrun is unsuitable for adding another KVM architecture?

The first, as mentioned above.

[yzewei]

• Is libkrun willing to merge LoongArch64 Linux/KVM support upstream?

As long someone volunteers to stick around to review future PRs, and it's at least possible to have some minimal CI (code-quality tests with cross-build, at minimum), we can merge it.

• If so, what do you think the initial release should at least include?

If it's just another architecture without changes in the API nor significant changes in common components, it can be part or 1.18.

• Is the main consideration long-term maintenance/continuous integration coverage, or are there architectural reasons why libkrun is unsuitable for adding another KVM architecture?

The first, as mentioned above.

Okay, thank you for your reply. I will complete the testing of the libkrun-loongarch branch locally, review the code again, and then submit basic support (including libkrunfw) in stages. By the way, since loongarch uses a PE external kernel format, a KBUNDLE_TYPE needs to be added to libkrunfw.