Xen’s Role in Functional Safety
Xen’s role in a functional safety system is to enforce isolation and freedom from interference between virtual machines.
This means ensuring that one virtual machine cannot affect another through memory access, security issues, latency, performance, or other system resources.
The session reviewed how Xen’s architecture can support embedded and safety-critical systems. Traditional Xen deployments often rely on Dom0, a large and highly privileged domain used to start and manage other virtual machines.
In embedded systems, the required virtual machines are often known before the platform starts. Xen can therefore launch them directly at boot, reducing the need for a large and privileged Dom0 environment.
Stefano described a model that separates responsibilities between a small control domain and a hardware domain. The control domain can monitor and restart selected virtual machines, while the hardware domain can manage devices and drivers without receiving unnecessary privileges.
Xen can also support untargetable domains that cannot be controlled or monitored by other domains. These domains can be used for safety-related workloads that require stronger isolation.
The Challenge of Complete Code Coverage
A central focus of the presentation was one of the most difficult remaining challenges: achieving complete code coverage.
Stefano explained that safety verification requires teams to document the behavior of the software and test that behavior. The combined test results must cover the code included in the certified software, including the independent conditions required for Modified Condition/Decision Coverage, or MC/DC.
This is particularly difficult for an open source project such as Xen.
Xen supports many processor vendors, platforms, configurations, and use cases. However, a specific certified configuration may only use a limited subset of this functionality.
For every code path, the team must therefore either test it or remove it from the final binary.
Removing Unused Code
Xen already uses Kconfig to enable and disable features before compilation. However, this is not sufficiently granular to remove every code path that falls outside a specific safety configuration.
Adding large numbers of conditional compilation statements would also make the upstream code more difficult to maintain.
Instead, the team is using compiler dead-code elimination.
By giving the compiler enough information about the selected configuration, code paths that cannot be reached can be removed automatically from the final binary.
One example involved processor-vendor-specific code. In a configuration that supports only AMD processors, the compiler can remove switch cases for other processor vendors.
Another example involved Xen’s x86 instruction-decoding code. Older x86 systems required Xen to decode trapped guest instructions manually. Modern systems provide more information about the instruction that caused the trap, so many legacy decoding paths are not required.
By limiting the configuration to modern hardware, the compiler can remove those unused paths.
Stefano showed how small source-code changes can allow the compiler to remove large sections of unused code without adding extensive conditional statements throughout the source.
The linker’s garbage-collection functionality can then remove entire functions that are no longer called.
Aligning Coverage Data With the Binary
Removing functions during linking creates an additional coverage challenge. Coverage notes are generated during compilation, but linker garbage collection happens later. As a result, the coverage information may still contain functions that were removed from the final binary.
Those functions could incorrectly appear as uncovered. To address this, the team developed two Python tools.
The first tool analyzes linker information, including the build log, map file, linker output, and DWARF data, to identify functions that were removed. It then creates a plain-text configuration showing which function was removed from which object file.
The second tool uses this information to remove the corresponding entries from the compiler-generated coverage notes. This process also accounts for static inline functions, which may be removed from one object file while remaining present in another.
The result is coverage information that more accurately represents the code included in the final binary.
Automating Fault Injection With QEMU
The session also covered fault injection, which is required to test how the software handles hardware errors.
Traditionally, this work may involve physical hardware and hardware debuggers, making tests difficult to automate and repeat. The team is instead using QEMU so that fault-injection tests can be included in continuous integration workflows.
Stefano described a Python framework that interacts with QEMU through QMP, QTest, and GDB.
QMP can inject events such as non-maskable interrupts and machine-check exceptions. QTest can simulate memory-mapped input/output and I/O port operations. GDB can set breakpoints and modify memory, registers, stacks, and function parameters.
By combining these interfaces, the team can trigger specific Xen error-handling paths and test them without changing the Xen source code for each case.
This makes the tests automated, repeatable, and suitable for use in verification pipelines.
Working With the Open Source Community
Stefano emphasized that the effort is not limited to AMD. Several organizations are contributing to work around Xen and safety, with collaboration taking place in the upstream community.
The goal is not to certify a private fork and leave it unchanged. Instead, the project aims to improve the upstream Xen codebase and make certification easier to maintain and repeat over time.
Making requirements, tools, artifacts, and infrastructure publicly available can also help support different configurations and safety targets in the future.
The session provided a practical look at the remaining work in Xen’s safety-certification effort, including complete code coverage, maintainable code reduction, accurate coverage reporting, automated fault injection, and open source collaboration.
Watch the session recording here.
Stay tuned for more Safety-Critical Software Track session highlights from Open Source Summit North America 2026. Check the playlist here.
