Re: RFC: vfio / iommu driver for hardware with no iommu

[Don Dutile <ddutile-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 04/30/2013 03:11 PM, Konrad Rzeszutek Wilk wrote:
>>>> 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.
no group support. probably doesn't have an iommu-like api either...

sounds like a no-iommu iommu interface is needed! :-p
(Alex: that slipped out! sorry!)