Abstract vGPU devices behind a framework dispatch

[yummybomb]

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 / VGPUFramework abstraction — mdev moves behind a framework dispatch (CreateVGPU / DestroyVGPU / DiscoverVGPU), with assignments described by a framework + device path instead of a bare mdev UUID.
• Hypervisor wiring — QEMU receives the generalized vGPU path through VGPUDevicePath, while Cloud Hypervisor continues to receive the existing mdev path as a passthrough device.
• Metadata — VF allocation tracked with a single field; instance metadata carries GPUFramework / GPUDevicePath alongside the mdev UUID.
• QEMU args — vGPU attaches via sysfsdev, and the dead mdev branch is dropped from PCI passthrough args.

Testing

• go build ./..., go vet clean
• go test -race ./lib/devices/ ./lib/hypervisor/... and targeted lib/instances suites pass (TestSocketCacheKeyChangesWhenSocketIsRecreated and the network/image-dependent instances tests fail identically on the unmodified stack head in this environment)

---

Note

Medium Risk
Touches GPU instance create/start/stop/delete and hypervisor device args; behavior should match mdev today but mistakes could leak vGPU slots or break VM boot attachment.

Overview
Introduces a framework-agnostic vGPU layer (VGPUDevice, VGPUFramework, CreateVGPU / DestroyVGPU) so mdev is one backend today and future vendor VFIO paths can plug in without rewriting instance lifecycle.

Instance create/start/stop/delete now allocate and release vGPUs through that API and persist GPUFramework, GPUDevicePath, and the mdev UUID (for legacy rows), with helpers to resolve the attach path and tear down via VGPUAssignment. SR-IOV VF state is renamed from HasMdev to Allocated to match framework-neutral wording.

Hypervisors get a dedicated VGPUDevicePath on VMConfig instead of stuffing mdev sysfs paths into PCIDevices; QEMU always attaches vGPU with vfio-pci,sysfsdev=…, and microvm validation rejects both PCI passthrough and vGPU paths.

^{Reviewed by Cursor Bugbot for commit 9396bc0. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

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.}

[sjmiller609]

• consider a struct param for DestroyVGPU(ctx, framework, devicePath, mdevUUID) — three positional strings are easy to swap silently as backends multiply
• error strings still say "create vGPU mdev for profile %s" — reword in whichever layer introduces non-mdev backends
• stop/delete log "uuid", stored.GPUMdevUUID — will be empty for path-only assignments; log the device path instead

[yummybomb]

addressed the review in 113d9e6 + 9396bc0:

• DestroyVGPU now takes a devices.VGPUAssignment struct instead of three positional strings — pulled the exact shape down from the next PR in the stack, so its diff collapses on restack
• stop/delete now log device_path (always populated) instead of the possibly-empty mdev uuid
• the "create vGPU mdev" error strings stay as-is in this layer since mdev is the only backend here; the layer that introduces the vendor backend already rewords them to "create vGPU for profile"