Xen, KVM, Jailhouse, QNX: Which Automotive Hypervisor Fits Which Integrity Level

The answer changes with the integrity level of the function you are partitioning, and no feature table shows that. At the higher integrity levels with hard timing requirements, the assessed commercial product is the low-risk choice by a clear margin. At the lower levels, decomposition with an independent monitor on Linux with KVM is a real shipping pattern with assessed products behind it. For workloads genuinely outside the safety argument, an assessed hypervisor buys evidence nobody will ask you for. And at every level, the timing interference argument on your own system-on-chip stays yours.

Every automotive hypervisor comparison table has the same rows: type 1 or type 2, static or dynamic partitioning, licence, architectures supported. Those rows are easy to fill in and they decide nothing, because they are the same whichever function you are protecting. The question that decides a programme is which automotive hypervisor fits which integrity level. What a safety assessor will accept for an ASIL D function is not what they ask for at ASIL B, and neither resembles what they ask for on a workload carrying no safety requirement at all. This post works through the four options on that basis, as of 24 September 2026, and is explicit about the part none of them settles for you.

The strongest case for QNX Hypervisor for Safety

The non-Linux option comes first and at its strongest, because the reasons a functional-safety engineer selects it are engineering reasons as well as procurement ones.

The evidence already exists, is finished, and has a reference number. BlackBerry QNX holds a TÜV Rheinland functional-safety certificate for QNX Hypervisor for Safety, recorded in a public register an assessor can look up. The vendor's product brief states that QNX Hypervisor for Safety 8.0 is pre-certified to ISO 26262 ASIL D, IEC 61508 SIL 3 and IEC 62304 Class C, and that it includes safety artefacts. "Pre-certified" is the vendor's term for a safety element out of context: an assessment performed against assumed requirements that the integrator must then validate against the actual item.
The timing behaviour is specified, not emergent. This is the reason that has nothing to do with paperwork. The product brief describes deterministic scheduling, bounded latency and strong domain separation, a hypervisor operating at EL2 so that guest transitions stay predictable, and support for both symmetric and bound multiprocessing so that virtual CPUs can be pinned to specific cores. A timing argument can be built on published, analysable behaviour. It cannot be built on measurements of a general-purpose scheduler.
The division of labour is defined. The supplier performed development activities against the standard and hands over a safety manual stating its assumptions of use. The integrator's remaining job is to confirm those assumptions hold in the actual item and to document where they do not. That work is bounded, and it can be planned and staffed.
Accountability is single-point. One supplier, under contract, with a support obligation. When a defect appears during integration there is a company to raise it with rather than a mailing list.
The privileged code base is small. In a microkernel, drivers, filesystems and protocol stacks run in memory-protected user space, so the privileged trusted computing base is a fraction of a general-purpose kernel and a fault in a device service does not take the system with it. Less privileged code means less to analyse, fewer requirements to trace and fewer changes to re-assess over a long product life.

Two things belong here rather than being left to a sceptical reader. First, a supplier's certificate is not your functional safety assessment: the assumptions of use, the development interface agreement and the confirmation measures at item level remain yours, and that work is frequently underestimated. Second, this is not a QNX-or-Linux choice. The vendor's own description has safety and non-safety operating systems, Android and Linux included, running side by side in isolated domains. The normal architecture is QNX hosting a Linux guest: you keep the Linux stack and stop resting the highest-integrity function on it.

If your programme needs an automotive hypervisor under a function classified at the higher integrity levels, and the argument must close on a schedule, this is the option that most obviously works today. Nothing in the rest of this post is intended to argue otherwise.

An automotive hypervisor comparison compares four categories of object

The four are not four products. QNX Hypervisor for Safety is a commercial product with an assessed certificate and a safety manual. Xen is an open-source project that has organised a formal committee to produce and maintain safety artefacts. KVM is a set of modules inside the Linux kernel, so its evidence position is inseparable from the Linux baseline you choose. Jailhouse is a reference design that demonstrated a partitioning approach and whose public development has stopped.

Three words are worth keeping apart. Certified means an assessment happened and a certificate names a scope, with an assessor named. Certifiable means a package exists to support an assessment the integrator still has to arrange. A safety package is available means documentation and evidence exist and no assessment has been stated. Most of this market sits in the middle category, and collapsing the three is how a reader ends up believing something untrue.

Two limits on this axis should be stated plainly, because it is the axis this automotive hypervisor comparison runs on. It is not the only axis, and it happens to be the one on which an open-source project can catch up by producing documents. It does not measure temporal determinism, and it does not measure the size of the trusted computing base as an architectural fact rather than an audit cost. On those, a certified microkernel does not need to catch up. Readers should weigh all three.

