Speed up host-arm workflow via native execution on Arm64 runners

[DrXiao]

The proposed changes modify the build system to allow native execution on AArch64 when targeting Arm32, and update the workflow definitions for host-arm to use Arm64 runners and perform native bootstrapping and other validations.

Advantages

The original workflow of host-arm uses run-on-arch-action to validate whether bootstrapping and test cases run successfully. However, this job often takes a long time (6 ~ 8 minutes) because it relies on QEMU(*) to perform the build and run the test cases.

(*) If I understand correctly, run-on-arch-action actually uses qemu-system to execute the specified commands, which makes the emulation slow.

After applying the proposed changes, the job can be sped up via native execution on Arm64 runners. According to the results, host-arm can complete bootstrapping and test case validations within 2 minutes.

As a result, the workflow is noticeably faster.

---

Summary by cubic

Run the host-arm workflow natively on Arm64 runners by enabling Arm32 execution on AArch64. This removes QEMU emulation and cuts the job from ~6–8 minutes to ~2 minutes.

• Refactors
  • Allow native Arm32 execution on AArch64; only use qemu-arm when the host is not armv7l or aarch64.
  • Switch host-arm job to ubuntu-24.04-arm and install armhf libc and required tools.
  • Replace run-on-arch-action with direct make, check-sanitizer, and unit test steps.

^{Written for commit 47f6100. Summary will update on new commits.}

[DrXiao]

By the way, I have another branch, workflow/use-arm64-runner, to test whether using qemu-user with Arm64 runners improves performance.

The commit and the test results are provided as follows:
commit 992d1a1
host-arm (static) - 2m 41s
host-arm (dynamic) - 2m 2s

In summary, although using qemu-user with Arm64 runners also improves performance, native execution is faster.

[jserv]

This is confusing. Not all Arm64 machines support the A32 ISA; therefore, the supported instruction sets must be validated explicitly, without assuming that Arm64 implies Arm32 compatibility.

[DrXiao]

After further investigation, it appears that there is no way to validate whether a machine supports the A32 ISA using shell commands.

Therefore, I would like to propose an altenative approach: introducing a new variable, FORCE_NATIVE, to control whether native execution should be enforced. For example:

$ make                 # Let the build system automatically determine the proper way to run
$ make FORCE_NATIVE=1  # Enforce native execution

By default, the build system performs native execution only when the machine architecture is armv7l; otherwise, QEMU is used to run the generated executables. However, if a user has confirmed that their machine can use native execution, they can manually set FORCE_NATIVE=1 to enforce it.

---

For Arm64 runners, I found a reference on the Arm Developer website. Although GitHub's official documentation does not describe the hardware details of Arm64 runners, the referenced page states:

Arm-hosted runners are powered by Cobalt 100 processors, based on the Arm Neoverse N2. The free runners have 4 vCPUs and Armv9-A features including Scalable Vector Extension 2 (SVE2).

From this information, we can conclude that GitHub's Arm64 runners use Arm Neoverse N2 processors to run workflows on VMs. According to the Arm Neoverse N2 specifications, the supported ISAs explicitly include A32.

Thus, if the proposed FORCE_NATIVE approach is acceptable, we can directly add a workflow step to run make FORCE_NATIVE=1, allowing native execution on Arm64 runners. As a result, the speedup can still be achieved.

[DrXiao]

The above description represents my initial view. I can research further and provide more information if necessary.

[jserv]

We can introduce an allow list of machines with verified A32 support, eliminating the need for the manual FORCE_NATIVE option.