PCI_IOV_INIT(9)

💅 PCI_IOV_INIT — enable SR-IOV on a PF device

okay bestie so this is PCI_IOV_INIT(9), straight out of the Kernel Developer's Manual (section 9, kernel-land, very much not your average userland situation 💀). It's the page about turning on SR-IOV for a PF device, and honestly? it's giving "networking main character energy" ✨

---

✨ SYNOPSIS ✨

the vibes, verbatim 🫶

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

int
PCI_IOV_INIT(device_t dev, uint16_t num_vfs, const nvlist_t *pf_config);

---

🌸 DESCRIPTION 🌸

So the PCI_IOV_INIT() method gets called by the PCI Single-Root I/O Virtualization (SR-IOV) infrastructure when the user requests that SR-IOV be enabled on a Physical Function (PF). Basically the user slides into your DMs asking for SR-IOV and the infra is like "okay, PCI_IOV_INIT(), you're up 💫". The number of Virtual Functions (VFs) that will be created gets passed to this method in the num_vfs argument — that's literally the headcount of VFs you're about to create, no cap.

Now, if the driver requested device-specific PF configuration parameters via a PF schema in its call to pci_iov_attach(9), those parameters will be available in the pf_config argument. Iconic. Here's the tea on what's guaranteed to be in there ☕:

• All configuration parameters that were either set as required parameters or that had a default value set in the PF schema are guaranteed to be present in pf_config. slay, reliable 💖
• Configuration parameters that were neither set as required nor given a default value are optional and may or may not be present in pf_config. lowkey a vibe check every time 🎲
• pf_config will not contain any configuration parameters that were not specified in the PF schema. no random extras, periodt 🙅
• All configuration parameters will have the correct type and are in the range of valid values specified in the schema. so you can trust it, fr fr ✅

Heads up bestie: if this method returns successfully, then this method will not be called again on the same device until after a call to PCI_IOV_UNINIT(9). Like, one at a time. No double-dipping. 🚫

---

👑 RETURN VALUES 👑

Returns 0 on success — that's the win, the slay, the "you ate 💅". Otherwise an appropriate error is returned. And if this method returns an error then the SR-IOV configuration will be aborted and no VFs will be created 😭 the whole thing just... stops. Not me crying in the kernel logs.

---

🦋 SEE ALSO 🦋

the whole friend group, pls go read them all:

• nv(9)
• pci(9)
• PCI_IOV_ADD_VF(9)
• pci_iov_schema(9)
• PCI_IOV_UNINIT(9)

---

🎀 AUTHORS 🎀

This manual page was written by Ryan Stone <rstone@FreeBSD.org>. King behavior, we stan 👑✨

---

okay that's the whole page!! this little cutie is from the Debian flavor of things, dated May 28, 2015 — ancient, honestly, but the wisdom is timeless 🧚💜