This article originally appeared on lwn.net. Suppose you have a program running on your system that you don’t quite trust. Maybe it’s a program submitted by a student to an automated grading system. Or maybe it’s a QEMU device model running in a Xen control domain
Xen on ARM is becoming more and more widespread in embedded environments. In these contexts, Xen is employed as a single solution to partition the system into multiple domains, fully isolated from each other, and with different levels of trust. Every embedded scenario is different, but many require real-time guarantees.
One of the challenges of using Xen in embedded environments is the need for core components to meet critical timing requirements. In traditional implementations engineers use real-time operating systems (RTOS) to ensure, for example, that an automobile’s brakes engage within a reasonable amount of time after the driver presses
Background: Introduction to Xen PV Bootloaders In the very early days of Xen it was necessary for the host (domain 0) administrator to explicitly supply a kernel (and perhaps initial ramdisk) from the domain 0 filesystem in order to start a new guest. This mostly worked and for some use
A few weeks ago, I went onto a road trip to China with the aim to meet Xen Project users as well as contributors. When I was planning the trip, it became apparent that many of the developers in China are new to the project and had difficulties with Xen