lkml.org 
[lkml]   [2021]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 02/11] driver core: Set DMA ownership during driver bind/unbind
From
On 2021-11-15 15:56, Jason Gunthorpe via iommu wrote:
> On Mon, Nov 15, 2021 at 03:37:18PM +0000, Robin Murphy wrote:
>
>> IOMMUs, and possibly even fewer of them support VFIO, so I'm in full
>> agreement with Greg and Christoph that this absolutely warrants being scoped
>> per-bus. I mean, we literally already have infrastructure to prevent drivers
>> binding if the IOMMU/DMA configuration is broken or not ready yet; why would
>> we want a totally different mechanism to prevent driver binding when the
>> only difference is that that configuration *is* ready and working to the
>> point that someone's already claimed it for other purposes?
>
> I see, that does make sense
>
> I see these implementations:
>
> drivers/amba/bus.c: .dma_configure = platform_dma_configure,
> drivers/base/platform.c: .dma_configure = platform_dma_configure,
> drivers/bus/fsl-mc/fsl-mc-bus.c: .dma_configure = fsl_mc_dma_configure,
> drivers/pci/pci-driver.c: .dma_configure = pci_dma_configure,
> drivers/gpu/host1x/bus.c: .dma_configure = host1x_dma_configure,
>
> Other than host1x they all work with VFIO.
>
> Also, there is no bus->dma_unconfigure() which would be needed to
> restore the device as well.

Not if we reduce the notion of "ownership" down to
"dev->iommu_group->domain != dev->iommu_group->default_domain", which
I'm becoming increasingly convinced is all we actually need here.

> So, would you rather see duplicated code into the 4 drivers, and a new
> bus op to 'unconfigure dma'

The .dma_configure flow is unavoidably a bit boilerplatey already, so
personally I'd go for having the implementations call back into a common
check, similarly to their current flow. That also leaves room for the
bus code to further refine the outcome based on what it might know,
which I can particularly imagine for cleverer buses like fsl-mc and
host1x which can have lots of inside knowledge about how their devices
may interact.

Robin.

> Or, a 'dev_configure_dma()' function that is roughly:
>
> if (dev->bus->dma_configure) {
> ret = dev->bus->dma_configure(dev);
> if (ret)
> return ret;
> if (!drv->suppress_auto_claim_dma_owner) {
> ret = iommu_device_set_dma_owner(dev, DMA_OWNER_KERNEL,
> NULL);
> if (ret)
> ret;
> }
> }
>
> And a pair'd undo.
>
> This is nice because we can enforce dev->bus->dma_configure when doing
> a user bind so everything holds together safely without relying on
> each bus_type to properly implement security.
>
> Jason
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>

\
 
 \ /
  Last update: 2021-11-15 23:33    [W:0.082 / U:0.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site