Transcript Unmodified Device Driver Reuse and Improved System

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 Beach
Northwestern University
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
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
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)
Driver Design
Basic Principles for Reuse
●
Resource Delegation
–
●
Separation of Name Spaces
–
●
●
- Within its own address space (proper protection)
Separation of Privilege
Secure Isolation
–
●
- Bulk Resources only, page level easier to
standardize
- Proper memory management, careful sharing
Common API
–
- General necessity of reuse and standardization
Architecture
Design Overview
●
DD/OS
–
●
Virtual Machines
–
●
- Protection and
Abstraction domain
Client
–
●
- Device Driver OS
- Uses Drivers via
through the VM
Translation Module
–
- The interface (glue)
between client and
the DD/OS
The Virtual Machine
●
The “Hyperviser”
–
●
The VMM
–
●
- Virtualization layer, actually manages the Vms
Device Management is direct (pass-through)
–
–
●
- Base kernel with ultimate privileges
- i.e. VM-OS is given direct access to devices
OS -> Device
OS <- VM <- Translation Module <- Client
Design Features:
Client and Dependability
●
Client interface provided by translation module
–
●
Modularity
–
–
●
- Uses interrupts to be invoked and to respond
- Device failure and crashes are contained within
VM
- VM can be rebooted
VM Isolation
–
- VM enforces isolation, even if device does not
Issue: Memory
●
DMA and VMM address translation
–
●
Solutions?
–
–
●
- 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
- 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
Issues: I/O, Resource
Consumption, Timing
●
I/O
–
●
Resource Consumption
–
–
●
- PCI bus is time multi-plexed... hurts performance
- 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
Evaluation:
Overhead Resources
CPU and Bandwidth
●
Native Linux vs. L4 Paravirtualization
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
●
●
●