Device Driver Reliability - Advanced Operating Systems and Kernel Applications - page 41

In addition, UMDF does not support drivers
requiring interrupt handling, because Windows
cannot field interrupts at user level. Drivers also
cannot use DMA, because a driver could bypass
kernel memory protection. These three limitations
restrict UMDF drivers to devices accessed over
serial ports, USB buses, or a network. In addition,
drivers accessed internally within the kernel, such
as storage and network devices, cannot be sup-
ported. Thus, UMDF supports portable storage
devices, such as PDAs and cell phones, portable
media players, USB bulk transfer devices, and
auxiliary display/video devices, but not network
devices or hard disks.

to be used. Figure 10(b) illustrates the UMDF
architecture.
Like Nooks, executing driver code at user
level with UIO isolates the kernel from driver
bugs. However, UIO has substantial limitations
not present with Nooks. First, UIO is only avail-
able for devices with a character interface, but not
block or network interfaces. Second, UIO pro-
vides no fault-detection or recover mechanisms.
Finally, UIO requires writing new driver, so does
not preserve the existing investment in drivers.
Nonetheless, the UIO framework is compact,
consisting of 800 lines of code, and can isolate
the kernel from the failure of drivers.

Linux UIO xen hypervisor drivers

Starting with the 2.6.23 kernel, Linux includes the
Userspace I/O (UIO) driver model that can execute
some driver code in user mode (Koch, 2008). With
UIO, drivers consist of a kernel module containing
an interrupt handler and a user-level library for
the remainder of the driver. At startup, a kernel
module registers an interrupt handler and a list of
I/O memory addresses with the UIO manager. The
UIO manager exports this information through
an entry named in the /dev/uioX, where X is the
index of the device. Reading from the device file
returns the number of interrupts since it was last
read, or blocks if there have been none. Memory
mapping the device file provides access to the
device's memory regions.
In the UIO driver model, all driver functional-
ity except dismissing interrupts executes at user
level. The kernel portion of a UIO driver is solely
responsible for telling the device to stop interrupt-
ing, at which point it signals that the user-level
driver should execute. The driver model provides
no specific API to access device functionality;
the driver code may be linked directly in with
applications. As a result, UIO drivers cannot be
accessed through standard file system interface,
and therefore require changes to application code

Virtual machines raise unique issues for I/O. Most
virtual machine monitors and hypervisors virtual-
ize devices to share them between multiple guest
virtual machines (Barham et al, 2003, and Fraser
et al, 2004). As a result, guest operating systems
talk to a virtual device rather than communicating
directly with a physical device. In some virtual
machine monitor architectures, device drivers
execute within the virtual machine monitor it-
self. This poses the same reliability problems
as executing drivers unprotected within an OS
kernel, as a driver failure may cause the VMM
and all guest VMs to crash. Hosted VMMs rely
on a host operating system for device access. In
this architecture, too, the failure of a driver can
lead the host OS, the VMM, and all guest virtual
machines to crash.
The Xen hypervisor addresses this problem
by executing device drivers in virtual machines,
rather than within the hypervisor. As shown in
Figure 11, the guest OS kernel runs a virtual
driver that exports an interface identical to a real
device driver. Like shadow drivers, a virtual driver
represents a class of devices, such as a network
interface card. Thus, only one virtual driver is
required per class. Instead of using processor