Abstract vGPU devices behind a framework dispatch - #366
Open
yummybomb wants to merge 19 commits into
Open
Conversation
yummybomb
changed the title
yummybomb
marked this pull request as ready for review
August 6, 2026 19:20
yummybomb
force-pushed
the
hypeship/vgpu-framework-abstraction
branch
2 times, most recently
from
August 6, 2026 19:40
c3d6a2f to
f677357
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
yummybomb
force-pushed
the
hypeship/vgpu-framework-abstraction
branch
from
August 7, 2026 20:52
a903554 to
4499016
Compare
This was referenced Aug 9, 2026
yummybomb
force-pushed
the
hypeship/vgpu-framework-abstraction
branch
from
August 10, 2026 18:26
12bd9d9 to
0abb18e
Compare
Since vGPU devices attach through VGPUDevicePath, PCIDevices only carries whole-device passthrough paths; the mdev special case was unreachable.
Stop and delete keep best-effort vGPU release (log and continue, metadata always cleared) and start no longer releases a stale stored assignment. Those behavior changes belong to the lifecycle-hardening layer, not this behavior-preserving refactor.
yummybomb
force-pushed
the
hypeship/vgpu-framework-abstraction
branch
from
August 10, 2026 18:58
0abb18e to
5f9e4fd
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 33140f2. Configure here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bottom layer of the vendor VFIO vGPU stack (this ← #322 ← #363 ← #364 ← #321). Behavior-preserving refactor only — no lifecycle semantics change in this layer.
Kernel 6.8 hosts assign NVIDIA vGPUs through a vendor-specific VFIO interface instead of mdev, so the mdev-shaped seams get generalized before the new backend lands above:
VGPUDevice/VGPUFrameworkabstraction — mdev moves behind a framework dispatch (CreateVGPU/DestroyVGPU/DiscoverVGPU), with assignments described by a framework + device path instead of a bare mdev UUID.VGPUDevicePath, while Cloud Hypervisor continues to receive the existing mdev path as a passthrough device.GPUFramework/GPUDevicePathalongside the mdev UUID.sysfsdev, and the dead mdev branch is dropped from PCI passthrough args.Testing
go build ./...,go vetcleango test -race ./lib/devices/ ./lib/hypervisor/...and targetedlib/instancessuites pass (TestSocketCacheKeyChangesWhenSocketIsRecreatedand the network/image-dependent instances tests fail identically on the unmodified stack head in this environment)Note
Medium Risk
Touches instance GPU lifecycle and hypervisor device attachment paths; behavior should match mdev today but mistakes could break vGPU boot or leak devices on stop/delete.
Overview
This PR generalizes vGPU handling ahead of non-mdev backends while keeping current mdev behavior on Linux.
Device layer: Adds
VGPUDevice,VGPUFramework, andCreateVGPU/DestroyVGPU(Linux delegates to mdev; macOS stubs). RenamesVirtualFunction.HasMdevtoAllocatedin discovery and GPU resource counting.Instances: Create/start/stop/delete use the vGPU API and persist
GPUFrameworkandGPUDevicePath(with helpers invgpu.gofor release and legacy UUID-only metadata). VM config passesVGPUDevicePathinstead of stuffing mdev sysfs paths intoPCIDevices.Hypervisors:
hypervisor.VMConfiggainsVGPUDevicePath. QEMU always attaches vGPU withvfio-pci,sysfsdev=...and no longer treats mdev paths insidePCIDevices. Cloud Hypervisor appends the vGPU path as an extra passthrough device.Reviewed by Cursor Bugbot for commit 47007e7. Bugbot is set up for automated code reviews on this repo. Configure here.