Customizable Multimedia Devices in Virtual Environments

Customizable Multimedia Devices in Virtual Environments Ankur Pai, Balasubramanian Seshasayee, Himanshu Raj and Karsten Schwan Center for Experimental Research in Computer Systems Georgia Institute of Technology Atlanta, Georgia 30332–0250 fpaiankur, bala, rhim, [email protected] Abstract—The separation of logical from physical devices maintain a consistent view of physical devices by presenting provided by modern virtualization techniques can be used to only a common minimal set of device features is too limiting enhance device functionality, including by emulating non-native and worse, it cannot account for changes in the environmental device functions in software. Such logically extended devices are particularly promising in the mobile domain, for embedded conditions or contexts in which devices are used. machines, handhelds, or phones. Challenges arise, however, from We argue that device sharing and interoperation in mobile the highly heterogeneous nature of portables and the devices with systems requires models and interfaces with which virtual- which they can interact. This suggests that device extensions ization infrastructures can dynamically change device func- should be dynamic, varied at runtime to adjust to new user needs and/or changes in environmental conditions. This paper tionality to account for runtime changes in device use, con- presents a model for runtime device extension and for then using ditions, and contexts. This paper presents such a model. It such extended devices. The model provides uniform interfaces to implements the safe, runtime extension of device functionality, native and extended devices, permits the safe runtime extension by enabling the virtualization layer, guest operating systems, of device functionality, and can be shown to operate across both or applications to safely specify and deploy custom code that stationary and mobile platforms, and arbitrary operating systems and applications. The model is implemented with the Xen virtual runs in conjunction with device accesses. This approach entails machine monitor (VMM) and shown useful for a Video4Linux a number of benefits, as detailed below: (V4L) multimedia device used by applications. Enhancements of • device functionality implemented in this context include image It provides a uniform view of devices to VMs, indepen- filtering and routing to remote clients, for camera devices using dent of the physical host. For instance, a TCP network V4L drivers and for applications using V4L, with small costs device may be implemented in software, by providing the incurred for runtime extension and/or changes to the logical TCP stack to the virtualization layer, or in hardware, by device, and with moderate execution costs exploiting the TCP offloading functions of an enhanced I. INTRODUCTION network interface [7]. The VMs using such a device need not be cognizant of how the TCP device is realized. Virtualization techniques enable a single device to be shared • It can be tuned to available hardware resources. For among several virtual machines (VMs), by deciding, at the instance, in the previous example, a node lacking a driver layer, how requests made to the virtual device are network interface supporting the offloading feature may mapped to the underlying physical platform. These decisions instead have a coprocessor that can be used to implement can be made without knowledge of the applications and the feature [3], without the VM being aware of this fact. operating systems using these devices, thereby ensuring porta- • It enables efficient use of remote devices. For instance, bility and interoperability without changes to participating an imaging application that requires only those frames systems and applications. Furthermore, this approach makes captured by a remote camera that contain specific fea- it possible to emulate, in software, devices that may not be tures can provide feature selection code that determines present physically [1], to transparently route requests to remote said features. Such an extension can use this code to devices when local ones are not available [2], and to even filter traffic, providing only the frames of interest to improve the functionality of physical devices by enhancing the application, thereby reducing communication and their virtual realization [3], [4]. computational overheads experienced by the application This paper addresses device sharing and interoperation in and the platform on which it runs [8]. the mobile domain, where challenges for device emulation • It opens up new possibilities for sharing device func- and extension are due to the diversity of actual devices, of tionality. Extending the previous example, when multiple device capabilities, and of the contexts in which they operate. VMs are interested in the same image features, common Additional challenges in the mobile domain are caused by the data can be shared at the device driver layer itself. fact that virtual machine migration, an important function in virtualized systems, will be difficult [5] without functionality A known problem associated with the runtime extension in addition to that provided by commercial products for data of system-level software by applications is safety [9], where centers [6]. For instance, an approach that allows VMs to faulty or even malicious code injected by applications into the Fig. 1. VMedia Architecture system layer can affect the behavior of other VMs that rely of the underlying hardware used to access the physical de- on the system. In our implementation, termed CustomCam, vice (such as PCI, USB, etc., or even network-based remote we use the split device driver model afforded by the Xen cameras), and instead, via V4L calls. The MediaGraph ab- hypervisor, on which we implement an overlay-based mid- straction used in VMedia further enhances this approach by dleware framework in the device backend (i.e., in the device allowing flexible mappings to be performed between logical driver layer). This middleware permits the runtime extension and physical devices. For instance, the size of a captured of overlay functions by allowing arbitrary code fragments to image may be enhanced by using concatenated images from be included into the overlay, i.e., into the device feature set, two physical cameras. MediaGraph also encourages increased at any time deemed appropriate by the application. Safety sharing among VMs, where based on the type of images is attained by use of dynamic code generation, where code desired by several VMs, opportunities to share the images fragments specified in a safe subset of the C language [10], are exploited by performing software-based transforms on and runtime binary code generation guarantees that such code captured images, thus reducing contention on the physical cannot damage other elements of the device driver layer. Ex- device. perimental results indicate that the cost of setting and resetting VMedia uses the Xen split driver model to separate logical such custom code is small (16ms and 1.2ms, respectively, from physical devices. As shown in Figure 1, it has a logical for the codes used in our experimentation). Further, running V4L-based video device driver as a frontend within each guest the custom code in the driver layer does not add significant domain, and a backend running in the service domain. Xen overheads to the layer's execution. Results also show that links frontend and backend via an efficient messaging system, sharing custom codes among multiple applications and the termed event channels, and data transfers are carried out using VMs that run them can yield savings compared to domain- shared pages. The backend interacts with the physical device level implementations of such functions. and provides device data to the frontend. In VMedia, the The remainder of the paper is organized as follows. Sec- backend uses the EV(ent)Path [11] overlay-based middleware tion II overviews VMedia, followed by Section III, which framework to implement the communication and computation discusses the architecture of CustomCam. Isolation and shar- actions necessary to extend Xen's basic virtualized devices to ing properties of CustomCam are discussed in Sections IV our device model. With this middleware, device accesses are and V respectively. Section VI discusses typical usage sce- performed via overlay graphs composed of software entities, narios for CustomCam, and experimental results are shown in termed `stones', that handle and process device messages Section VII. Related work is covered in Section VIII, while (events) traversing the overlay linking backend to physical Section IX concludes the paper. device. With EVPath and in contrast to Xen's event-based VM- VM communication mechanism, linkages between stones can II. VMEDIA OVERVIEW extend across multiple machines and as stated above, compu- CustomCam is built on top of the VMedia framework tations can be performed as events traverse the overlay. In this ( [4]). VMedia is a multimedia sharing framework that presents fashion, higher level services or applications are composed as logical video devices to VMs, via the standard V4L interface. sets of computations that can filter events, forward them, or Consequently, device virtualization is carried out independent transform them. Because these computations are specified in ECL (a subset of the C language supporting loop, conditional, In addition to the isolation mechanism, guest VMs can also and return statements), they can serve the needs of individual benefit from recovery functionality. To

Load more