lkml.org 
[lkml]   [2021]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC 06/20] iommu: Add iommu_device_init[exit]_user_dma interfaces
Date
Hi Jason,

On 2021/9/28 19:57, Jason Gunthorpe wrote:
> On Tue, Sep 28, 2021 at 07:30:41AM +0000, Tian, Kevin wrote:
>
>>> Also, don't call it "hint", there is nothing hinty about this, it has
>>> definitive functional impacts.
>>
>> possibly dma_mode (too broad?) or dma_usage
>
> You just need a flag to specify if the driver manages DMA ownership
> itself, or if it requires the driver core to setup kernel ownership
>
> DMA_OWNER_KERNEL
> DMA_OWNER_DRIVER_CONTROLLED
>
> ?
>
> There is a bool 'suprress_bind_attrs' already so it could be done like
> this:
>
> bool suppress_bind_attrs:1;
>
> /* If set the driver must call iommu_XX as the first action in probe() */
> bool suppress_dma_owner:1;
>
> Which is pretty low cost.

Yes. Pretty low cost to fix the BUG_ON() issue. Any kernel-DMA driver
binding is blocked if the device's iommu group has been put into user-
dma mode.

Another issue is, when putting a device into user-dma mode, all devices
belonging to the same iommu group shouldn't be bound with a kernel-dma
driver. Kevin's prototype checks this by READ_ONCE(dev->driver). This is
not lock safe as discussed below,

https://lore.kernel.org/linux-iommu/20210927130935.GZ964074@nvidia.com/

Any guidance on this?

Best regards,
baolu

\
 
 \ /
  Last update: 2021-09-28 15:37    [W:0.208 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site