Hi Salvatore,
First of all, apologies for the very late reply — I only just saw your messages
from August and September. Sorry to have left your question about loong64
unanswered for so long.
To answer it now: yes, criu is functional on loong64, not just buildable. I've
verified a full checkpoint/restore cycle on a native loongarch64 host (Debian,
kernel 7.1.8+deb14.1-loong64 with CONFIG_CHECKPOINT_RESTORE=y):
# criu check
...
Looks good.
# dump a live process (a loop incrementing a counter in memory)
$ criu dump -t 116008 -D img -v4 --leave-stopped
...
(00.013691) Dumping finished successfully
# restore it
$ criu restore -D img -v4
...
(00.006345) Restore finished successfully. Tasks resumed.
The restored process continued its counter from where the dump was
taken:
counter=1 ... counter=7 (before dump)
counter=8 ... counter=17 (after restore)
i.e. registers / memory / file descriptors are correctly saved and restored on
LoongArch, which is exactly the state preservation that podman / crun rely on
for container checkpoint/restore.
Please let me know if you need anything else to enable loong64.
Regards,
Na Zhang
======================================================================
criu on loong64 (LoongArch) - functional verification evidence
======================================================================
--- 1. Environment ---
Architecture : loongarch64
Kernel : 7.1.8+deb14.1-loong64
Kernel config:
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_FHANDLE=y
criu version:
Version: 4.2.1
--- 2. criu check ---
Warn (criu/cr-check.c:1595): Hardware breakpoints don't seem to work
Looks good.
--- 3. criu dump - key log lines (full log: dump.log) ---
(00.000062) Version: 4.2.1 (gitid 0)
(00.000069) Running on debian Linux 7.1.8+deb14.1-loong64 #1 SMP PREEMPT Debian
7.1.8-2 (2026-08-15) loongarch64
(00.000880) Dumping processes (pid: 116008 comm: looptest)
(00.001674) Seized task 116008, state 1
pie: 116008: 116008: new_sp=0x7ffff3442f00 ip 0x7ffff3279224
(00.013568) Writing image inventory (version 1)
(00.013725) Dumping finished successfully
--- 4. criu restore - key log lines (full log: restore.log) ---
(00.000112) Version: 4.2.1 (gitid 0)
(00.000129) Running on debian Linux 7.1.8+deb14.1-loong64 #1 SMP PREEMPT Debian
7.1.8-2 (2026-08-15) loongarch64
(00.002680) Collected [usr/lib/loongarch64-linux-gnu/libc.so.6] ID 0x2
(00.002683) Collected
[usr/lib/loongarch64-linux-gnu/ld-linux-loongarch-lp64d.so.1] ID 0x3
(00.002955) Forking task with 116008 pid (flags 0x0)
(00.002960) Creating process using clone3()
(00.006345) Restore finished successfully. Tasks resumed.
--- 5. Test program output: counter continues across dump/restore ---
(counter=1..7 before/at dump, counter=8.. continues after restore)
counter=1
counter=2
counter=3
counter=4
counter=5
counter=6
counter=7
counter=8
counter=9
counter=10
counter=11
counter=12
counter=13
counter=14
counter=15
counter=16
counter=17
counter=18
counter=19
counter=20
counter=21
counter=22
counter=23
counter=24
--- 6. Conclusion ---
Both dump and restore succeeded. The restored process continued its
counter from 7 to 8, 9, ..., confirming that registers / memory / file
descriptors are correctly saved and restored on LoongArch.
