Blog

Open Source Summit North America 2026 and Embedded Linux Conference brought together the open source community in Minneapolis from May 18–20, 2026.

For the ELISA Project community, the event was an important opportunity to continue the conversation around safety-critical software, open source safety standards, regulatory compliance, requirements traceability, verification, software supply chains, and safety engineering.

The Safety-Critical Software Track highlighted practical work across several domains, including aerospace, embedded systems, medical devices, robotics, avionics, automotive, and industrial systems. Sessions explored how open source communities are addressing the technical, process, and compliance needs of safety-critical systems.

Over the next few weeks, we will highlight selected session recordings from the track and share key takeaways with the community.

This week, we highlight “The Final Phase of Xen Safety: Solving Coverage and Residual Gaps,” presented by Stefano Stabellini, AMD.

Moving Xen Toward Final Safety Certification

AMD, in collaboration with the Xen community, is working to make the Xen hypervisor safety-certifiable to ISO 26262 ASIL D and IEC 61508 SIL 3 on Arm and AMD x86 platforms.

Stefano explained that the first phase of the project, Safety Concept Approval, has been completed. During this phase, safety assessors reviewed the project plans and examples of the safety artifacts.

The team is now nearing completion of the second phase, which focuses on carrying out those plans and addressing the remaining gaps in the certification effort.

The work is being developed in collaboration with the upstream Xen community rather than through a private fork. Major changes have been upstreamed, the Xen branch being prepared for certification is publicly available, and the team is working to make requirements, examples, tools, and infrastructure public wherever possible.

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.

Open Source Summit North America 2026 and Embedded Linux Conference brought together the open source community in Minneapolis from May 18–20, 2026.

According to the event report, the event welcomed 1,231 attendees from 524 organizations, with 68% of attendees in technical positions. The program included 210 conference talks selected from 977 talks submitted, reflecting strong interest and participation across the open source ecosystem.

For the ELISA Project community, the event was an important opportunity to continue the conversation around safety-critical software, open source safety standards, regulatory compliance, requirements traceability, verification, software supply chains, and safety engineering.

The Safety-Critical Software Track highlighted practical work across several domains, including aerospace, embedded systems, medical devices, robotics, avionics, automotive, and industrial systems. Sessions explored how open source communities are addressing the technical, process, and compliance needs of safety-critical systems.

Over the next few weeks, we will highlight selected session recordings from the track and share key takeaways with the community.

Session Highlight: From Pull Request To Patient Safety: How Tidepool Built an Open-Source Quality Management System – Tapani Otala, Tidepool

In this session, Tapani Otala of Tidepool shared how Tidepool built an open source Quality Management System (QMS) for safety-critical medical software.

Tidepool is a nonprofit organization founded by people with diabetes, parents of children with diabetes, and clinicians. The organization builds open source tools for diabetes care, including Tidepool Loop, an automated insulin delivery system. Tidepool Loop uses data from a continuous glucose monitor, runs an algorithm on a phone, and communicates with an insulin pump to adjust insulin delivery. Because the software can influence insulin delivery every five minutes, including while a person is asleep, the system must be developed with strong safety and regulatory controls.

A central point of the talk was that open source and FDA-cleared medical software can coexist. Tidepool Loop was cleared by the FDA as Class II Software as a Medical Device, while the source code remained open. Tapani explained that safety and regulatory standards define what evidence and controls are needed, but they do not require the software to be closed source.

The session outlined the core elements of a QMS, including traceability, verification and validation, risk management, and change control. Tapani described QMS as a controlled, repeatable, and auditable system made up of policies, procedures, records, requirements, risks, tests, reviews, and change history.

A major part of the talk focused on how Tidepool connects engineering work to regulatory evidence. Requirements are tracked in Jira and linked to design, implementation, tests, risks, mitigations, bugs, and other records. These links are not just references; they form the structure that allows Tidepool to trace a requirement through development and testing, and then trace code or test evidence back to the original requirement.

Tapani used a specific requirement for insulin delivery presets as an example. A feature that may appear simple to users can generate a large set of safety and regulatory artifacts, including development tickets, test tickets, risk records, mitigations, UX design work, usability testing, and training requirements. In one example, a requirement for presets was connected to multiple risks and tests, showing how safety-critical software features can create significant downstream evidence needs.

The session also explained how Tidepool generates regulatory outputs from its development data. Instead of manually creating traceability matrices and risk analysis documents after development, Tidepool uses scripts to pull structured information from Jira and generate workbooks for regulatory review. These outputs include traceability views, risk analysis, hazard analysis, cybersecurity hazard analysis, and related summaries. This helps reduce manual drift and keeps documentation connected to the engineering work.

Another important topic was Tidepool’s relationship with the upstream open source Loop community. Tidepool Loop was based on the earlier do-it-yourself Loop project, which was created by a community of people who wanted better automated insulin delivery tools. Tidepool needed to maintain regulatory control over its FDA-cleared product while still staying connected to upstream innovation. The team does this by selectively bringing in changes, running them through the regulatory process, keeping shared code modular, and offering improvements back to the open source community where appropriate.

Tapani also shared lessons learned from building this system. One lesson was that the schema behind tools like Jira matters because issue types, link types, required fields, and relationships become part of the regulatory structure. Another lesson was that heavy workflow gates can slow engineers down, while downstream validation and automated checks can help maintain data quality with less friction.

The broader takeaway for safety-critical open source communities is that transparency can support trust. Tidepool’s experience shows that open source development, regulatory compliance, and safety engineering can work together when traceability, risk management, testing, and change control are built into the development process.

As safety-critical software continues to expand across medical, automotive, aerospace, industrial, and embedded systems, Tidepool’s work offers a practical example of how open source communities can build auditable processes while keeping development open and collaborative.

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.