Add vfio mode to generate CDI specs for NVIDIA passthrough GPUs#315
Add vfio mode to generate CDI specs for NVIDIA passthrough GPUs#315elezar wants to merge 1 commit intoNVIDIA:mainfrom
Conversation
|
@cdesiniotis if this is still valid, please rebase or close. |
|
@varunrsekar would this be interesting for what you're looking at in NVIDIA/k8s-dra-driver-gpu#183? |
pkg/nvcdi/lib-vfio.go
Outdated
| // GetCommonEdits returns common edits for ALL devices. | ||
| // Note, currently there are no common edits. | ||
| func (l *vfiolib) GetCommonEdits() (*cdi.ContainerEdits, error) { | ||
| return &cdi.ContainerEdits{ContainerEdits: &specs.ContainerEdits{}}, nil |
There was a problem hiding this comment.
This is missing a device node for /dev/vfio/vfio:
&cdi.ContainerEdits{
ContainerEdits: &specs.ContainerEdits{
DeviceNodes: []*specs.DeviceNode{
&specs.DeviceNode{
Path: "/dev/vfio/vfio",
},
},
},
}
yeah this will help! |
|
@varunrsekar I am no longer working on this -- feel free to take ownership of this PR if you need it. |
Pull Request Test Coverage Report for Build 16119484166Details
💛 - Coveralls |
ArangoGutierrez
left a comment
There was a problem hiding this comment.
2 non blocking nits
There was a problem hiding this comment.
Pull Request Overview
This PR adds a new VFIO mode to the nvcdi API and the nvidia-ctk generate command to support NVIDIA GPU passthrough via VFIO.
- Introduces a
ModeVfioconstant and integrates it into the mode resolver. - Adds
WithPCILiboption and dependency onnvpcifor querying PCI devices. - Implements
vfiolibto generate VFIO-based CDI specs, including unit tests.
Reviewed Changes
Copilot reviewed 6 out of 10 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/nvcdi/options.go | Import nvpci and add WithPCILib option |
| pkg/nvcdi/mode.go | Register ModeVfio in the list of supported modes |
| pkg/nvcdi/lib.go | Wire up nvpcilib in New for ModeVfio |
| pkg/nvcdi/lib-vfio.go | Implement vfiolib and VFIO device spec generation |
| pkg/nvcdi/lib-vfio_test.go | Add unit tests for the new VFIO mode |
| go.mod | Bump github.com/NVIDIA/go-nvlib for PCI library support |
Comments suppressed due to low confidence (3)
pkg/nvcdi/lib-vfio.go:93
- [nitpick] Consider using
%qinstead of%vto quote the invalid ID in the error message for clarity ("invalid channel ID %q: %w").
return nil, fmt.Errorf("invalid channel ID %v: %w", id, err)
pkg/nvcdi/lib-vfio_test.go:28
- Tests cover positive VFIO scenarios but don’t verify that non-
vfio-pcidevices are filtered out or that error paths (e.g., invalid ID parsing, PCI library failures) behave as expected. Consider adding cases for those.
func TestModeVfio(t *testing.T) {
pkg/nvcdi/lib-vfio.go:33
- [nitpick] The field
groupinvfioDeviceis ambiguous — consider renaming it toiommuGroupto make its purpose clearer.
group int
|
@elezar Sorry this completely missed my radar. Are you driving this to completion? |
…through GPUs Signed-off-by: Christopher Desiniotis <cdesiniotis@nvidia.com>
|
Thanks @varunrsekar. I have rebased this. Please take a look. |
varunrsekar
left a comment
There was a problem hiding this comment.
@elezar Thanks for this change. This looks good to me. Just had some minor comments.
Also as a follow-up:
We'd also want to support IOMMUFD devices (https://lists.nongnu.org/archive/html/qemu-devel/2022-06/msg01294.html):
The legacy way is /dev/vfio/vfio and /dev/vfio/<group>. The IOMMUFD way is: /dev/iommu and /dev/vfio/devices/<vfioX>
|
|
||
| var vfioDevices []*vfioDevice | ||
| for i, dev := range devices { | ||
| if dev.Driver != "vfio-pci" { |
There was a problem hiding this comment.
I recently found out that this driver is different for GB200/GH200 systems (nvgrace-gpu-vfio-pci). So perhaps this needs to account for it
There was a problem hiding this comment.
On a related note, I am working on updating our vfio-manage script (which binds GPUs to the vfio-pci driver) to account for this new VFIO module required for Grace: NVIDIA/k8s-driver-manager#128. Hopefully we can push the relevant abstractions to go-nvlib so that our various clients don't need to re-implement logic to detect what module name to use.
There was a problem hiding this comment.
yes having this in go-nvlib would be very useful!
| func (l *vfioDevice) GetDeviceSpecs() ([]specs.Device, error) { | ||
| path := fmt.Sprintf("/dev/vfio/%d", l.group) | ||
| deviceSpec := specs.Device{ | ||
| Name: fmt.Sprintf("%d", l.index), |
There was a problem hiding this comment.
Can you add a prefix to this name? I can imagine that other non-gpu vfio device might also need something like this. So we'd need a prefix to also differentiate the device types. Something like: vfio-<deviceType>-<deviceIndex>. Eg: vfio-gpu-0 / gpu-vfio-0.
There was a problem hiding this comment.
Would you prefer that over an explicit class by default? What about:
nvidia.com/gpu.vfio=0
or
nvidia.com/vfio.gpu=0
There was a problem hiding this comment.
Eg:
$ sudo nvidia-ctk cdi list
k8s.gpu.nvidia.com/device=gpu-0
k8s.gpu.nvidia.com/device=gpu-1
nvidia.com/gpu.vfio=0
nvidia.com/gpu.vfio=1
Would it be possible for our container runtime to allocate from the different classes? I remember I couldnt get it to work when I attempted a new class
This change adds a vfio mode to the nvcdi API (and nvidia-ctk generate command).