The scope is narrower than the market. Commercial separation kernels, other commercial automotive hypervisor products and the packaged Linux offerings are outside this post: three of these four are the open-source options an embedded Linux team is most often asked about, and the fourth is the commercial position they are measured against.

Freedom from interference is the part no automotive hypervisor settles alone

Before comparing evidence packages it is worth being clear about what an automotive hypervisor does and does not deliver, because this is the most common overestimate in the field.

Spatial isolation — one partition cannot read or write another's memory, and a device cannot write outside its owner's memory through DMA — is enforced by hardware. Stage-2 translation and the system MMU do the work; the hypervisor configures them. This part is well understood and all four candidates use the same silicon mechanisms.

Temporal isolation is the harder half and it is where designs are oversold. Two partitions pinned to dedicated cores still contend for the shared last-level cache, for DRAM banks and the memory controller, for interconnect bandwidth and for system MMU translation resources. That contention is invisible in the configuration file and can move worst-case execution time by a large factor. No automotive hypervisor in this comparison removes it by partitioning cores. It is addressed, where it is addressed at all, by cache partitioning or colouring, by memory bandwidth regulation, or by quality-of-service regulators in the silicon — and by the SoC vendor's own safety manual, which states what the part guarantees.

That has a consequence for every section below. The automotive hypervisor is one input to a freedom-from-interference argument. The silicon is another, and often the decisive one. An evidence package that does not address timing interference on your specific SoC has not finished the job, whoever supplied it.

Xen: a project that has organised its safety evidence

The most consequential change in the open-source automotive hypervisor picture in the last year is dated 17 August 2026, when the Linux Foundation announced the Xen Safety Committee.

The announcement describes a formal project committee whose responsibility, beyond maintaining source code, is to develop and maintain engineering artefacts supporting organisations' downstream functional safety certification. The founding contributors are AMD, EPAM and Renesas. What they contributed is the interesting part, because it is a list of what an assessor asks for: software safety requirements, architecture specifications, MISRA C coding-standard work, design failure mode and effects analysis, testing frameworks, tooling, code coverage and process documentation.

Two further facts from the same announcement matter in practice. The project extended the support lifecycle for Xen releases to five years in 2026 — three of regular support, then two of security support — which matters because a vehicle programme cannot build on a component maintained for less time than its own integration phase. And a membership tier, Premier Plus, gives members votes on the committee and access to the committee-managed artefacts.

That last point should be stated plainly. The source code is open. The safety artefacts are committee-managed and access to them is a membership benefit. Reading the code and obtaining the evidence package are two different transactions, and the project does not publish a price for the second on its membership page. This is the single most practical fact in this post for anyone budgeting an evaluation.

The technical work is visible in a dated session. At an ELISA seminar on 13 May 2026, Ayan Kumar Halder of AMD and Matthew Weber of Boeing presented the work items upstreamed or published for Xen. They include MISRA C fixes, memory protection unit support, requirements, architecture and test specifications, and a testing programme running from fault injection and fuzzing to modified condition/decision coverage. The session also describes shrinking the code that has to be certified through fine-grained configuration options. The stated purpose is validating Xen as a safety element out of context.

Note the tense. That is work aimed at validation, not a validation that has happened. The Xen Project says so itself, in wording more careful than most of what is written about it. Its safety page states that Xen source code is not itself safety certified, and that certification depends on the complete system, integration context, process, evidence, tooling, validation and safety case. The committee's artefacts, the same page says, are inputs to each organisation's own assessment and are not a complete product certification.

That is the statement to rely on, because a supporting quote in the same press release refers to achieving baseline functional safety certification for Xen as a milestone already reached. The two contradict each other, and where a project's technical page and its press release disagree about certification status, the technical page is the one an assessor will read.

One architectural point belongs here and is usually omitted. A conventional Xen deployment has a full Linux kernel in the control domain holding the device drivers, so the claim that Xen is a thin layer while KVM carries all of Linux is not true of the default configuration. Xen's case as an automotive hypervisor rests on dom0less boot and static resource partitioning, both of which the project lists as capabilities: guest domains start without waiting for a traditional control-domain boot path, and CPU, memory, device and interrupt ownership become platform design decisions. Without that configuration the trusted computing base argument does not hold.

On adoption, the project's own membership page lists AMD, ARM, AWS, Boeing, EPAM, Ford Motor Company, Honda, Renesas, Vates and XenServer. Two carmakers and an aerospace manufacturer paying for a seat on the advisory board is a meaningful signal about where the work is aimed. It is not evidence that any of them ships Xen in a product, and this post makes no such claim.

KVM: the evidence position is the kernel's

