QEMU disaggreagation

Registered by sstabellini

A key characteristic of the Xen architecture is the ability of running multiple service domains to provide device drivers and PV backends. In Xen jargon these are called "driver domains" and you can have one for the disk, one for the network, etc.

Driver domains can be Linux, or any other Operating Systems, they don't have to be fully privileged and can be restarted without rebooting the host. They provide advantages in terms of security, scalability and reliability, not to mention giving the user a broad spectrum of choices.

The next step forward to improve the flexibility of the Xen architecture is disaggregating the device model. Traditionally the emulated hardware that a guest VM can access is always provided by a single process (QEMU) in a single service domain (usually dom0) or a stubdomain. Having the ability of running multiple QEMU instances per VM, each of them in a separate service domain and emulating a different set of hardware, would allow us to further enhance the benefits introduced by driver domains. For example we could have one QEMU emulating a SATA controller in the disk driver domain and another one emulating everything else in a stubdomain: it would allow us to concentrate all the disk configurations in a single VM, tightening the access control list to the disk and improving performances by shortening the IO path. The same could be done for network, having one QEMU emulating a network card in the network driver domain.

This talk will explain in details why having more than a one device model is advantageous, and how it will be accomplished without twisting QEMU's architecture.

Topic Lead: Stefano Stabellini
Stefano is a Senior Software Engineer at Citrix, working on the Open Source Xen Platform team. He has been working on Xen since 2007, focusing on several different projects, spanning from Qemu to the Linux kernel. He currently maintains libxenlight, Xen support in Qemu and PV on HVM in the Linux kernel. Before joining Citrix he was a researcher at the Institute for Human and Machine Cognition, working on mobile ad hoc networks.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.