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
Changes host GPU discovery, /resources admission signals, and sysfs assignment/release paths; vendor create remains blocked but incorrect discovery or release logic could misreport capacity or clear the wrong VF.

Overview
Adds NVIDIA vendor VFIO vGPU support alongside mdev: VFs are discovered via creatable_vgpu_types / current_vgpu_type, profiles are listed from sysfs, assignments are created by writing a type ID and released by writing 0, with least-loaded-GPU placement, in-process owner checks, and a strict /proc VFIO open-handle scan before release.

Unified vGPU stack: DiscoverVGPU() picks mdev when usable VFs exist, otherwise vendor VFIO; DetectHostGPUMode / public DiscoverVFs go away. DestroyVGPU / ReconcileVGPUs dispatch by framework; CreateVGPU still errors on vendor VFIO until instance lifecycle integration lands. Instance cleanup passes InstanceID on VGPUAssignment for vendor release ownership.

Safer capacity reporting: mdev and vendor discovery skip individual unreadable VFs (warn) instead of reporting zero capacity; /resources uses DiscoverVGPU with context and avoids falling through to passthrough when vGPU discovery fails. API/docs clarify best-effort profile availability and ephemeral stop/start lifecycle.

Tests & docs: large sysfs unit tests for vendor VFIO; integration test asserts framework-specific sysfs, stop/release, and start/reacquire (skips vendor VFIO hosts until create is wired).

^{Reviewed by Cursor Bugbot for commit 345db47. 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 fc85cfe (pushed)

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

✅ python code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

230 files generated at 6f01d51 (pushed)

✅ typescript code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

138 files generated at 3f2884d (pushed)

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

Level	Code	Message	Targets

Build metadata

Build	bd_76CczQdS-zealous-comb
Timestamp	2026-08-24T20:34:46.289Z
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-24 20:35:12 UTC