[v7,0/6] Add non-strict mode support for iommu-dma

Message

Robin Murphy Sept. 14, 2018, 2:30 p.m. UTC

Hi all,

Since we'd like to get this polished up and merged and Leizhen has other
commitments, here's v7 of the previous series[1] wherein I address all
my own feedback :) This is a quick tweak of the v6 I sent yesterday
since I figured out slightly too late a much neater way of setting the
attribute at the appropriate time.

The principal change is that I've inverted things slightly such that
it's now a generic domain attribute controlled by iommu-dma given the
necessary support from individual IOMMU drivers. That way we can easily
enable other drivers straight away, as I've done for SMMUv2 here (which
also allowed me to give it a quick test with MMU-401s on a Juno board).
Otherwise it's really just cosmetic cleanup and rebasing onto Will's
pending SMMU queue.

Robin.

[1] https://www.mail-archive.com/[e-mail]/msg25150.html


Robin Murphy (1):
  iommu/arm-smmu: Support non-strict mode

Zhen Lei (5):
  iommu/arm-smmu-v3: Implement flush_iotlb_all hook
  iommu/dma: Add support for non-strict mode
  iommu/io-pgtable-arm: Add support for non-strict mode
  iommu: Add bootup option "iommu.non_strict"
  iommu/arm-smmu-v3: Add support for non-strict mode

 .../admin-guide/kernel-parameters.txt         | 13 ++++++
 drivers/iommu/arm-smmu-v3.c                   | 40 +++++++++++++++----
 drivers/iommu/arm-smmu.c                      | 40 +++++++++++++++----
 drivers/iommu/dma-iommu.c                     | 29 +++++++++++++-
 drivers/iommu/io-pgtable-arm.c                |  9 +++--
 drivers/iommu/io-pgtable.h                    |  5 +++
 drivers/iommu/iommu.c                         | 26 ++++++++++++
 include/linux/iommu.h                         |  1 +
 8 files changed, 145 insertions(+), 18 deletions(-)

Comments

Will Deacon Sept. 18, 2018, 5:10 p.m. UTC | #1

Hi Robin,

Thanks for turning this around so quickly.

On Fri, Sep 14, 2018 at 03:30:18PM +0100, Robin Murphy wrote:
> Since we'd like to get this polished up and merged and Leizhen has other
> commitments, here's v7 of the previous series[1] wherein I address all
> my own feedback :) This is a quick tweak of the v6 I sent yesterday
> since I figured out slightly too late a much neater way of setting the
> attribute at the appropriate time.
> 
> The principal change is that I've inverted things slightly such that
> it's now a generic domain attribute controlled by iommu-dma given the
> necessary support from individual IOMMU drivers. That way we can easily
> enable other drivers straight away, as I've done for SMMUv2 here (which
> also allowed me to give it a quick test with MMU-401s on a Juno board).
> Otherwise it's really just cosmetic cleanup and rebasing onto Will's
> pending SMMU queue.

I've been through and had a look, leaving some small comments on the patches
themselves. The only part I failed to figure out is how you tie the lifetime
of the flush queue to the lifetime of the domain so that the timer callback
can't fire after e.g. the DMA cookie has been freed. How does that work?

Cheers,

Will

Robin Murphy Sept. 18, 2018, 6:28 p.m. UTC | #2

Hi Will,

On 2018-09-18 6:10 PM, Will Deacon wrote:
> Hi Robin,
> 
> Thanks for turning this around so quickly.

Cheers for a pretty rapid review too :)

> On Fri, Sep 14, 2018 at 03:30:18PM +0100, Robin Murphy wrote:
>> Since we'd like to get this polished up and merged and Leizhen has other
>> commitments, here's v7 of the previous series[1] wherein I address all
>> my own feedback :) This is a quick tweak of the v6 I sent yesterday
>> since I figured out slightly too late a much neater way of setting the
>> attribute at the appropriate time.
>>
>> The principal change is that I've inverted things slightly such that
>> it's now a generic domain attribute controlled by iommu-dma given the
>> necessary support from individual IOMMU drivers. That way we can easily
>> enable other drivers straight away, as I've done for SMMUv2 here (which
>> also allowed me to give it a quick test with MMU-401s on a Juno board).
>> Otherwise it's really just cosmetic cleanup and rebasing onto Will's
>> pending SMMU queue.
> 
> I've been through and had a look, leaving some small comments on the patches
> themselves. The only part I failed to figure out is how you tie the lifetime
> of the flush queue to the lifetime of the domain so that the timer callback
> can't fire after e.g. the DMA cookie has been freed. How does that work?

Er, to be honest I haven't looked or even considered it! Other than the 
parts I've massaged I kinda took the functionality of the previous 
series for granted. Let me cross-check the x86 code and figure it out.

Robin.