KVM is the automotive hypervisor option most often misread, because the decisive fact about it is structural. It is a set of kernel modules running in kernel space. It does not boot ahead of Linux; it depends on the kernel for scheduling, memory management, drivers and device support.

The consequence for evidence is that KVM is not a separable layer you can scope on its own. Any safety argument about it is an argument about a specific Linux baseline in a specific configuration. That route has a name and a published document. ISO/PAS 8926:2024, Use of pre-existing software architectural elements, was published on 29 January 2024 and defines the classification and tailoring path for software not developed to conform with ISO 26262. Its own worked example of such an element is an operating system. An earlier post on this site sets out what a Linux safety certification actually covers and what a certificate on a Linux product does and does not bound.

Two corrections to the compressed version of this argument. Saying KVM "has no evidence" is wrong: stable and longterm branch maintenance, kernel selftests, static analysis, vendor BSP verification records and the process work coming out of ELISA are all engineering evidence an assessor will look at. What does not exist is a packaged product certification for generic upstream KVM. And assessed Linux products do exist — Red Hat's In-Vehicle Operating System is certified by exida as a safety element out of context at ASIL-B, with a safety guidance document containing assumptions of use. The honest statement is not that Linux cannot be argued, but that it is argued at a different integrity level, by a different route, with more of the work falling on the integrator.

A distinction worth drawing, because it is a common confusion. Android's Virtualization Framework uses protected KVM to run protected virtual machines. Google documents it as security-oriented, supported only on ARM64, with the property that a compromised host cannot read a protected machine's memory. That is a security claim, and there are no safety artefacts behind it. But it would be wrong to dismiss the architecture: moving isolation enforcement into a small component at EL2, and removing the host kernel from the trusted computing base for that property, is the most plausible future foundation for a Linux-side isolation argument. The evidence to support one does not exist today. That is a statement about the evidence, not about the mechanism.

KVM's defensible role in a vehicle today is consolidation of workloads that sit outside the safety argument, on a Linux platform the team already runs and already maintains.

Jailhouse: no public development since January 2023

Jailhouse, the fourth automotive hypervisor here, is described by its own repository as a Linux-based partitioning hypervisor that runs bare-metal applications or adapted operating systems beside Linux. It performs no scheduling, and it virtualises in software only those resources that a platform requires and that cannot be partitioned in hardware.

The design is genuinely different from the other three, and its claim should be stated accurately. Assigning CPUs, memory and devices statically removes hypervisor scheduling as a source of interference, which is a real simplification. It does not remove temporal interference through the shared cache, the memory controller and the interconnect, which is the dominant problem in multicore mixed-criticality systems. Static core assignment narrows what you must argue about. It does not close the argument.

The larger problem is the state of the project. Reading the public repository on 24 September 2026, the most recent tag is v0.12, dated 4 February 2020. The most recent commit on master is dated 16 January 2023 and on next 22 January 2023.

Two caveats belong with that. Siemens may maintain the code internally and downstream forks exist, so an absence of public commits describes the public repository and not the world. And a static partitioner is a small piece of software that could reasonably reach a stable state. But a component in a vehicle needs a security response path and a maintenance commitment measured in fifteen years, and a repository with no public activity since January 2023 does not demonstrate one. For a programme starting now this is a design worth studying, not a supplier position you can enter into a safety plan.

What this comparison does not settle

Several things are deliberately left unclaimed. No OEM or Tier 1 is named as running any of these four as its automotive hypervisor in a production vehicle; membership of a project is not deployment, and deployment information in this industry is routinely under non-disclosure. The detailed scope of the QNX certificate is not analysed, only its existence and the category of evidence it represents. No performance, latency or footprint numbers appear anywhere, because published benchmarks for these four come from interested parties on hardware nobody else can reproduce.

I did not read the Xen safety artefacts, because access to them is a membership benefit; what is described above is the project's own public description of their contents, and that limitation applies to any evaluation from outside the membership. The Jailhouse dates come from the public repository, and no statement is made about internal Siemens development. No ISO 26262 clause number is cited anywhere in this post, because the relevant parts are paid documents and only their published abstracts were read.

What each one can hand an assessor today

Option	Category	What it supplies	Who can obtain it
QNX Hypervisor for Safety	Assessed commercial product	Certificate with a public register entry, plus a safety manual carrying assumptions of use	Any customer
Xen	Project producing shared artefacts	Requirements, architecture and test specifications, tests, coverage, static analysis, process documentation — described by the project as inputs, not a certification	Premier Plus members
KVM	Linux kernel subsystem	Whatever the chosen Linux baseline supplies, under the pre-existing software route; assessed Linux products exist at ASIL-B	Anyone
Jailhouse	Dormant reference design	Source and a clear design; no demonstrated maintainer or security response path	Anyone

