Industry Insights

SR-IOV Passthrough and Namespace Isolation: Moving VM I/O Out of the Hypervisor

작성: JH SemiconductorSR-IOV / virtual function / namespace isolation

Independent VF queue pairs and MSI-X let a VM bypass the software switch layer, but performance isolation is the hard one of the three layers. SR-IOV sits in the P1 tier of the feature baseline, and the maturity of the underlying QoS arbitration is why.

The Software Switch Layer Is No Longer Free

Under classic virtualisation every guest block I/O passes through an emulated device and a back-end driver, adding at least two context switches and a data copy. With drive-side QD1 average read latency planned at around 65 µs, that fixed overhead becomes a meaningful fraction of total service time — and under high concurrency on the same path it also turns into a CPU-side bottleneck. The faster the drive, the more visible the virtualisation tax.

What SR-IOV Changes

SR-IOV presents one physical function (PF) and a number of virtual functions (VFs) from a single physical SSD. Each VF has its own BAR space, its own MSI-X vectors and its own submission/completion queue pairs, and can be mapped directly into a guest address space. The guest driver rings its own doorbell; commands are arbitrated by the controller front end and enter the shared NAND channel scheduler, with the data path never touching the hypervisor. The PF retains management duties — VF creation and teardown, resource quotas, and out-of-band monitoring via NVMe-MI.

Three Layers of Isolation, All Required

Handing VFs to different tenants requires all three isolation layers to hold at once. Address isolation comes from the IOMMU. Data isolation comes from multiple namespaces: a VF attaches only to the namespaces assigned to it and cannot address LBAs in any other. Performance isolation is the difficult one — per-VF bandwidth and IOPS quotas must be enforced inside the controller, or one tenant's large sequential write stream will multiply a neighbour's read latency. Host-side rate limiting cannot fix this, because the queueing has already happened inside the drive.

Why It Sits in the P1 Tier

The enterprise feature baseline puts PLP, end-to-end protection, T10 DIF/DIX, multiple namespaces, NVMe-MI, TCG OPAL and Secure Boot, telemetry, online update and rollback, low-latency QoS and hot-plug in the first wave, with SR-IOV and OCP-related requirements in the P1 tier — and the list itself is still converging at the definition stage. The ordering follows from one observation: the value of a VF depends heavily on the maturity of the underlying QoS arbitration, so hardening queue-level service quality under a single PF first and exposing VFs afterwards is the safer sequence.

Which Form Factors It Lands On

The capability is planned for the Gen5 multi-tenant side: FLEX 9 in E3.S (J100E, J130E) and E1.S (J100S, J130S) for OCP cloud data centres and high-density nodes, and TITAN 9 in U.2/U.3 for AI servers, databases and cloud platforms. What those share is a single drive serving several mutually untrusting workloads. On general-purpose server and virtualisation configurations of the CORE 7 kind, a single PF plus multiple namespaces already covers most of the isolation requirement. Placing SR-IOV in P1 is not a deferral; it is an admission that its benefit only materialises once the layer beneath it is solid.

키워드
SR-IOVvirtual functionnamespace isolationnoisy neighbourNVMe-MIQoS arbitrationFLEX 9