This project focuses on developing an integrated digital cockpit system based on the Xen hypervisor. By leveraging virtualization, the system consolidates multiple automotive functions—such as Instrument cluster, Head unit—onto a single hardware platform. The use of a hypervisor ensures robust isolation, security, and resource efficiency, aiming to enhance both the user experience and system reliability in next-generation vehicles. Here is the detailed explanation of this project
The Xen hypervisor is an open-source, type-1 hypervisor that enables multiple independent operating systems(domains) to run concurrently on a single hardware system. This architecture allows each domain to be strictly isolated, significantly improving both safety and security.
Key features of Hypervisor-Based Architecture
- Domain Isolation: Safety-critical and non-safety functions are logically separated, ensuring that faults in one domain do not affect others
- Resource Efficiency: Hardware resources are dynamically allocated and managed for maximum system efficiency
- Type-1 Hypervisor: Runs directly on the hardware (bare metal), not on top of an operating system.
- Dom0: The first domain (privileged), responsible for managing hardware and creating other guest domains.
- DomU: Unprivileged guest domains running user operating systems.
- Virtualization Types: Supports Paravirtualization (PV), Hardware-assisted Virtualization (HVM), and PVH (hybrid).
- Dom0: Controls the PiRacer hardware and accesses the physical display via VNC.
- DomU1 (HU): Runs the Head Unit Qt application.
- DomU2 (IC): Runs the Instrument Cluster Qt application.
To enable Xen in your Yocto-based image, follow these steps:
Ensure you have the meta-virtualization layer in your Yocto workspace. Add it to your bblayers.conf:
BBLAYERS += "/path/to/meta-virtualization"Append Xen-related features to your distro:
DISTRO_FEATURES:append = " virtualization xen"Note: Tigervnc cannot be used with Wayland, as it is based on X11.
To run Xen properly, both Dom0 and DomU kernels must be configured with Xen-compatible options.
Dom0 must support Xen backend drivers and hypervisor communication features. Make sure the following kernel options are enabled:
- CONFIG_XEN_DOM0
- CONFIG_XEN
- CONFIG_BRIDGE
- CONFIG_PHY_BROADCOM
- CONFIG_XEN_BLKDEV_BACKEND
- CONFIG_XEN_GNTDEV
- CONFIG_XEN_DEV_EVTCHNDomU images require frontend drivers and PVH support:
- CONFIG_XEN
- CONFIG_XEN_NETDEV_FRONTEND
- CONFIG_XEN_BLKDEV_FRONTEND
- CONFIG_HVC_XEN
- CONFIG_PARAVIRT
- CONFIG_XEN_PVH To launch a DomU domain, create a configuration file like the following:
Belowed code is domic.cfg
kernel = "/home/root/IcImage"
cmdline = "console=hvc0 earlyprintk=xen sync_console root=/dev/xvda"
memory = "512"
name = "ic"
vcpus = 1
serial = "pty"
disk = [ 'file:/home/root/IC.ext3,xvda,w' ]
vif = [ 'mac=00:11:22:66:88:33,bridge=natbr0' ]Replace IcImage with your custom kernel image and IC.ext3 with your root filesystem.
Then launch the domain from Dom0 using:
xl create -c ic.cfgMake sure both the kernel image and the root filesystem (ext3) exist on the Dom0 filesystem before running this command.
Vchan is a communication mechanism in Xen environments that enables high speed, low latency inter-domain communication. It’s built on shared memory and event channels, using grant tables to securely grant memory access between domains.
Why we using vchan?
It is lightweight, no extra daemons or protocols are needed and it’s fully integrated into the Xen ecosystem. Based on these advantages, we chose vchan as an alternative to conventional communication protocols like CAN and VSOME/IP.
vchan communication structure
- Grant table: allow a domain to securely share memory pages with another domain by storing access permissions.
- Event channel: provides interrupt-based signal for real-time responsiveness during data transmission.
- Xenstore: manages communication channel setup and shared memory information between domains.
Eunji Lee 
|
Seungjoo Kim 
|
Soonwoong Kim 
|