That is the table an automotive hypervisor comparison should have been. It still does not decide anything on its own, because what an assessor will accept depends on what the function is classified at.

Which automotive hypervisor fits which integrity level

ISO 26262 does not offer one answer. It classifies a function from QM through the four ASILs, and the evidence demanded at each end of that range is not comparable. The published subject list of ISO 26262-9:2018 includes requirements decomposition with respect to ASIL tailoring. That is the mechanism behind the middle of this table: a requirement at one level can be decomposed across elements argued at lower levels, provided their independence is established.

Function classified at	Defensible choice today	What you still owe
Higher ASIL, hard real-time (for example a function whose timing budget is part of the safety requirement)	An assessed commercial product. QNX Hypervisor for Safety is pre-certified by its vendor to ISO 26262 ASIL D and publishes deterministic scheduling and bounded latency.	Validate the safety manual's assumptions of use against your item; your own DIA and confirmation measures; the timing interference argument on your SoC.
Lower ASIL, with decomposition available	Decomposition with an independent monitor, hosted on Linux with KVM, is a real shipping pattern. Assessed Linux products exist at this level: Red Hat's In-Vehicle Operating System is certified by exida as a safety element out of context at ASIL-B.	Establish the independence the decomposition assumes; qualify your Linux baseline under the pre-existing software route; the same SoC timing argument.
Any level, if you will run your own assessment	Xen, using the Safety Committee artefacts. The project attaches no integrity level to itself, so the level you reach is the level you and your assessor can defend.	Premier Plus membership to obtain the artefacts; your own assessor; a dom0less configuration, because the default control domain puts a full Linux kernel in the privileged path.
QM — outside the safety argument	Whatever your team already runs and maintains. A rear-seat entertainment stack consolidated with a connectivity gateway does not need an assessed hypervisor.	Confirm the partition really is outside the argument. Shared devices, update paths and resource exhaustion are the usual routes by which it is not.
Any level	Not Jailhouse. Its design is worth studying and its public repository has had no commit since January 2023.	—

Two questions settle most of this faster than any comparison table. Ask the supplier which product version and which configuration the certificate or the artefact set actually covers, because a certificate that does not name your build is not evidence about your build. Then ask what their safety manual assumes about the timing behaviour of your specific system-on-chip. The second question is the one that goes unanswered most often, and it is the one your assessor will return to.

Key takeaways

There is no single answer. Which automotive hypervisor fits depends on the integrity level of the function you are partitioning, and a feature table cannot show that.
At the higher integrity levels with hard timing requirements, the assessed commercial product is the low-risk choice by a clear margin. At the lower levels, decomposition with an independent monitor on Linux with KVM is a real shipping pattern, and assessed Linux products exist at ASIL-B.
Keep certified, certifiable and a safety package is available apart. Most of this market sits in the middle one.
Spatial isolation comes from the silicon and the hypervisor configures it. Temporal interference through shared cache, memory controller and interconnect is not solved by partitioning cores, and none of these four closes it for you.
The Xen Safety Committee, announced on 17 August 2026, produces artefacts the project describes as inputs to your own assessment, not a product certification. Access is tied to Premier Plus membership. Xen's automotive case also depends on a dom0less configuration.
Ask two questions of any supplier: which version and configuration the evidence covers, and what the safety manual assumes about your SoC's timing behaviour.

Frequently asked questions

Which automotive hypervisor should I use at ASIL D?
For a higher-integrity function with hard timing requirements, an assessed commercial product is the low-risk choice today. At the lower integrity levels, decomposition with an independent monitor hosted on Linux with KVM is a real shipping pattern, and assessed Linux products exist at ASIL-B.

Is Xen safety certified?
No. The Xen Project states on its own safety page that Xen source code is not itself safety certified, and that the Safety Committee's artefacts are inputs to an organisation's own assessment rather than a product certification.

Can I certify KVM on its own?
Not as a separable layer. KVM is a set of modules inside the Linux kernel and depends on it for scheduling, memory management and drivers, so any safety argument about KVM is an argument about a specific Linux baseline, taken under the pre-existing software route defined by ISO/PAS 8926:2024.

Does an automotive hypervisor give me freedom from interference?
Only partly. An automotive hypervisor configures the hardware that provides spatial isolation. Temporal interference through shared cache, the memory controller and the interconnect persists even when partitions have dedicated cores, and it has to be addressed with the SoC's own mechanisms and its safety manual.

Is Jailhouse still maintained?
Its public repository shows no commit on either the master or next branch since January 2023, and no release since v0.12 in February 2020. Siemens may maintain it internally and forks exist, but the public repository does not demonstrate an active maintenance or security response path.