1. GPUvm: GPU Virtualization at the Hypervisor
Yusuke Suzuki, Shinpei Kato, Member, IEEE,
Hiroshi Yamada, Member, IEEE, and Kenji Kono, Member, IEEE
IEEE TRANSACTIONS ON COMPUTERS
Park Sewon

2. CONTENTS Introduction Full-Virtualization Naive Para-Virtualization
High performance para-virtualization(PVDRM)
Experimen
Conclusion

3. Introduction Virtualizing GPUs I/O pass-through API remoting
Exposes GPU hardware to Guest device driver
can provide close to a native performance
Physical GPU is assigned to a Single VM
API remoting
More suitable for multi-tasking
Easy to implement
Require a high-level API such as CUDA(in Guest VMs)

4. Introduction Virtualizing GPUs Para-virtualization Full-virtualization
An ideal device model through the hypervisor
Allows multiple VMs to concurrently access the GPU
Lower-level control to the guest drivers
Minimizes the overhead of the virtualization
The guest device drivers must be modified
Full-virtualization
Enables for multiplexing without drivers
Guest VMs to use vanilla device drivers
Users can use existing GPGPU s/w stack

5. Introduction Full-virtualization Naive Para-virtualization
GPUvm exposes a native GPU device model
A low-level interface through memory-mapped I/O
Naive Para-virtualization
GPUvm provides a hypercall interface to mitigate the major source of overhead in the full-virtualization
High performance para-virtualization
Is called PVDRM
GPUvm exposes the high-level interface
Direct Rendering Manager(DRM) APIs as an interface

6. 2. Full-Virtualization GPUvm intercepts MMIO
GPUvm creates a GPU shadow page table for every GPU channel descriptor.

7. 3. Naive Para-Virtualization
Full-Virtualization’s overhead
Shadowing GPU page tables need to be scanned to detect any changes to the guest GPU page tables.
New hypercall interface
The guest GPU page tables are placed within the memory areas under the control of GPUvm.
The guest GPU driver issues a hypercall to the hypervisor to update the guest GPU page tables.
Expensive that The context is switched from the VM to hypervisor
GPUvm uses the multicall interface.

8. 4. PVDRM Naive para-virtualization’s overhead
The low-level interceptions through MMIO
Frequent hypercall issues
Uses the Direct Rendering Manager
Instead of MMIO
Provides high-level interfaces
Enables for existing software stacks without modification.

9. 4. PVDRM Uses the split driver model
The front-end driver resides in the guest
The DRM operations on the front-end are routed to the back-end driver
The back-end driver performs them in the DRM stack

10. 5. Experiment Full-virtualization Naive para-virtualization
A non-trivial overhead due to MMIO
Naive para-virtualization
Two or three times slower performance than the pass-through and native approaches.
High-performance para-virtualization
Reduces the overhead

11. 6. Conclusion
The GPU hardware design is that a nested page table support in GPUs is effective to reduce overhead of GPU virtualization.
We do not have to scan all page table entries in building the shadow page table
Hardware extension