Skip to content

Report vendor VFIO profile availability per free VF - #378

Closed
yummybomb wants to merge 17 commits into
hypeship/vendor-vfio-vgpufrom
hypeship/fix-vgpu-stack-review
Closed

Report vendor VFIO profile availability per free VF#378
yummybomb wants to merge 17 commits into
hypeship/vendor-vfio-vgpufrom
hypeship/fix-vgpu-stack-review

Conversation

@yummybomb

Copy link
Copy Markdown
Contributor

summary

  • report vendor VFIO profile availability in creatable-instance units by counting free VFs that advertise each profile
  • align vendor VFIO availability with the existing API contract and mdev reporting semantics
  • update the unit test to cover multiple free VFs sharing a parent GPU

This changes the gpuProfileSlots metric for vendor VFIO hosts from parent-GPU units to free-VF units.

tests

  • GOCACHE=/tmp/gocache go vet ./lib/devices ./lib/resources
  • GOCACHE=/tmp/gocache go test ./lib/devices -run 'TestVendorVFIO' -count=1 -v
  • GOCACHE=/tmp/gocache go test ./lib/devices ./lib/resources -count=1

The vendor VFIO hardware integration test was not run locally.

A vGPU assignment goes stale when its release succeeds but the
metadata save does not (or start fails between the release and its
first save). The backend's owner map only covers assignments created
since the last restart and the VFIO handle scan only covers VMs that
have opened the device, so after a restart a stale release could still
clear a VF during another live instance's pre-open boot window.
Consult live instance metadata on every release: when another instance
with a live hypervisor process claims the same device path, drop the
stale metadata without touching the device.

Tag assignments with the owning instance ID, persist the assignment
before booting a started instance, and retain assignment metadata when
rollback release fails in create and start so later release paths can
still find the device.
Startup reconciliation protects the VFs of instances whose hypervisor
survived the restart, verified by socket ownership so a reused PID
cannot hold a VF. The inventory behind that protected set must not
silently skip unreadable metadata: a skipped live claimant would leave
its VF unprotected during the pre-VFIO-open boot window. Add
ListInstancesForReconcile, which fails on any unreadable metadata, and
skip vendor VFIO reconciliation when the inventory is unavailable
while keeping mdev reconciliation running.
The claim guard compared raw GPUDevicePath, which is empty on records
persisted before the framework migration; a live claimant with only a
legacy GPUMdevUUID was invisible to the check. Normalize the inventory
side with storedVGPUDevicePath, matching the release subject.
…r seam

Replace the go:linkname shadow of devices.hostVendorVFIO with createVGPU/destroyVGPU manager fields, and wrap failed creates whose rollback release also failed in VGPUCleanupPendingError so the API can point callers at the retained instance record.
Enable vendor VFIO dispatch in CreateVGPU now that the lifecycle
persists assignments durably and guards releases.

Protect nil-PID claims in the release guard: the hypervisor PID is only
persisted after the claimant boots, so a matching assignment without a
PID must be treated as live, matching the startup reconcile protection.

Scan raw metadata instead of hydrating instances for the claim check.
Hydration derives state through hypervisor queries for every instance
on the host, which every vendor VFIO release would pay; the guard only
needs the stored assignment, PID, and socket. Unreadable metadata still
fails the release closed.

Report pending vGPU cleanup even when retaining the rollback record
fails: the destroy already failed, so the caller must learn about the
outstanding assignment either way.
@yummybomb
yummybomb force-pushed the hypeship/vendor-vfio-vgpu branch from 8807e97 to 9642387 Compare August 10, 2026 05:11
@yummybomb

Copy link
Copy Markdown
Contributor Author

folding this into the stack where the bug was introduced: the fix now lives in #364 (hypeship/vendor-vfio-backend) and the stack has been rebased.

@yummybomb yummybomb closed this Aug 10, 2026
@yummybomb
yummybomb deleted the hypeship/fix-vgpu-stack-review branch August 10, 2026 05:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant