Abstract vGPU devices behind a framework dispatch - #366
Open
yummybomb wants to merge 18 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
yummybomb
force-pushed
the
hypeship/vgpu-framework-abstraction
branch
from
August 10, 2026 18:58
0abb18e to
5f9e4fd
Compare
yummybomb
force-pushed
the
hypeship/vgpu-framework-abstraction
branch
from
August 12, 2026 15:20
fe97bda to
d86b86b
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 d86b86b. Configure here.
|
|
||
| if cfg.VGPUDevicePath != "" { | ||
| args = append(args, "-device", fmt.Sprintf("vfio-pci,sysfsdev=%s", cfg.VGPUDevicePath)) | ||
| } |
There was a problem hiding this comment.
MicroVM skips vGPU path check
Low Severity
MicroVMProfile.validateConfig still only rejects PCIDevices, but vGPU attachment now goes through VGPUDevicePath and QEMU always emits vfio-pci,sysfsdev=... for that field. A real config with only VGPUDevicePath set therefore passes validation even though microvm cannot support VFIO/vGPU.
Reviewed by Cursor Bugbot for commit d86b86b. Configure here.
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 13, 2026 14:19
d86b86b to
ec4e189
Compare
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 VM device attachment and vGPU create/destroy on instance create, start, stop, and delete; behavior should match mdev today but regressions could leak or fail to release GPU slots.
Overview
Introduces a framework-agnostic vGPU layer (
VGPUDevice,VGPUFramework,CreateVGPU/DestroyVGPU) so mdev is one backend today and future VFIO-style assignments can plug in without rewriting instance lifecycle.Instance flow now provisions and tears down vGPUs through that API, persists
GPUFrameworkandGPUDevicePath(with helpers for legacy mdev UUID paths), and routes attachment via dedicatedVGPUDevicePathonhypervisor.VMConfiginstead of stuffing mdev sysfs paths intoPCIDevices. QEMU always attaches vGPU withvfio-pci,sysfsdev=…; Cloud Hypervisor adds the path as a passthrough device entry.SR-IOV VF JSON/API field
has_mdevis renamed toallocatedto mean “vGPU assigned on this VF,” and GPU slot counting follows the same rename.Reviewed by Cursor Bugbot for commit ec4e189. Bugbot is set up for automated code reviews on this repo. Configure here.