Skip to content

Conversation

@winsopc
Copy link

@winsopc winsopc commented Sep 17, 2025

Add both PF and VF VFIO mode support, which is needed by kubevirt support.

@winsopc
Copy link
Author

winsopc commented Sep 18, 2025

@adrianchiris @SchSeba could you please review the changes?

@winsopc winsopc mentioned this pull request Sep 18, 2025
@SchSeba
Copy link
Collaborator

SchSeba commented Sep 28, 2025

Hi @adrianchiris will NVIDIA be able to check this one I don't have an env to test infiniband.

Copy link
Contributor

@almaslennikov almaslennikov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adrianchiris PTAL at this PR

@winsopc winsopc force-pushed the vfio-support-upstream branch 2 times, most recently from cc34bd7 to 1210b64 Compare October 18, 2025 00:23
Copy link
Contributor

@almaslennikov almaslennikov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. @adrianchiris PTAL

@adrianchiris
Copy link
Collaborator

Will review on sunday. sorry for the delay.

@winsopc
Copy link
Author

winsopc commented Nov 5, 2025

@adrianchiris PTAL

return nil, nil, err
}

// If vfioPciMode is true (either set manually or auto-detected), skip SR-IOV setup
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we do want the check related to netConf.RdmaIso

i would just skip the call for config.LoadDeviceInfo() if netConf.VfioPciMode is true

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack. I will update the PR.

// Only handle GUID setting for VF devices, keep previous code path for PF devices
if isVF && netConf.GUID != "" {
// Load device info needed for GUID setting (VFIO VF version - no network interface)
err = config.LoadDeviceInfoVfioVF(netConf)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason why this should not be rolled into configLoadDeviceInfo which will handle both regular and vfio cases ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I should put them together, if it's VF only, many codes can be reused.

if err != nil {
return err
sm := sriov.NewSriovManager()
if err := sm.ApplyVFConfig(netConf); err != nil {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this handles also applying linkState why do you call it conditionally if its a VF and GUID was provided ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's related to the PF related code path. I agree, this part need be optimized.
maybe I need submit a VF VFIO only change fist for this PR

// For VFIO VF devices, we don't have a network interface, so skip VF link operations
if conf.VfioPciMode && conf.HostIFNames == "" {
// VFIO VF: Just set the GUID directly via PF, no VF link to query
return s.setVfGUID(conf, pfLink, conf.GUID)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this currently breaks the non-vfio use-case.

for both cases you need to set the node and port GUID and only for the non-vfio case you need to rebind the VF.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack

// Validate that we have container interface name to work with
if conf.ContIFNames == "" {
// Silently skip cleanup if container interface name is missing
// This can happen with corrupted or incomplete cached configs
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if cache config failed to load we exit early.

i really find it hard to follow this PR. IMO this PR should focus around VFIO support.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. I will address this in next update.

Add VFIO mode support for VF devices, which is needed by kubevirt.

Signed-off-by: Zhen(Winson) Wang <[email protected]>
@winsopc winsopc force-pushed the vfio-support-upstream branch from 1210b64 to 6a69941 Compare November 12, 2025 17:50
@winsopc
Copy link
Author

winsopc commented Nov 12, 2025

@adrianchiris thanks for your review comments. I update my PR with VF VFIO support only. PTAL when you have time.
If upstream agree PF support is needed, I can add PF support in a new PR.

@winsopc winsopc changed the title VFIO device support VF VFIO device support Nov 14, 2025
@winsopc winsopc requested a review from adrianchiris November 19, 2025 18:54
@kozmod
Copy link

kozmod commented Nov 25, 2025

Hi, guys)
What about the progress of PR (@winsopc, @adrianchiris)?
our team need to this kind of functionality -> now we are creating VM using KubeVirt with Infinband interfaces (VF):

$ lspci -nnk | grep -A 3 -i mell
81:00.0 Infiniband controller [0207]: Mellanox Technologies MT27800 Family [ConnectX-5] [15b3:1017]
	Subsystem: Hewlett Packard Enterprise MT27800 Family [ConnectX-5] [1590:0255]
	Kernel driver in use: mlx5_core # ⚠️
	Kernel modules: mlx5_core
81:00.1 Infiniband controller [0207]: Mellanox Technologies MT27800 Family [ConnectX-5 Virtual Function] [15b3:1018]
	Subsystem: Hewlett Packard Enterprise MT27800 Family [ConnectX-5 Virtual Function] [1590:0255]
	Kernel driver in use: vfio-pci # ⚠️
	Kernel modules: mlx5_core
81:00.2 Infiniband controller [0207]: Mellanox Technologies MT27800 Family [ConnectX-5 Virtual Function] [15b3:1018]
	Subsystem: Hewlett Packard Enterprise MT27800 Family [ConnectX-5 Virtual Function] [1590:0255]
	Kernel driver in use: vfio-pci  # ⚠️
	Kernel modules: mlx5_core

I have built and installed ib-sriov bin file from this branch (didn't look at the changes attentively) and tried to create VM (with UFM integration + Nvidia-networl-operator + Multus) -> GUID (Pkey Members) in the UFM creates normally...
... but I have found one problem: GUID didn't delete from UFM after deleting VM.
Снимок экрана 2025-11-25 в 11 16 27

@winsopc
Copy link
Author

winsopc commented Nov 26, 2025

Hi @kozmod , Thanks for validating my PR. This PR is pending @adrianchiris 's review for my latest changes.
For the stale guid issue on UFM, are you using ib-kubernetes ?
My understanding, ib-sriov-cni cannot control the UFM side, it's ib-kubernetes with ufm plugin.
https://github.com/Mellanox/ib-kubernetes/tree/master
@almaslennikov @adrianchiris can you guys comments on the guid UFM support?

@kozmod
Copy link

kozmod commented Nov 27, 2025

@adrianchiris , could you continue validate this PR, please?

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.

5 participants