Virtualizing Resources for the Cloud - Large Scale and Big Data: Processing and Management - page 522

Process rocess Process Process Process rocess

Guest OS Guest OS

Device drivers

Device drivers

Virtual
devices

Virtual
processor(s)

Virtual
devices

Virtual
processor(s)

Hypervisor

Device drivers

Physical devices Physical processor(s)

FIGURE 16.23 Logical locations of device drivers within multiple guest OSs in native sys-
tem VMs sharing a single hardware machine.

are all sensitive, thus need to be controlled by the hypervisor. Clearly, this would
necessitate a trap to the hypervisor per every I/O request. I/O requests are all privi-
leged, whether issued using I/O instructions or memory-mapped I/O, hence, they
are not critical instructions and can naturally trap to the hypervisor. In principle, the
hypervisor can intercept I/O requests at any of the three interfaces: the system call
interface, the device driver interface, or the operation level interface.
If the hypervisor intercepts an I/O request at the operation level interface, some
essential information about the I/O action might be lost. In particular, when an
I/O request arrives at the device driver interface, it might get transformed into a
sequence of instructions. For instance, a disk write is usually transformed into multi-
ple store instructions, thus when received at the operation level interface, it becomes
difficult on the hypervisor to identify the instructions as belonging to a single write
request. As such, intercepting I/O requests at the operation level interface is typi-
cally avoided. In contrast, intercepting an I/O request at the device driver interface
allows the hypervisor to efficiently map the request to the respective physical device
and transmit it via the operation level interface. Clearly, this is a natural point to
virtualize I/O devices; yet would oblige hypervisor developers to learn about all the
device driver interfaces of various guest OSs so as to encode the approach. Finally,
intercepting I/O requests at the system call interface (i.e., the ABI), might theoreti-
cally make the I/O virtualization process easier, whereby every I/O request can be
entirely handled by the hypervisor (the solo controller in this case). To achieve that,
however, the hypervisor has to emulate the ABI routines of every guest OS (different
OSs have different ABI routines). Consequently, hypervisor developers need again
to learn about the internals of every potential guest OS. Alongside, emulating ABI
routines can degrade system performance due to the overhead imposed by the emu-
lation process. To this end, intercepting I/O requests at the device driver interface is
usually the most efficient approach, thus normally followed.