Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines

1. Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines • J. LeVasseur • V. Uhlig • J. Stoess • S. G¨otz • University of Karlsruhe, Germany • Presented by: Aaron BeachNorthwestern University

2. Outline • 1. Intro • 2. General Approach to Driver Re-use • - Basic Principles • - Architecture and Design Overview • - The Virtual Machine • 3. Evaluation • - CPU and memory overhead • - Comparison with native Linux

3. Intro • Basic idea: • - Run device drivers within their native OS in a virtual machine. • - Provide easy interface for client OS to use • Why reuse driver code (or binary) • - Device driver code accounts for a large percentage of total operating system code • - Can enforce proper protection and modularity between device drivers and OS

4. Driver Design • 1. Basic Principles • 2. Architecture and Design Overview • 3. The Virtual Machine • 4. More Design Features • 5. Biggest Design Issues • - Memory • - I/O • - Other Problems (timing, Sharing Resources)

5. Driver DesignBasic Principles for Reuse • Resource Delegation • - Bulk Resources only, page level easier to standardize • Separation of Name Spaces • - Within its own address space (proper protection) • Separation of Privilege • Secure Isolation • - Proper memory management, careful sharing • Common API • - General necessity of reuse and standardization

6. ArchitectureDesign Overview • DD/OS • - Device Driver OS • Virtual Machines • - Protection and Abstraction domain • Client • - Uses Drivers via through the VM • Translation Module • - The interface (glue) between client and the DD/OS

7. The Virtual Machine • The “Hyperviser” • - Base kernel with ultimate privileges • The VMM • - Virtualization layer, actually manages the Vms • Device Management is direct (pass-through) • - i.e. VM-OS is given direct access to devices • OS -> Device • OS <- VM <- Translation Module <- Client

8. Design Features:Client and Dependability • Client interface provided by translation module • - Uses interrupts to be invoked and to respond • Modularity • - Device failure and crashes are contained within VM • - VM can be rebooted • VM Isolation • - VM enforces isolation, even if device does not

9. Issue: Memory • DMA and VMM address translation • - DMA can't work directly in a VM because there is an extra layer of address translation and the DMA would try to directly access the wrong memory • Solutions? • - DMA address translation is always done by VMM • - To give VM direct access to DMA, then the VM must be mapped directly to hardware addresses • This creates a conflict of performance vs trust • - If there is trust then less protection is needed • - Otherwise, Translation must be used and the translations must stay constant during DMA... • - This also requires that pinning be governed

10. Issues: I/O, Resource Consumption, Timing • I/O • - PCI bus is time multi-plexed... hurts performance • Resource Consumption • - Overhead and Driver Resource Consumption extends beyond the VM • - Some efficiency can be gained by sharing memory footprints and VMM memory management • Timing • - System may pre-empt real-time critical drivers • - Solution involves carrying VM interrupt disable actual machine interrupt disabling

11. Evaluation:Overhead Resources

12. CPU and Bandwidth • Native Linux vs. L4 Paravirtualization

13. Conclusions • Main Point: Driver Reuse • Unmodified drivers • Running in native OS • Smaller implementation effort than rewriting • Dependability (protection and modularity) • Achieved with 3-8% overhead