PCI_IOV_ADD_VF(9)

💖 NAME 💖

okay bestie, welcome to PCI_IOV_ADD_VF(9) from the Kernel Developer's Manual — its whole little mission is to inform a PF driver that a VF is being created. that's the point. that's the vibe, fr fr. periodt. 🦋✨

---

✨ SYNOPSIS ✨

#include <sys/bus.h>
#include <sys/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 💅

okay so picture this: the PCI Single-Root I/O Virtualization (SR-IOV) infrastructure is initializing a new Virtual Function (VF) as a child of the given Physical Function (PF) device, and it calls the PCI_IOV_ADD_VF() method. main character energy, honestly. 👑

timing tea, bestie: PCI_IOV_ADD_VF() will not be called until a successful call to PCI_IOV_INIT(9) has been made. lowkey important. but — plot twist — it is not guaranteed that this method will be called following a successful call to PCI_IOV_INIT(9). 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. 😭💀

The index of the VF being initialized is passed in the vfnum argument. VFs are always numbered sequentially starting at 0. no skipping, no weird gaps, just 0 onwards. 🎀

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. All configuration parameters that were either set as required parameters or that had a default value set in the VF schema are highkey guaranteed to be present in vf_config. Configuration parameters that were neither set as required nor were 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. All configuration parameters will have the correct type and will be in the range of valid values specified in the schema. the schema ate and left no crumbs — it's giving type safety, slay, we are obsessed. 💖

bestie pls note: 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. not me having to say this, but nope. don't do it. that is not the move. 🙈

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, iykyk. ⭐

---

🎀 RETURN VALUES 🎀

PCI_IOV_ADD_VF() returns 0 on success, otherwise an appropriate error is returned. 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 one messy VF doesn't cancel the whole squad — iconic resilience, no cap. 👑✨

---

🌈 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>. 🫶

okay that's the whole page, bestie — this cutie came from Debian, dated May 28, 2015, and its manpage tag is PCI_IOV_ADD_VF(9). mwah 💋💖