virtio: Towards a De-Facto Standard For Virtual I/O Devices
Rusty Russell
IBM OzLabs
8 Brisbane Ave
Canberra, Australia
rusty@au.ibm.com
ABSTRACT
The Linux Kernel currently supp or ts at least 8 distinct vir-
tualization systems: Xen, KVM, VMware’s VMI, IBM’s Sys-
tem p, IBM’s System z, User Mode Linux, lguest and IBM’s
legacy iSeries. It seems likely that more such systems will
app ear, and until recently each of these had its own block,
network, console and other drivers with varying features and
optimizations.
The attempt to address this is virtio: a series of efficient,
well-maintained Linux drivers which can be adapted for vari-
ous different hypervisor implementations using a shim layer.
This includes a simple extensible feature mechanism for each
driver. We also provide an obvious ring buffer transport im-
plementation called vring, which is currently used by KVM
and lguest. This has the subtle effect of providing a path
of least resistance for any new hypervisors: supp or ting this
efficient transport mechanism will immediately reduce the
amount of work which needs to be done. Finally, we pro-
vide an implementation which presents the vring transport
and device configuration as a PCI device: this means guest
op erating systems merely need a new PCI driver, and hy-
p ervisors need only add vring support to the virtual devices
they implement (currently only KVM does this).
This paper will describe the virtio API layer as implemented
in Linux, then the vring implementation, and finally its em-
b odiment in a PC I device for simple adoption on otherwise
fully-virtualized guests. We’ll wrap up with some of the pre-
liminary work to integrate this I/O mechanism deeper into
the Linux host kernel.
General Terms
Virtio, vring, virtio pci
Keywords
Virtualization, I/O, ring buffer, Linux, KVM, lguest
1. INTRODUCTION
The Linux kernel has been ported to a huge number of plat-
forms; the official kernel tree contains 24 separate architec-
ture directories and almost 2 million lines of architecture-
sp ecific code out of 8.4 million. Most of these architectures
contain support for multiple platform variants. Unfortu-
nately we are aware of only one platform which has been
deleted from the tree (as the last machine of its kind was
destroyed) while new hardware variants sprout like weeds
after a rain. With around 10,000 lines changing every day,
the kernel has at least one of everything you can imagine.
When we look at Linux as a guest under virtualization, we
are particularly blessed: IBM’s System p, System z and
legacy iSeries are all supported. User Mode Linux[4] has
long been included, for running Linux as a userspace process
on Power, IA64 and 32 and 64 bit x86 machines. In the last
two years the x86 architecture has proven particularly fe-
cund, with support for Xen[2] from XenSource, VMI[1] from
VMware and KVM[5] from Qumranet. Last and least, we
should mention my own contribution to this mess, lguest[7]:
a toy hypervisor which is useful for development and teach-
ing and snuck quietly into the tree last year.
Each of these eight platforms want their own block, n et-
work and console drivers, and sometimes a boutique frame-
buffer, USB controller, host filesystem and virtual kitchen
sink controller. Few of them have optimized their drivers in
any significant way, and offer overlapping but often slightly
different sets of features. Importantly, no-one seems par-
ticularly delighted with their drivers, or having to maintain
them.
This question b ecame particularly pertinent as the KVM
project, which garnered much attention when it burst onto
the Linux scene in late 2006, did not yet have a paravirtual
device model. The performance limitations of emulating de-
vices were becoming clear[6], and yet the prospect of either
adopting the very-Xen-centric driver model was almost as
unapp ealing as developing Yet Another driver model. Hav-
ing worked on the Xen device model, we believe it possible to
create a general virtual I/O mechanism which is efficient[14],
works on multiple hypervisors and platforms, and atones for
Rusty’s involvement with the Xen device configuration sys-
tem.
2. VIRTIO: THE THREE GOALS
Our initial goal of driver unification is fairly straight-forward:
all the work is inside the Linux kernel so there’s no need for