On 6/4/26 11:20 AM, Jason Gunthorpe wrote: > On Thu, Jun 04, 2026 at 08:01:41AM -0700, Dimitri Daskalakis wrote: >> With this patchset core enumarates the SIOV capability and can identify >> SIOV PFs. But there is no central mechanism to allocate/manage SIOV VFs. >> To support device pass through, devices will need to add a vfio-mdev >> driver with IOMMUFD support (or something similar). > > There is an enormous amount of missing work to do something useful > with the SIOVr2 stuff. IIRC there is even supposed to be BIOS > components in this plan and there are some missing PCI SIG topics too > IIRC. > > So, I'm not sure how much value there is in merging just the cap > discovery without a roadmap for the missing parts.. > > Also, I'm quite surprised to see this out of the blue, there is an OCP > workstream that was building out a standard that outlines how all the > different components have to act to successfully implement it. What > is in PCI SIG was just some minor foundational adjustments without any > context on how to form them into a solution. > > I think it is extremely premature to merge anything related to SIOV to > the kernel. Join the OCP work stream if you are interested. I think > the general feeling was there is not sufficient interest in the > industry to do this and it has gone quiet. > > Jason
Hey Jason, thanks for the feedback. We (at Meta) are definitely interested in SIOV-like capabilities for device passthrough to containers. For those scenarios, having PCIe transactions per RID plus IOMMU isolation is enough, but I can imagine hypervisors/VMs requiring more platform support. I hear you on the broader support story being premature. But on the other hand, this series unblocks experimentation at the driver level for basic data path validation.
