As the current stubdomain based on minios is difficult to maintain, we have worked on a stubdomain based on Linux. This helps to use QEMU upsteam in the stubdom with little change. So first I will present how a Linux based stubdomain is built and lauched, and the difficulties around it. Then, to see if this is a viable option, I will show disk and network benchmarks to compare it with a traditional QEMU in dom0 configuration. To finish, I will present the current limitations of this type of stubdomains.

1. Linux based
Stub-domain
why, how and benchmark
Anthony PERARD
@ Citrix

2. "Normal" case
● Device Model (QEMU) in dom0

3. Solution: stub-domain
● The Device Model in its own domain

4. How to do it?
● Current one based on mini-os
○ use newlib
● But QEMU upstream need more
● So, two solutions:
○ Port another libc to mini-os
○ Linux based stubdom

5. What do we need?
● Change in Linux
○ Need to use dom0 privileged command (memory
mapping)
● QEMU
○ set_hvm_param DM_DOMAIN
○ no backend initialisation
● libXenLight
● initramfs

6. Status
● Can start a domain with both console and
network
● Stubdom memory: 40MB

7. TODO
● upstream those patches
● integrate it in Xen build system
● have a video working
● could reduce the size of the stubdom

8. Lies, damned lies, and
benchmarks
● With 8 CPU AMD Opteron, 8GB
● dom0: Arch Linux 64bit
● domU: Arch Linux 64bit, 2GB of RAM
● (kernel Linux 3.4.8)
● iperf for network
● dd for disk

9. benchmark - Network

10. benchmark - Disk

11. benchmark - Boot time
Between `xl create vm` and `ssh guest true`

12. Conclusion
● No more competition, priority inversion in
dom0
● Extra layer against security vulnerability in
QEMU
● Little impact on performance
● Should it be the default?

13. Question ?