1MODUS 2008

Customizable Multimedia Devices in

Virtual Environments

Ankur Pai, Bala Seshasayee,

Himanshu Raj, Karsten Schwan

Center for Experimental Research in Computer Systems,

Georgia Institute of Technology, Atlanta

2MODUS 2008

Why Customizable Devices ?

• Improving mobile platforms (1GHz ARM processors)

• Mobile virtualization enabling VM migration

– Xen on ARM (Samsung, UBC, Montavista)

– L4 on ARM (UNSW, UIUC, Motorola)

• Diversity of devices and sensors

• Smart devices

– Active disks [ASPLOS ‘98]

– Smart cameras [IEEE Computer ‘02]

• Uniform access to VMs independent of device

capability

3MODUS 2008

Opportunities

• VMs may not be aware of all features in all devices

• Migrating VMs may be unchanged, irrespective of

changing devices underneath

• Offloading of processing to smart devices when

possible

• More efficient use of remote sensors

4MODUS 2008

Virtualization – Overview

Kernel <-> Hypervisor Interface

Hardware Platform

Hypervisor

Logical Partition Logical Partition Logical Partition Logical Partition

Hardware <-> Hypervisor Interface

5MODUS 2008

Multimedia Virtualization Service: VMedia

MultimediaApplication

VMediaFrontend

V4L API

domU

User

Kernel

dom0

VMediaBackend

MediaGraph &VMedia Control

Physical Dev. Access

PhysicalDevice

6MODUS 2008

Functionality Sharing via MediaGraph

MediaGraph handles physical to virtual device formats

640 X 480, color

640 X 480, color 320 X 240, grey

Downscaling

Physical Device

Virtual Device

MediaGraph

Transformations

Greyscaling

VM 1 VM 2

7MODUS 2008

EVPath Middleware Toolkit

• MediaGraph realized using EVPath

• Stones

– Queue

– Handle event processing

• Edges

– Connect stones, cause data flow

– Remote or local

• Code can be associated to a stone dynamically

– Binary generated from ECL source

– In-memory lexer, parser, code generator

8MODUS 2008

EVPath Middleware Toolkit

• MediaGraph realized using EVPath

• Stones

– Queue

– Handle event processing

• Edges

– Connect stones, cause data flow

– Remote or local

• Code can be associated to a stone dynamically

– Binary generated from ECL source

– In-memory lexer, parser, code generator

9MODUS 2008

CustomCam – Customizable Camera

• ECL code’s return value determines if message is dropped

• Interface: set/get custom code fragments via ioctl()

10MODUS 2008

Code Isolation and Accounting

• Isolation

– New process spawned for each custom code

– Advantage: process-level protection

– Disadvantage: address space crossings

• Accounting

– Using getrusage() to monitor process costs

– Updates corresponding VM’s counters in the VMM using

hypercalls

11MODUS 2008

Improved Sharing and Remote Access

● VM’s interested in sharing their code notify backend

via an ioctl() call● Mutually trusting

● Opportunity to share same code● Identifying same functionality

● Code compare, IR compare, signature

● Shared libraries

12MODUS 2008

Experimental Evaluation

• 3.2GHz dual-core Pentium-D processor

● 3GB RAM

● Xen 3.0.3, dom0 memory = 512MB

● Kensington SE401 USB camera

● Linux 2.6.16, Video4Linux

13MODUS 2008

ioctl() costs

● Total cost ~ 16ms

● Dominated by process creation

Process Creation

EVPath

Miscellaneous

14MODUS 2008

Cost comparison

15MODUS 2008

Experimental Evaluation - Jitter

16MODUS 2008

Experimental Evaluation – Sharing

17MODUS 2008

Related Work

• Active Messages

– Code injected into routers for app-specific network functionality

• Smart Messages

– Messages carry data and processing information

• Kernel Plugins

– Allows user-specified code to be run in kernel safely

• Device driver isolation

– For restarting defective drivers (Nooks project)

– On the L4, for fault isolation

18MODUS 2008

Conclusions

• Device customization in virtualized systems

• Uniform interface to devices

• Better use of smart devices

• Data filtering at source

• Implementation with a camera device