PCI_IOV_ADD_VF(9)

💖 PCI_IOV_ADD_VF 💖

okay bestie, so this one is from the Kernel Developer's Manual (section 9, the kernel-nerd zone 🧚) and it's literally about telling a PF driver "hey girly, a VF is being born rn". no cap.

✨ NAME ✨

PCI_IOV_ADD_VF — inform a PF driver that a VF is being created

🌸 SYNOPSIS 🌸

#include <sys/bus.h>
#include <machine/stdarg.h>
#include <sys/nv.h>
#include <dev/pci/pci_iov.h>

int
PCI_IOV_ADD_VF(device_t dev, uint16_t vfnum, const nvlist_t *vf_config);

🦋 DESCRIPTION 🦋

The PCI_IOV_ADD_VF() method is called by the PCI Single-Root I/O Virtualization (SR-IOV) infrastructure when it is initializating a new Virtual Function (VF) as a child of the given Physical Function (PF) device. (yes, it really says "initializating" in the original, we're keeping it, iconic 💅)

So here's the tea: this method will not be called until a successful call to PCI_IOV_INIT(9) has been made. and even then? it's not guaranteed that this method will be called following a successful call to PCI_IOV_INIT(9). like, bestie, it's giving "maybe". 🙈 if the infrastructure encounters a failure to allocate resources following the call to PCI_IOV_INIT(9), the VF creation will be aborted and PCI_IOV_UNINIT(9) will be called immediately, without any preceding calls to PCI_IOV_ADD_VF. zero buildup, straight to the breakup. 💀

The index of the VF being initialized is passed in the vfnum argument. VFs are always numbered sequentially starting at 0. (yes babes, zero-indexed, the way nature intended 🌈)

If the driver requested device-specific configuration parameters via a VF schema in its call to pci_iov_attach(9), those parameters will be contained in the vf_config argument. okay so let's break down what's guaranteed in there:

• All configuration parameters that were either set as required parameters, or that had a default value set in the VF schema, are guaranteed to be present in vf_config. 💖
• Configuration parameters that were neither set as required nor given a default value are optional and may or may not be present in vf_config. 🙈
• vf_config will not contain any configuration parameters that were not specified in the VF schema. periodt.
• All configuration parameters will have the correct type and will be in the range of valid values specified in the schema. no chaos allowed, everything's valid and on its best behaviour ✨

Note that it is possible for the user to set different configuration values on different VF devices that are children of the same PF. The PF driver must not cache configuration parameters passed in previous calls to PCI_IOV_ADD_VF() for other VFs and apply those parameters to the current VF. like, do NOT do that. that's the whole warning. each VF is its own main character, no copying homework 🫶

This function will not be called twice for the same vf_num on the same PF device without PCI_IOV_UNINIT(9) and PCI_IOV_INIT(9) first being called, in that order. (order matters bestie, UNINIT then INIT, don't freestyle it 🎀)

⭐ RETURN VALUES ⭐

This method returns 0 on success, otherwise an appropriate error is returned. and here's the spicy part: if this method returns an error then the current VF device will be destroyed, but the rest of the VF devices will be created and SR-IOV will be enabled on the PF. so it's a lil "one of y'all didn't make it but the group chat lives on" situation 😭

👑 SEE ALSO 👑

nv(9), pci(9), PCI_IOV_INIT(9), pci_iov_schema(9), PCI_IOV_UNINIT(9)

💜 AUTHORS 💜

This manual page was written by Ryan Stone <rstone@FreeBSD.org>. absolute legend, we thank them for their service 🫡

and that's the whole vibe check! this page came to you courtesy of Debian, dated May 28, 2015, living in section 9 of the manual. slay, bye bestie! 💖✨🎀🦋