> >>Does vfio work with swiotlb and if not, can/should swiotlb be > >>extended? Or does the time and space overhead make it a moot point? > > > >It does not work with SWIOTLB as it uses the DMA API, not the IOMMU API. > > > I think you got it reversed. vfio uses iommu api, not dma api.
Right. That is what I was saying :-) SWIOTLB uses the DMA API, not the IOMMU API. Hence it won't work with VFIO. Unless SWIOTLB implements the IOMMU API. > if vfio used dma api, swiotlb is configured as the default dma-ops interface > and it could work (with more interfaces... domain-alloc, etc.). <nods> > > >It could be extended to use it. I was toying with this b/c for Xen to > >use VFIO I would have to implement an Xen IOMMU driver that would basically > >piggyback on the SWIOTLB (as Xen itself does the IOMMU parts and takes > >care of all the hard work of securing each guest). > > > >But your requirement would be the same, so it might as well be an generic > >driver called SWIOTLB-IOMMU driver. > > > >If you are up for writting I am up for reviewing/Ack-ing/etc. > > > >The complexity would be to figure out the VFIO group thing and how to assign > >PCI B:D:F devices to the SWIOTLB-IOMMU driver. Perhaps the same way as > >xen-pciback does (or pcistub). That is by writting the BDF in the "bind" > >attribute in SysFS (or via a kernel parameter). > > > > Did uio provide this un-secure support, and just needs some attention > upstream? I don't recall how UIO did it. Not sure if it even had the group support. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
