{
  "slug": "sr-iov",
  "term": "Single Root I/O Virtualization (SR-IOV)",
  "aliases": [
    "SR-IOV",
    "Single Root I/O Virtualization",
    "Single-Root I/O Virtualization"
  ],
  "definition": "SR-IOV is a PCI Express capability that lets a Physical Function expose dependent Virtual Functions as separately addressable PCI functions.",
  "note": "A Virtual Function (VF) has its own PCI configuration-space address and register mapping, not a separate physical drive. Linux v6.12 distinguishes enabling VFs through sriov_numvfs from host-driver probing; neither operation alone assigns a VF to a guest. Set sriov_drivers_autoprobe before enabling VFs; changing it does not affect VFs that have already been probed. [linux-iov]\n\nIn NVMe Base 2.0e, support for both SR-IOV and Virtualization Enhancements maps Physical Function (PF) controllers to primary controllers and their VFs to secondary controllers. Flexible queue and interrupt resources assigned to a secondary controller are configured while that controller is Offline. A namespace is separate: Figure 19 permits both private and shared namespaces, not one namespace per VF. [nvme-20e]\n\nThe same NVMe edition takes associated secondary controllers Offline when the primary is disabled or undergoes a Controller Level Reset. Function separation is not reset independence. Disabling a VF register mapping is not itself a controller reset: Base 2.0e specifies that clearing SR-IOV Control.VF MSE hides the VF controller properties without resetting their values. For Linux device assignment, DMA isolation also depends on the IOMMU group and platform topology. [nvme-20e] [linux-vfio]",
  "status": "shipping",
  "advantages": [],
  "limitations": [
    {
      "text": "Enabling a VF does not establish guest assignment, controller readiness or namespace attachment.",
      "citationIds": [
        "linux-iov",
        "nvme-20e"
      ]
    },
    {
      "text": "Separately addressable functions do not by themselves establish independent DMA isolation; Linux VFIO retains IOMMU-group ownership constraints.",
      "citationIds": [
        "linux-vfio"
      ]
    }
  ],
  "related": [
    "pcie-storage",
    "nvme",
    "namespace-nvme",
    "nvm-subsystem"
  ],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "citations": [
    {
      "id": "linux-iov",
      "title": "Linux v6.12: PCI Express I/O Virtualization Howto, sections 3.1.1, 3.2.1 and 3.3.1",
      "url": "https://www.kernel.org/doc/html/v6.12/PCI/pci-iov-howto.html",
      "accessed": "2026-11-02"
    },
    {
      "id": "nvme-20e",
      "title": "NVM Express Base 2.0e (29 July 2024), sections 2.4.1 and 8.26; copyright 2008-2024 NVM Express, Inc., all rights reserved",
      "url": "https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0e-2024.07.29-Ratified.pdf",
      "accessed": "2026-11-02"
    },
    {
      "id": "linux-vfio",
      "title": "Linux v6.12: VFIO, Groups, Devices, and IOMMUs; Device cdev ownership",
      "url": "https://docs.kernel.org/6.12/driver-api/vfio.html",
      "accessed": "2026-10-31"
    }
  ],
  "updated": "2026-11-02",
  "provenance": [
    "Primary-source explanation using pinned editions, not a claim about the latest specification or support in every NVMe device.",
    "No VF was enabled or assigned in this work; no isolation, reset, performance or live-migration experiment was performed."
  ]
}