2026-07-21 07:09:48Ralf Lici:
add arm64 coverage info and references to the latest virtme-ng fixes
DataChannelOffload/CI for DCO Linux.md ..
@@ 33,10 33,10 @@
## High-level flow
-
Each matrix job starts on a standard `ubuntu-24.04` GitHub runner. The runner
-
installs the host-side tools needed to build root filesystems and boot virtual
-
machines: `mmdebstrap`, `dnf`, `qemu`, `virtme-ng`, `virtiofsd`, and related
-
utilities.
+
Each matrix job starts on a standard `ubuntu-24.04` or `ubuntu-24.04-arm64`
+
GitHub runner. The runner installs the host-side tools needed to build root
+
filesystems and boot virtual machines: `mmdebstrap`, `dnf`, `qemu`,
+
`virtme-ng`, `virtiofsd`, and related utilities.
The job then checks out two repositories:
@@ 58,10 58,10 @@
them from an Ubuntu GitHub runner.
Once the rootfs exists, the workflow boots it with virtme-ng. Inside the guest,
-
the caller-provided script runs as root. For `ovpn-backports`, that script
-
builds the module and runs the ovpn kselftests. For `ovpn-dco`, the current
-
useful signal is primarily whether the module still builds across the supported
-
kernel matrix.
+
the caller-provided script runs as root. For `ovpn-backports` on x86_64, that
+
script builds the module and runs the ovpn kselftests. For `ovpn-dco` and
+
`ovpn-backports` on arm64, the current useful signal is primarily whether the
+
module still builds across the supported kernel matrix.
## Why boot the distro kernel?
@@ 152,14 152,17 @@
target is noticeably slower, but still useful because it covers the oldest
kernel generation the module is expected to support.
-
The other important performance detail is KVM. GitHub's Linux runners currently
+
The other important performance detail is KVM. GitHub's x86_64 Linux runners currently
expose `/dev/kvm`, so nested virtualization works and the guest boots are quick.
The guest runner script still probes for `/dev/kvm` before booting. If it is
missing, it adds `--disable-kvm` and continues with software emulation rather
than failing outright. That fallback is a safety net: GitHub documents nested
virtualization on hosted runners as
["experimental and done at your own risk," with no guarantees on stability or performance](https://docs.github.com/en/actions/concepts/runners/github-hosted-runners#runner-images).
-
Today it works; the CI probes anyway.
+
In fact, on arm64, KVM is not exposed so we resort to software emulation which
+
is not only way slower but also instable (for example it occasionally segfaults
+
while building or installing the module). For this reason arm64 targets are
+
kept minimal and manual-dispatched only.
RHEL kernels also forced work in this area because they do not provide 9p at
all, and virtme-ng historically mounted some helper exports over 9p. That
@@ 168,15 171,22 @@
removes the remaining hardcoded 9p helper exports and uses virtiofs instead
when virtiofs is available.
-
One related issue is still open at the time of writing:
