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

Medium Risk
Touches sysfs vGPU assignment and VFIO in-use probing on a reused VF path; vendor create remains blocked, but destroy/reconcile and resource reporting changes affect admission and cleanup behavior on GPU hosts.

Overview
Adds NVIDIA vendor VFIO vGPU support alongside mdev: profiles come from creatable_vgpu_types, assignments are written to current_vgpu_type, with least-loaded-GPU placement, create verify/rollback, and release guards (in-process owner map plus strict open-VFIO-handle scan so a reused VF path is not cleared while a VM still holds it).

Discovery and API surface replace DetectHostGPUMode with DiscoverVGPU (mdev VFs first, then vendor VFIO). ListGPUProfiles, DestroyVGPU, and new ReconcileVGPUs dispatch on VGPUFramework. Mdev discovery now ignores VFs without usable mdev_supported_types. CreateVGPU still rejects vendor VFIO until instance lifecycle integration lands; destroy/reconcile paths are wired for when metadata exists.

Resources use DiscoverVGPU for /resources GPU status and fail closed on discovery errors so a vGPU host is not mis-reported as passthrough. Profile availability is documented as a best-effort VF snapshot.

Integration test is framework-aware (device path, sysfs checks), adds stop/release and start/reacquire, and skips on vendor VFIO hosts until create is enabled. Instance cleanup passes InstanceID on VGPUAssignment for vendor VFIO ownership checks.

^{Reviewed by Cursor Bugbot for commit 40252f8. 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 ✅

114 files generated at 32bcf05 (pushed)

go get github.com/kernel/hypeman-go-staging@32bcf05dec93a1dbdf6bbdcffb9fbaa25a3054a9

✅ typescript code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

136 files generated at 0358fb8 (pushed)

Diagnostics: 💡 0 new / 5 total note

Level	Code	Message	Targets

Build metadata

Build	bd_767nlNGQ-tame-glint
Timestamp	2026-08-13T14:21:59.563Z
stlc	8413509
Spec hash	d57cf10cee81
Config hash	ee536b54c599

---

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-13 14:22:19 UTC

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

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