Continuous Integration
GitLab CI: The Primary Test Infrastructure for Xen
The Xen Project relies on GitLab CI as its primary test infrastructure, enabling continuous integration and validation across a wide range of hardware and software configurations. This system ensures that every change to Xen is thoroughly tested, helping maintain quality and stability. Explore how it works, what tests are run, and how you can contribute or integrate your own hardware into the testing grid.
Unlike anything else…
🚀 Unlike most open source projects, Xen CI lets you:
- 🛠️ Run tests on your own hardware from your own lab
- 📡 See live public results from the global test grid
This level of transparency and extensibility is practically unheard of in other hypervisor projects.
🌐 Live Test Grid: See Xen CI in Action
Want proof? Here’s a real-time view of Xen running on real boards across our global test grid:
Why This Matters for You ✅
Whether you’re building cloud infrastructure or deploying Xen in industrial, automotive, or embedded systems, validation on real hardware is critical.
With Xen’s CI system:
- You can connect your own devices (development boards, embedded targets, automotive platforms) directly to the test grid
- Every commit to Xen can be automatically tested against your hardware, with full traceability and access to logs
- There’s no need to pay for cloud lab time. You can run and debug tests directly in your own environment
This is a key differentiator that sets Xen apart from both open source and proprietary hypervisors.
You stay in control, and testing fits into your workflow, not the other way around.
What is GitLab CI?
Xen Project’s upstream development is backed by a powerful, public GitLab CI system. It runs over 100 automated tests across multiple architectures and hardware platforms, every time new code is pushed.
But this isn’t your typical cloud CI setup…
Xen Project GitLab CI
🎥 Watch: GitLab CI in Action at Xen Summit
Want a deeper dive into how Xen’s CI works? Check out this talk from the 2023 Xen Developer & Design Summit
CI Workflow Overview
Xen’s GitLab CI system orchestrates build and test jobs across various environments to ensure code quality and hardware compatibility.
Every CI pipeline starts by building Xen across a wide range of Linux distributions. Here’s how that works.
Build Jobs
Xen’s GitLab CI includes build jobs across multiple Linux distributions such as Debian, Fedora, and Alpine, ensuring compatibility and successful builds in diverse environments.
Test Jobs
To validate the builds, Xen’s GitLab CI includes test jobs that fall into 2 categories: QEMU and Hardware.
QEMU
Most tests are performed using QEMU emulation, allowing rapid validation of Xen features in an emulated environment.
Hardware
Real hardware tests cover booting Dom0, DomU, and Dom0less setups, PCI passthrough, and suspend/resume functionality.
Xen CI Pipeline
Developer pushes code
GitLab Pipeline Triggered
Build Job
(x86, ARM64)
QEMU Test Job
Hardware Test Job
Serial Output Checked
Result: Pass/Fail
Wondering how the virtual and hardware tests compare? Here’s a side-by-side look.
QEMU vs Hardware: How They Differ 🔍
Xen CI supports both emulated test environments and real hardware validation. Here’s a quick side-by-side look at how QEMU-based and hardware-based test jobs differ:
QEMU Test Job (Emulated)
Test Runner Container
Xen + Tools Installed
QEMU Launched
- Xen boots inside QEMU
- Dom0 and optional DomU launched
- Serial output monitored for success
Serial logs checked → Pass/Fail
Hardware Test Job (Baremetal Execution)
Test Runner Container
(on Controller)
Test Script Executes
Triggers:
- PDU (power on)
- TFTP boot
- Serial monitoring
Test Board (e.g. ZCU102, Zen3)
Xen boots natively on board
- Dom0 and DomU launched
- Serial logs captured
- Result sent back to pipeline
Serial logs checked → Pass/Fail
Test Coverage Highlights
Xen CI covers a wide range of scenarios to ensure high-quality releases across diverse environments:
- ✅ Architectures: x86, ARM32, ARM64, RISC-V, PowerPC
- 🔁 Features: Dom0 boot, DomU launch, Dom0less, suspend/resume, PCI passthrough
- 🧪 Tools: Static analysis with cppcheck, MISRA C, and more
- 🧩 Environments: QEMU virtualized tests and real baremetal boards
- 🧷 OS coverage: Debian, Fedora, Alpine, and FreeBSD (via Cirrus-CI)
Additional testing is also performed on Cirrus-CI for FreeBSD builds using a full LLVM based toolchain.
Bring Your Own Hardware (BYOH) 🛠️
One of Xen’s most powerful features is the ability to connect your own hardware to the public CI grid:
- Run GitLab Runner on a nearby host
- Connect your boards via serial, TFTP, and PDU (power switch)
- Add a few YAML snippets, and you’re in!
This is ideal for:
- 🚗 Automotive teams testing ECUs or infotainment platforms
- 🏭 Industrial users with specialized hardware or I/O
- 📦 Edge/IoT deployments using Raspberry Pi, Rockchip, or custom boards
Get Involved 🤝
Want to test Xen on your own hardware? Want to learn more?
- 💬 Join the discussion on matrix
- 📬 Subscribe to the mailing lists
- ✉️ Email our Community Manager: community.manager@xenproject.org
We’re always happy to help you get started or connect with others using Xen in production.