Re: [PATCH v2 0/3] arm-smmu: performance optimization

Hi Leizhen, On 9/12/2017 9:00 AM, Zhen Lei wrote: v1 -> v2: base on (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing") Zhen Lei (3): iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction iommu/arm-smmu-v3: add support for unmap an iova range

bind pasid table API

Hi Jean and All, This is a follow-up on the LPC discussion we had last week. (https://linuxplumbersconf.org/2017/ocw/proposals/4748) My understanding is that the data structure below can satisfy the needs from Intel (pointer + size) and AMD (pointer only). But ARM pvIOMMU would need additional

Re: [PATCH 1/1] iommu/iova: Make rcache flush optional on IOVA allocation failure

Hi Tomasz, On 9/18/2017 12:02 PM, Robin Murphy wrote: Hi Tomasz, On 18/09/17 11:56, Tomasz Nowicki wrote: Since IOVA allocation failure is not unusual case we need to flush CPUs' rcache in hope we will succeed in next round. However, it is useful to decide whether we need rcache flush step

Seeing conflict with IPMMU driver under ACPI

Hi, with your IPMMU driver enabled under 4.13 we’re seeing a crash on boot: [ 13.785164] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 13.793254] [0018] user address but active_mm is swapper [ 13.799600] Internal error: Oops: 9604 [#1] SMP [

Re: [PATCH 3/4] iommu/arm-smmu: Disable stalling faults for all endpoints

On Mon, Sep 18, 2017 at 1:33 PM, Will Deacon wrote: > On Wed, Sep 13, 2017 at 03:31:20PM -0400, Rob Clark wrote: >> On Fri, Dec 16, 2016 at 6:54 AM, Will Deacon wrote: >> > Hi Rob, >> > >> > On Tue, Dec 06, 2016 at 06:30:21PM -0500, Rob Clark wrote: >>

Re: [PATCH 3/4] iommu/arm-smmu: Disable stalling faults for all endpoints

On Wed, Sep 13, 2017 at 03:31:20PM -0400, Rob Clark wrote: > On Fri, Dec 16, 2016 at 6:54 AM, Will Deacon wrote: > > Hi Rob, > > > > On Tue, Dec 06, 2016 at 06:30:21PM -0500, Rob Clark wrote: > >> On Thu, Aug 18, 2016 at 9:05 AM, Will Deacon wrote: > >>

Re: [RFC] iommu: arm-smmu: stall support

On Mon, Sep 18, 2017 at 08:11:47AM -0400, Rob Clark wrote: > IIRC Will or Robin mentioned wanting a token in earlier stall > discussion.. although not being familiar with v3 I wasn't quite sure > what the use was. > > At any rate, adding a token to fault handler callback and >

Re: [PATCH 1/1] iommu/iova: Make rcache flush optional on IOVA allocation failure

Hi Tomasz, On 18/09/17 11:56, Tomasz Nowicki wrote: > Since IOVA allocation failure is not unusual case we need to flush > CPUs' rcache in hope we will succeed in next round. > > However, it is useful to decide whether we need rcache flush step because > of two reasons: > - Not scalability. On

[PATCH 2/2] iommu/io-pgtable-arm-v7s: Convert to IOMMU API TLB sync

Now that the core API issues its own post-unmap TLB sync call, push that operation out from the io-pgtable-arm-v7s internals into the users. For now, we leave the invalidation implicit in the unmap operation, since none of the current users would benefit much from any change to that. Note that

[PATCH 1/2] iommu/io-pgtable-arm: Convert to IOMMU API TLB sync

Now that the core API issues its own post-unmap TLB sync call, push that operation out from the io-pgtable-arm internals into the users. For now, we leave the invalidation implicit in the unmap operation, since none of the current users would benefit much from any change to that. CC: Magnus Damm

[PATCH 1/1] iommu/iova: Make rcache flush optional on IOVA allocation failure

Since IOVA allocation failure is not unusual case we need to flush CPUs' rcache in hope we will succeed in next round. However, it is useful to decide whether we need rcache flush step because of two reasons: - Not scalability. On large system with ~100 CPUs iterating and flushing rcache for

[PATCH 0/1] Optimise IOVA allocations for PCI devices

Here is my test setup where I have stareted performance measurements. PCIe - TX - PCIe - | ThunderX2 |--| Intel XL710 | ---> | Intel XL710 |--| X86 | | (128 cpus) | | 40GbE | |40GbE| -

Re: [RFC] iommu: arm-smmu: stall support

On Mon, Sep 18, 2017 at 7:13 AM, Jean-Philippe Brucker wrote: > Hi Rob, > > On 14/09/17 20:44, Rob Clark wrote: >> Adds a new domain property for iommu clients to opt-in to stalling >> with asynchronous resume, and for the client to determine if the >> iommu

Re: [RFC] iommu: arm-smmu: stall support

Hi Rob, On 14/09/17 20:44, Rob Clark wrote: > Adds a new domain property for iommu clients to opt-in to stalling > with asynchronous resume, and for the client to determine if the > iommu supports this. > > Current motivation is that: > > a) On 8x96/a530, if we don't enable CFCFG (or HUPCF)

[PATCH] iommu/ipmmu-vmsa: Do not replace bus IOMMU ops on driver init.

If the IPMMU driver is compiled in the kernel it will replace the platform bus IOMMU ops on running the ipmmu_init() function, regardless if there is any IPMMU hardware present or not. This screws up systems that just want to build a generic kernel that runs on multiple platforms and use a