The Definitive Guide to Xen Hypervisor - David Chisnall
https://docs.saferwall.com/blog/virtualization-internals-part-3-xen-and-paravirtualization/
XenBus (Approach to Device Drivers)
Xen light library (libxl) - Swiss army knife for administrating
CODE OVERVIEW:
some pointers in the source:
xen/xen/include/public/xen.hwill give you a list of all the hypercalls with comments what they do.xen/xen/include/xen/mm.hgives you an introduction to the different memory terminology used by Xen (i.e., real versus virtualized addresses and page numbers). If you don’t grasp these differences, then reading the hypervisor code will surely be frustrating.xen/xen/include/asm-x86/config.hgives an overview of the memory layout of Xen.xen/tools/libxc/xenctrl.hexports a large list of interesting domain control operations, which gives an abstract view of task division between Dom0 and the hypervisor.
MEMORY:
- Xen uses 2-stage translation in the MMU to assign memory to virtual machines
- Dom0, or domain zero to expand the abbreviation, is the first domain started by the Xen hypervisor on boot. It has special privileges, like being able to cause new domains to start, and being able to access the hardware directly.
CPU:
- Xen runs entirely and only in hypervisor mode
- Xen leaves kernel mode for the guest operating system kernel and EL0 for guest user space applications. Type-2 hypervisors need to frequently switch between hypervisor mode and kernel mode. By running entirely in EL2 Xen significantly reduces the number of context switches required.
- Xen uses generic timers to receive timer interrupts as well as injecting timer interrupts and exposing the counter to virtual machines
- Xen uses the GIC to receive interrupts as well as injecting interrupts into guests
PERIPHERALS
Xen discovers the hardware via device tree. It assigns all the devices that it does not use to Dom0 by remapping the corresponding MMIO regions and interrupts.
- The
PV Frontendsconnect to thePV Backendsusing a simple ring protocol over a shared page in memory. - Even though it is the most common configuration, there is no reasons to run all the device drivers and all the paravirtualized backends in Dom0. The Xen architecture allows driver domains: unprivileged virtual machines with the only purpose of running the driver and the paravirtualized backend for one class of devices.
- Even if a malicious guest manages to take over the paravirtualized network backend and the network driver domain, it would not be able to take over the entire system. Driver domains also improve isolation and resilience: the network driver domain is fully isolated from the disk driver domains and Dom0
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper
https://wiki.xenproject.org/wiki/Tuning_Xen_for_Performance