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, and resource admission: a discovery or release bug can leak VFs, steal another instance’s assignment, or hide/expose GPU capacity incorrectly. Create is still gated, which limits production blast radius until the next layer.

Overview
Adds a Linux vendor VFIO vGPU backend for hosts that assign profiles via nvidia/current_vgpu_type instead of mdev (NVIDIA R580 / kernel 6.8+). Discovery prefers mdev, then vendor VFIO, and only then passthrough—so a failed vGPU probe no longer demotes a vGPU host to passthrough.

The backend discovers VFs, lists creatable_vgpu_types as a best-effort availability snapshot, places on the least-loaded GPU, and create/verify/rollback by writing the type ID. Release is guarded by an in-process owner map plus a strict open-VFIO-handle scan (because VF paths are reused). Reconciliation clears orphans unless they are protected or still held open. Unreadable VFs are skipped rather than wiping advertised capacity.

CreateVGPU still rejects vendor VFIO until instance-lifecycle integration lands. Resource status, OpenAPI profile available wording, GPU.md, and the vGPU integration test (stop/start reacquire; skip vendor VFIO for now) are updated to match.

^{Reviewed by Cursor Bugbot for commit 6f98055. 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

✅ gocode · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

116 files generated at f6146e4 (pushed)

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

✅ pythoncode · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

230 files generated at 3c815a0 (pushed)

✅ typescriptcode · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

138 files generated at 2cbb81b (pushed)

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

Level	Code	Message	Targets

Build metadata

Build	bd_76BcNdZp-glacial-scale
Timestamp	2026-08-21T20:51:21.988Z
stlc	8413509
Spec hash	a37dc5305160
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-21 20:51:46 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.}