Dynamic GPU Allocation for Virtual Machines

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current virtual machine (VM) technologies face performance limitations when accessing graphics processing units (GPUs) due to the inflexibility of hypervisor-based GPU access and the lack of flexibility in GPU passthrough methods, which hinder seamless migration and resource reallocation.

Innovation Solution

A method that offloads the first GPU driver from the VM's operating system, deallocates the first GPU, allocates a second GPU, loads the second GPU driver, and replays the GPU command log to restore the GPU context, allowing for dynamic migration and reallocation of GPU resources while maintaining application transparency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If hypervisor-based GPU access is used for VMs, then flexibility for migration is improved, but performance is severely limited

Engineering Contradiction:
Improveflexibility for migrationVSAvoidperformance
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The system segments GPU access into two distinct modes: hypervisor-based virtualized access for flexibility and direct passthrough access for performance. The VM can dynamically switch between these segments depending on the operational context, allowing migration when virtualized and high-performance access when passthrough is enabled.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The GPU access model is made dynamic by allowing the VM to transition between hypervisor-based virtualized access and direct passthrough access. This dynamic switching enables the system to optimize between flexibility (during migration) and performance (during steady-state operation) based on current needs.

Inventive Principle:
Principle #15Dynamics

2Productivity

If GPU passthrough is used to assign GPU resources to VM, then performance is improved, but flexibility for migration is much less

Engineering Contradiction:
ImproveperformanceVSAvoidflexibility for migration
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The system changes the access parameter dynamically - switching between virtualized access mode (for migration flexibility) and passthrough mode (for performance). By controlling the VM's ability to switch between these parameter states, the system resolves the contradiction between flexibility and performance.

Inventive Principle:
Principle #35Parameter changes

3Productivity

If a VM interfaces directly with hardware components, then performance is improved, but the VM loses the ability to be transparently managed during migration

Engineering Contradiction:
ImproveperformanceVSAvoidtransparent management
Core Design Contradiction:
ProductivityVSEase of operation

Solution Approach 1:

The hypervisor serves as an intermediary that enables transparent management during migration while allowing direct hardware access for performance. The intermediary can redirect communications to different GPUs during migration without the VM needing to be aware of the underlying hardware changes, thus maintaining both performance and ease of operation.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3497562B1Allocation of graphics processing units for virtual machines
Publication Date: 2023.12.13 HUAWEI TECH CO LTD
  • EP3497562B1 patent drawingFigure 1
  • EP3497562B1 patent drawingFigure 2
  • EP3497562B1 patent drawingFigure 3

AI summary

The present disclosure provides systems, methods, and computer-readable media for managing graphics processing unit (GPU) allocation for a virtual machine (VM). A first GPU driver, associated with a first GPU, is offloaded from an operating system (OS) of the VM. Then, the first GPU is deallocated from the VM. A second GPU is allocated to the VM, and a second GPU driver, associated with the second GPU, is loaded in the OS of the VM. To restore a GPU context from the first GPU within the second GPU, a GPU command log from the first GPU is replayed to the second GPU.