Existing I/O Virtualization Approaches

rel="File-List" href="file:///C:%5CDOCUME%7E1%5Cblu2%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml">

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.