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

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

On 04/30/2013 05:15 PM, Alex Williamson wrote:
> On Tue, 2013-04-30 at 16:48 -0400, Don Dutile wrote:
>> 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...
>
> It doesn't, in fact uio-pci doesn't even allow enabling bus master
> because there's zero isolation.
>
>> sounds like a no-iommu iommu interface is needed! :-p
>> (Alex: that slipped out! sorry!)
>
> I wouldn't say "needed", I'm really not sure how or why this is even
> practical.  What would we do with a userspace driver interface that's
> backed by a software IOMMU that provides neither translation nor
> isolation?  This is exactly why I suggested to the freescale guys that
> it should be some kind of vfio-fake-iommu backend with very, very strict
> capability checking and no default loading.  Thanks,
>
> Alex
>
that's what I would expect as well.  but it's still a wonky fake-iommu...
writing code to do almost nothing.... sounds like pci-stub! :)