Shared hardware
Run more platform software on fewer boards while keeping ownership and failure domains visible.
Solution Area
Open source virtualization for embedded and automotive systems.
Build mixed-criticality platforms that consolidate Linux, RTOS, and specialized workloads onto shared hardware while keeping system boundaries explicit, inspectable, and maintainable throughout long product lifecycles.
Mixed-criticality platform
User space
Applications
Mixed workloads stay above platform-owned boundaries, with responsibilities kept explicit.
Domains
Guest systems
Linux, RTOS workloads, and service domains retain separate runtime and ownership assumptions.
- Linux
- RTOS
- Services
Isolation boundary
Xen hypervisor
Scheduling, runtime separation, device assignment, and platform control stay visible.
Shared compute
Hardware platform
Compute, memory, interrupts, and SoC integration remain explicit inputs for long-lived platforms.
Xen separates application workloads, guest domains, hypervisor control, and shared hardware into visible platform layers.
Why virtualization matters here
Consolidate the platform without blurring the boundaries.
Embedded and automotive teams need to combine more software on shared compute while preserving engineering, validation, and maintenance boundaries.
Mixed workloads
Give Linux, RTOS workloads, service domains, and specialized systems clear places to coexist.
Explicit boundaries
Keep devices, boot flow, interrupts, and integration responsibilities visible.
Maintainable platforms
Support architectures that can evolve across long hardware, software, and product lifecycles.
Mixed-criticality systems
Why mixed-criticality matters
Modern platforms combine workloads with different safety, timing, reliability, and maintenance needs. Mixed-criticality keeps attention on the boundaries between them, not just the shared hardware.
Different operating profiles
Control workloads, RTOS workloads, Linux services, infotainment, diagnostics, and OTA services can have different timing, reliability, update, and validation needs.
Shared compute pressure
As platforms consolidate onto fewer processors, workloads that once lived on separate controllers increasingly share memory, devices, interrupts, and boot paths.
Separation as an engineering concern
The hard problem is sharing hardware without blurring ownership, validation scope, fault containment, or lifecycle boundaries.
Design principles
Designed for platform separation
Xen gives platform teams a clear boundary between shared hardware and guest systems, keeping separation decisions visible.
Isolation boundaries
Reason about where guests are separated and where integration must be reviewed explicitly.
Guest ownership
Keep Linux guests, RTOS guests, service domains, and hardware-facing components accountable.
Resource assignment
Make CPU, memory, interrupt, and device assignment explicit platform design choices.
Boot and integration
Track startup order, control-domain choices, device setup, and integration responsibilities.
Platform control
Separate hardware-facing control from guest application environments where needed.
Long-term maintainability
Support lifecycles where guests, platform software, and hardware assumptions evolve at different rates.
Technical capabilities
Capabilities for mixed-criticality platform design
Once the separation model is clear, teams can evaluate Xen capabilities for ownership, timing, device access, and boot architecture.
CPU pinning
Assign CPU resources deliberately so latency-sensitive guests have explicit execution ownership.
Deterministic interrupt latencies
Design systems where interrupt routing, CPU assignment, and device ownership support deterministic interrupt latencies.
Device passthrough
Assign selected hardware devices directly to guests when the design calls for direct ownership.
Dom0less boot
Start selected guest domains without waiting for a traditional control-domain boot path.
Static resource partitioning
Make CPU, memory, device, and interrupt ownership part of the platform design.
Flexible control domains
Choose a control-domain model that fits the architecture instead of assuming one pattern.
Embedded platform breadth
The same separation model applies across embedded domains.
Xen can be evaluated wherever hardware-facing software, guest operating systems, and long-lived platform requirements share compute.
Industrial systems
Robotics
Medical and regulated devices
Edge appliances
Networking equipment
Specialized hardware platforms
Flagship embedded example
Software-defined vehicles make the separation challenge concrete.
Automotive platforms make the embedded challenge concrete: Linux systems, RTOS workloads, service domains, and hardware-specific functions increasingly share compute. Xen gives teams a thin layer for reasoning about isolation and ownership without treating one operating system as the whole platform.
ECU consolidation
Keep boundaries explicit as vehicle functions move toward shared compute.
Mixed workloads
Evaluate how IVI, service domains, Linux, RTOS workloads, and hardware-facing functions coexist.
Process tooling
The project also collaborates with BUGSENG on static analysis with ECLAIR, supporting MISRA C compliance efforts and ongoing code quality improvement.
Why architects choose Xen
Evaluation starts with architecture, evidence, and integration context.
After the separation model is clear, teams can evaluate Xen through architecture, isolation resources, guest model, governance, and public engineering process.
Thin hypervisor boundary
Xen gives platform teams a focused layer for separation decisions near hardware.
Hardware-aware isolation
Guest isolation and hardware-facing work stay visible instead of disappearing inside one OS.
Flexible guest model
Different operating environments can share a platform while retaining separate roles.
Open engineering model
Governance, contribution paths, security handling, and public testing resources are available for evaluation.
Long-lived maintainability
An open boundary helps teams plan products that must be inspected and updated over time.
Open platform ecosystem
Building complete embedded platforms
Most embedded products are built from multiple open source projects, not one operating system. Xen provides the virtualization and isolation boundary that lets Linux, Yocto Project, Zephyr, AGL, and platform software play complementary roles without hiding ownership or integration decisions.
Open platform composition
Software layer
Vehicle applications and services
Vehicle applications and platform services run above distinct guest environments.
- IVI
- Diagnostics
- OTA
- Fleet mgmt
Operating environments
Guest systems
Guest operating environments keep runtime and integration roles separate.
- Linux built with Yocto
- Zephyr / RTOS
- Service domains
Isolation boundary
Xen virtualization
Xen makes isolation and hardware ownership explicit.
- Isolation
- CPU scheduling
- Device ownership
Shared compute
Hardware / SoC platform
The SoC supplies the resources every layer composes around.
- CPU
- Memory
- Devices
A complete embedded or automotive platform can place applications and services above guest systems, use Xen as the virtualization and isolation layer, and run on shared hardware or SoC resources.
Core platform
Xen
Provides the virtualization and isolation boundary between guest systems and shared hardware.
Linux
Runs rich operating-system services, middleware, application environments, and integration tooling.
Zephyr
Supports RTOS-style embedded workloads that may need a smaller runtime than Linux.
Build and domain ecosystem
Yocto Project
Helps teams construct embedded Linux distributions and repeatable images for Linux guests.
Automotive Grade Linux
Provides an open automotive Linux platform for IVI and software-defined vehicle software stacks.
Hardware and SoC platform
Supplies the compute, memory, interrupts, devices, and peripherals the platform composes around.
Related resources
Follow the evaluation path from architecture to participation.
Use these project, technology, testing, and download entry points to continue evaluation.
Hypervisor
Start with the core Xen hypervisor project and architecture resources.
Architecture
See how Xen fits between hardware, guests, and platform control.
Isolation & Security
Review isolation and security resources for Xen-based platforms.
Safety-Critical Systems
Start with safety-oriented evaluation resources for Xen.
Continuous Integration
Explore hardware CI, test coverage, and bring-your-own-hardware resources.
Downloads
Find Xen releases for evaluation and development.
Ecosystem
Sustained by organizations working across open virtualization.
Xen is sustained by organizations working across infrastructure, hardware, embedded, automotive, and security-sensitive systems. Membership supports infrastructure, events, trademark stewardship, and ecosystem coordination.
Next step
Evaluate Xen for your platform, or help shape the work.
Start with architecture resources, documentation, CI, and community contribution paths, or support the project through membership.