Device driver paravirtualization: VM heaven or IT hell?

Paravirtualizing device drivers benefits virtual machines (VMs) and guest operating systems, but it comes with baggage. This tip defines the pros, cons and surprisingly lengthy lifespan of paravirtualization and paravirtualized drivers.

As virtualization technology becomes increasingly mainstream, IT managers and even workstation end users need to understand the finer points of virtualization. An area of keen interest is virtualization of hardware interfaces and, in particular, how to acquire, develop, manage and support both new and legacy device drivers in a virtual machine (VM) setting.

Virtualization one-day seminars:
There's a free, one-day virtualization seminar coming to a city near you. Click here for details.

As with application code, there are two approaches for deploying device drivers on VM platforms: "pure" virtualization and paravirtualization. Pure virtualization supports near-transparent execution of device driver code on a VM. General-purpose machine instructions execute natively and without intervention, while privileged operations -- instructions that affect hardware or operating systems' kernel state or those that access peripheral hardware directly -- trigger exceptions serviced by code in a VM.

Support for pure I/O virtualization requires support in silicon, as with AMD-V and input/output memory management unit (IOMMU), Intel's announced IVT-d technology, and a range of other legacy micro- and minicomputer architectures from IBM Corp. and others.

Absent such hardware assistance, VM architects, operating system suppliers and device driver developers turn to paravirtualization, wherein I/O code is optimized or wholly re-targeted for VM execution. At the simplest level, driver code is manually pre-processed or re-coded to remove privileged instructions and substitute VM application programming interfaces (APIs), or "hypercalls," in their place. In the most extreme case, existing driver code requires complete re-architecting.

There are several motivations for paravirtualizing device drivers:

  • a lack of support for full, "pure" virtualization in the underlying silicon and/or the VM platform (as in x86 lacking I/O memory management unit (IOMMU) and embedded architectures like Advanced RISC Machine (ARM), Microprocessor without Interlocked Pipeline Stages (MIPS) and so on);
  • the need to support a legacy driver in a new execution environment -- in this case, a virtualized one; and
  • the desire to optimize an existing driver or a new one for acceptable performance in a virtualized execution setting.

PC-AT "white box" virtualization platforms – such as VMware workstation products and Parallels from SWsoft -- present guest OSes with a set of generic virtual devices that mimic the core hardware platform definition established nearly two decades ago by IBM and Microsoft. That set includes familiar interfaces like integrated drive electronics (IDE), serial and parallel ports, and basic video graphics array (VGA) video, with more recently accrued interfaces for networking, USB and so forth.

A functional "pure" virtual machine platform must emulate the behavior -- memory or I/O address, word/byte size, states and, in some cases, timing -- and respond to device probing that occurs during guest OS installation. Paravirtualization of OS and drivers can eliminate the need for emulating either, which can speed installation, booting and throughput on the guest OS.

The behavior of an OS-hosted network interface device driver, for example, depends on the particulars of one of several networking chipsets that appear on actual system boards and network interface cards (NICs). While interrupt processing and read/write sequences of legacy driver code are optimized for device attributes and bus cycles of physical hardware, granularity of legacy operations can present major performance bottlenecks when a hypervisor intercedes to emulate that behavior. Through intelligent paravirtualization, a driver can be optimized or simplified to leverage streamlined VM APIs available to guest code. For an NIC driver, serial packet copying cab be optimized by hypercalls that perform virtual DMA direct memory access (DMA) and/or other hypercalls that subsume chunks of packet handling behavior.

Challenges to device driver paravirtualization As with native use, VM-based installation and execution of hardware interfaces is dependent on availability of device drivers specific to the hardware in question. The viability of an OS -- Linux, for example -- in a particular application or niche can hinge on driver ubiquity -- or lack thereof. The same is true for paravirtualization of drivers for particular VM platforms.

So while virtualization may be a "killer app," it suffers from many of the same woes as native operating systems, and paravirtualization presents its own challenges, some of which we detail below.

  • The availability of device driver versions for a particular guest OS. If a driver isn't available for Linux or Windows or Berkeley Software Distribution (BSD), for example, virtualization won't help.

  • The complexity of device drivers and OS architecture dependencies. The majority of device drivers are not simple, stateless interrupt-service routines that perform character I/O on memory-mapped devices. Many use complex scatter/gather direct memory access (DMA), invoke deferred execution (e.g., Linux tasklets and Windows deferred procedure calls, or DPC) or are intimately tied to OS subsystems, especially networking and disk I/O. This complexity can mean that paravirtualization entails nontrivial -- that is, costly -- porting and re-architecting.

  • Access to source code for needed devices drivers. As with any kind of porting, paravirtualization usually requires access to source code. As Linux users and open source developers have learned, device manufacturers and competing OS vendors usually treat device specifications and driver source code as closely held intellectual property.

  • Incompatible notions of abstraction. Some OSes offer or enforce their own abstractions for system resources, implemented with macros, complex data structures, and kernel APIs. While masking detail and employing other object-oriented programming practices can enhance portability of user applications, it often complicates maintenance and migration of system-level code. Since hypercalls are themselves a form of abstraction, mapping OS-specific -- and/or OS-generic -- abstractions onto hypercalls can devolve into a frustratingly nebulous exercise.

  • Forking and deprecation of hypercall APIs. OS device driver interfaces change over time, and so do hypercall APIs. While VMware may offer the dominant commercial VM technology, numerous other open and closed VMs exist as well (such as Xen, Linux kernel-based virtual machines, Parallels, embedded VMs). How can IT professionals determine which combination of VM and OS versions is optimal for their application?

  • Competing versions of paravirtualized drivers. Device drivers typically emerge from multiple sources: from OS vendors and communities around them -- such as open source software and commercial ecosystems -- from silicon suppliers and computer manufacturers writing drivers for their own hardware; and for paravirtualized drivers, from VM suppliers. Given the increasing ubiquity of VM technology, multiple paravirtualized drivers can emerge from any of these sources, compounding the complexity of deploying and maintaining virtualized software and hardware assets.
  • Availability, utility and longevity of hardware virtualization support. AMD and Intel offer comparable but different competing application virtualization support in their silicon, and the situation appears to be repeating itself for I/O virtualization. It will take several years, however, for these I/O technologies to reach mainstream deployment volumes, if they ever do.
  • It is unlikely that AMD-V and IVT-d will wholly displace the need for paravirtualization in drivers anytime soon. Furthermore, critics compare emerging I/O virtualization technology to other first-generation Intel architecture features that did not survive, such as task switch support, whose brief usage was eclipsed by simpler hardware assist for software operations.

    As with other advances in IT, the virtualization devil lies in the details. There is no question that virtualization liberates IT managers from the tyranny of single OSes and hardware platforms, but it presents its own challenges and dependencies. In particular, device drivers present costs with virtualization. Even with emerging I/O virtualization technology, paravirtualization of low-level, value-added systems code will remain central to the strategies of OSVs and hardware suppliers. As a result, for the short and the midterm, IT managers need to monitor the progress and evolution of driver paravirtualization technology and the business around it.

    About the author: Bill Weinberg is an independent analyst for Linuxpundit.com and serves in a part-time executive capacity for Linux Phone Standards Forum (LiPS). Previously, at Open Source Development Labs (OSDL) he served as senior technology analyst and also managed the OSDL Mobile Linux and Carrier Grade Linux initiatives. Prior to OSDL, Weinberg was a founding member of MontaVista Software, helping to pioneer and ultimately to establish Linux as the leading platform for intelligent devices.

Dig Deeper on Virtual machine provisioning and configuration