The
traditional device driver model was extended to support I/O virtualization in
several different ways:
l
Legacy device drivers are used in fully virtualized systems, based on
device emulation [2]. The hypervisor traps the device accesses (such as
memory-mapped IO operations) and converts them to operations on a real device,
which may be different from the emulated device. This approach does not require
changes to the guest OS, at the cost of significant performance degradation due
to frequent context switches between the VM and the hypervisor.
l
Para-virtualized (``virtual'') I/O drivers are hypervisoraware I/O
drivers, installed in the guest OS [3, 4, 5]. A paravirtualized driver
communicates with the real device driver running outside the guest; the level
of abstraction is raised from low-level bus operations (such as MMIO) to
device-level operations (such as “send a packet”). The performance of
paravirtual solution is significantly better compared to device emulation, but
still far from native [6].
l
Direct access (also known as pass-through access) device drivers provide
guest access to real hardware. A device is dedicated to the guest, which
interacts directly with the device, without a software intermediary. This
significantly improves performance compared to device emulation or
para-virtualized drivers. However, this approach in fact does not virtualize
the I/O. The vendor-specific device driver is executed within the guest, which
preserves the traditional driver-related problems (such as high development
cost and stability issues). Direct access also poses challenges to many aspects
of virtualization, in particular it significantly complicates live migration
[7, 8, 21].
l
Self-virtualizing devices [9, 10, 18, 20] allow direct access interface to
multiple VMs; logically, several devices of the same type are packaged
together. Since the device driver within the quest OS interacts with the hardware
directly, a self-virtualizing device (as a direct-access device) does not
really virtualize the I/O. In addition, even though the hardware allows I/O
sharing, the supported number of the virtual devices (and accordingly the
number of VMs sharing the device) is typically very low, since the
self-virtualization support has significant impact on hardware size per virtual
interface. Accordingly, this solution scales poorly, while the device cost is
significantly increased.