Add the vendor VFIO vGPU device backend

[yummybomb]

Summary

Layer 2 of the vendor VFIO vGPU stack (generalize-vgpu-device ← hypervisor-liveness ← this ← vendor-vfio-vgpu). Self-contained in lib/devices + lib/resources; nothing in the instance lifecycle calls it yet (that's the top layer).

Linux 6.8 hosts with NVIDIA R580 drop the mdev interface: vGPUs are assigned by writing a type ID to a VF's nvidia/current_vgpu_type and passed to QEMU as a plain VFIO PCI device. This adds that backend behind the framework dispatch introduced in #322:

• Discovery & placement — profile discovery from the capacity-dependent creatable_vgpu_types catalogs, least-loaded-GPU VF selection, create/verify/rollback. Profile availability counts free VFs currently advertising each type as a best-effort snapshot; creating one assignment may change sibling catalogs.
• Release guards — unlike mdev (fresh UUID per assignment), vendor VFIO reuses the same VF path across assignments, so a stale release could clear a later owner's vGPU. Release is guarded by an in-process owner map (covers the window before QEMU opens the device) and an open-VFIO-handle scan (refuses to clear a VF a running VM holds).
• Reconciliation — clears orphaned assignments on startup, skips VFs in the caller-supplied protected set, and fails closed (skips vendor VFIO entirely) when that set is unavailable, while mdev reconciliation still runs.
• Per-VF degradation — one unreadable VF is skipped with a warning instead of failing discovery or profile listing wholesale, so a flaky sysfs read cannot blank the host's advertised GPU capacity. Only when no VF is readable does discovery fail, so a wholesale outage cannot demote a vGPU host to passthrough while assignments exist. The open-handle probe stays strict on purpose: it authorizes clearing a reused VF path, so an incomplete scan fails the release rather than risk a false "not in use".
• Integration test — branched by discovered framework, extended to cover release on stop and reacquisition on start.

Testing

• go build ./..., go vet clean
• go test -race ./lib/devices/ ./lib/resources/ pass

---

Note

High Risk
Touches GPU assignment, sysfs writes that can clear live VF types, and resource/admission reporting. A discovery or release bug could steal capacity, demote a vGPU host to passthrough, or wipe another instance’s assignment.

Overview
Adds NVIDIA’s vendor VFIO vGPU path (Linux 6.8 + R580: write type IDs to nvidia/current_vgpu_type) next to mdev, and routes discovery, profile listing, destroy, and reconcile through DiscoverVGPU.

Placement uses creatable_vgpu_types, least-loaded GPU selection, and create/verify/rollback. Availability is a best-effort count of free VFs advertising a type. Release is guarded by an in-process owner map plus a strict open-VFIO-handle scan so a reused VF path is not cleared while a VMM holds it. Reconcile drops orphans unless they are protected or still open; vendor VFIO reconcile no-ops if the protected set is missing.

Unreadable VFs are skipped so one bad sysfs node cannot blank capacity; discovery fails only when no VF is readable, so a vGPU host is not demoted to passthrough. CreateVGPU still rejects vendor VFIO until lifecycle persistence lands. Resource status now prefers vGPU discovery over passthrough, and docs/tests cover stop/start assignment plus the new sysfs backend.

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

[yummybomb]

added 7f5233f: report GPUProfile.Available as the count of free VFs advertising the profile type (creatable-instance units), matching mdev's summed available_instances, the OpenAPI description, and the integration test's decrement assertion. note the gpuProfileSlots metric steps up on vendor VFIO hosts (per-GPU → per-free-VF units). go test ./lib/devices ./lib/resources green; the hardware integration test was not run locally.

[github-actions]

-->

✱ stlc build

✅ go code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

116 files generated at abe29bb (pushed)

go get github.com/kernel/hypeman-go-staging@abe29bbba87d87198b10ccfbf4678d350739b146

✅ python code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

230 files generated at 1e0016e (pushed)

✅ typescript code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

138 files generated at db26009 (pushed)

Diagnostics: ❗ 0 new / 1 total error, 💡 0 new / 5 total note

Level	Code	Message	Targets

Build metadata

Build	bd_76BJxZSD-steep-span
Timestamp	2026-08-20T22:09:00.892Z
stlc	8413509
Spec hash	101b9ae4ce99
Config hash	55e15f6f4434

---

This comment is auto-generated by stlc and is kept up to date as you push.
If you push new commits, re-run this workflow to update this comment.
Last updated: 2026-08-20 22:09:31 UTC

[cursor]

Cursor Bugbot has reviewed your changes using default 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 d28e3d0. Configure here.}

[cursor]

Stale open-handle scan race

Medium Severity

reconcile takes one openVFIOPaths snapshot and passes it into destroyWithOpenPaths, which skips a fresh scan under vendorVFIOMu when that map is non-nil. A VMM can open the VF after the snapshot and before the current_vgpu_type clear, so reconcile can wipe an assignment a running guest already holds. The normal destroy path avoids this by passing nil and rescanning under the lock.

Additional Locations (1)

• lib/devices/vendor_vfio_linux.go#L243-L257

 

^{Reviewed by Cursor Bugbot for commit d28e3d0. Configure here.}