[PATCH v4 5/6] iommu/iova: Extend rbtree node caching

The cached node mechanism provides a significant performance benefit for allocations using a 32-bit DMA mask, but in the case of non-PCI devices or where the 32-bit space is full, the loss of this benefit can be significant - on large systems there can be many thousands of entries in the tree,

[PATCH v4 4/6] iommu/iova: Simplify cached node logic

The logic of __get_cached_rbnode() is a little obtuse, but then __get_prev_node_of_cached_rbnode_or_last_node_and_update_limit_pfn() wouldn't exactly roll off the tongue... Now that we have the invariant that there is always a valid node to start searching downwards from, everything gets a bit

[PATCH v4 6/6] iommu/iova: Make dma_32bit_pfn implicit

From: Zhen Lei Now that the cached node optimisation can apply to all allocations, the couple of users which were playing tricks with dma_32bit_pfn in order to benefit from it can stop doing so. Conversely, there is also no need for all the other users to explicitly

[PATCH v4 3/6] iommu/iova: Add rbtree anchor node

Add a permanent dummy IOVA reservation to the rbtree, such that we can always access the top of the address space instantly. The immediate benefit is that we remove the overhead of the rb_last() traversal when not using the cached node, but it also paves the way for further simplifications.

[PATCH v4 2/6] iommu/iova: Optimise the padding calculation

From: Zhen Lei The mask for calculating the padding size doesn't change, so there's no need to recalculate it every loop iteration. Furthermore, Once we've done that, it becomes clear that we don't actually need to calculate a padding size at all - by flipping the

[PATCH v4 0/6] Optimise 64-bit IOVA allocations

v3: https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg19694.html This was supposed to be just a rebase and repost, but in the meantime I kept scratching the itch and ended up with two extra patches to simplify the end result even more - the series was least churny with them added

[PATCH v4 1/6] iommu/iova: Optimise rbtree searching

From: Zhen Lei Checking the IOVA bounds separately before deciding which direction to continue the search (if necessary) results in redundantly comparing both pfns twice each. GCC can already determine that the final comparison op is redundant and optimise it down to

RE: [PATCH v7 1/5] Doc: iommu/arm-smmu-v3: Add workaround for HiSilicon erratum 161010801

> -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Tuesday, September 19, 2017 3:53 PM > To: Shameerali Kolothum Thodi > Cc: lorenzo.pieral...@arm.com; marc.zyng...@arm.com; > sudeep.ho...@arm.com; will.dea...@arm.com;

Re: [PATCH v7 1/5] Doc: iommu/arm-smmu-v3: Add workaround for HiSilicon erratum 161010801

On Thu, Sep 14, 2017 at 01:57:52PM +0100, Shameer Kolothum wrote: > From: John Garry > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon > platforms > hip06/hip07 to support the SMMU mappings for MSI transactions. > > On these platforms, GICv3 ITS

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

On Tue, Sep 19, 2017 at 8:30 AM, Joerg Roedel wrote: > Hi Rob, > > thanks for the RFC patch. I have some comments about the interface to > the IOMMU-API below. > > On Thu, Sep 14, 2017 at 03:44:33PM -0400, Rob Clark wrote: >> +/** >> + * iommu_domain_resume - Resume translations

Re: [RFC PATCH 1/1] iommu/arm-smmu: Add support for multiple TBU child devices

On Tue, Sep 12, 2017 at 05:31:07PM +0530, Vivek Gautam wrote: > ARM MMU-500 implements a TBU (uTLB) for each connected master > besides a single TCU which controls and manages the address > translations. Each of these TBUs can either be in the same > power domain as the master, or they can have a

[PATCH 3/3] iommu/iova: Try harder to allocate from rcache magazine

When devices with different DMA masks are using the same domain, or for PCI devices where we usually try a speculative 32-bit allocation first, there is a fair possibility that the top PFN of the rcache stack at any given time may be unsuitable for the lower limit, prompting a fallback to

[PATCH 2/3] iommu/iova: Make rcache limit_pfn handling more robust

When popping a pfn from an rcache, we are currently checking it directly against limit_pfn for viability. Since this represents iova->pfn_lo, it is technically possible for the corresponding iova->pfn_hi to be greater than limit_pfn. Although we generally get away with it in practice since

[PATCH 0/3] Misc IOVA tweaks

While I was elbow-deep in the IOVA code, a few other things came to light which don't really fit into the rbtree optimisation series. Patches #1 and #2 are more or less just cleanup, while patch #3 complements Tomasz' recent PCI allocation patch as it aims to potentially improve the same

[PATCH 1/3] iommu/iova: Simplify domain destruction

All put_iova_domain() should have to worry about is freeing memory - by that point the domain must no longer be live, so the act of cleaning up doesn't need to be concurrency-safe or maintain the rbtree in a self-consistent state. There's no need to waste time with locking or emptying the rcache

Re: [PATCH] iommu: QCOM_IOMMU should depend on HAS_DMA

On Mon, Sep 11, 2017 at 02:34:34PM +0200, Geert Uytterhoeven wrote: > > Fixes: 0ae349a0f33fb040 ("iommu/qcom: Add qcom_iommu") > Signed-off-by: Geert Uytterhoeven > --- > drivers/iommu/Kconfig | 1 + > 1 file changed, 1 insertion(+) Applied, thanks.

Re: [PATCH] iommu/exynos: Rework runtime PM links management

On Fri, Sep 15, 2017 at 01:05:08PM +0200, Marek Szyprowski wrote: > add_device is a bit more suitable for establishing runtime PM links than > the xlate callback. This change also makes it possible to implement proper > cleanup - in remove_device callback. > > Signed-off-by: Marek Szyprowski

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

Hi Rob, thanks for the RFC patch. I have some comments about the interface to the IOMMU-API below. On Thu, Sep 14, 2017 at 03:44:33PM -0400, Rob Clark wrote: > +/** > + * iommu_domain_resume - Resume translations for a domain after a fault. > + * > + * This can be called at some point after the

Re: [PATCH] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD

On 14/09/17 06:08, Yisheng Xie wrote: > According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL > is not 0b00, which means we should not disable stall mode if stall > or terminate mode is not configuable. > > As Jean-Philippe's suggestion, this patch introduce a feature bit >

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

Hi Laurent, On 19/09/17 08:07, Laurent Pinchart wrote: > Hi Liviu, > > Thank you for the patch. > > On Monday, 18 September 2017 13:04:44 EEST Liviu Dudau wrote: >> If the IPMMU driver is compiled in the kernel it will replace the >> platform bus IOMMU ops on running the ipmmu_init() function,

Re: [RFC] virtio-iommu version 0.4

Hi Eric, On 12/09/17 18:13, Auger Eric wrote: > 2.6.7 > - As I am currently integrating v0.4 in QEMU here are some other comments: > At the moment struct virtio_iommu_req_probe flags is missing in your > header. As such I understood the ACK protocol was not implemented by the > driver in your

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

On 19/09/17 10:42, Leizhen (ThunderTown) wrote: [...] static void __cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free) { struct iova *cached_iova; -struct rb_node *curr; +struct rb_node **curr = NULL; -if

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

On Tue, Sep 19, 2017 at 10:07:58AM +0300, Laurent Pinchart wrote: > Hi Liviu, > > Thank you for the patch. > > On Monday, 18 September 2017 13:04:44 EEST Liviu Dudau wrote: > > If the IPMMU driver is compiled in the kernel it will replace the > > platform bus IOMMU ops on running the

Re: [PATCH] iommu: dmar: fix harmless section mismatch warning

On Tue, Sep 12, 2017 at 10:10:21PM +0200, Arnd Bergmann wrote: > Building with gcc-4.6 results in this warning due to > dmar_table_print_dmar_entry being inlined as in newer compiler versions: > > WARNING: vmlinux.o(.text+0x5c8bee): Section mismatch in reference from the > function

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

On 2017/7/31 19:42, Robin Murphy wrote: > Hi Nate, > > On 29/07/17 04:57, Nate Watterson wrote: >> Hi Robin, >> I am seeing a crash when performing very basic testing on this series >> with a Mellanox CX4 NIC. I dug into the crash a bit, and think this >> patch is the culprit, but this rcache

Re: [PATCH] iommu: Add missing dependencies

On Sun, Sep 10, 2017 at 01:43:37PM -0700, Guenter Roeck wrote: > parisc:allmodconfig, xtensa:allmodconfig, and possibly others generate > the following Kconfig warning. > > warning: (IPMMU_VMSA && ARM_SMMU && ARM_SMMU_V3 && QCOM_IOMMU) selects > IOMMU_IO_PGTABLE_LPAE which has unmet direct

Re: [PATCH] iommu/amd: Use raw_cpu_ptr() instead of get_cpu_ptr() for ->flush_queue

Hi Sebastian, On Wed, Sep 06, 2017 at 12:34:59PM +0200, Sebastian Andrzej Siewior wrote: > get_cpu_ptr() disables preemption and returns the ->flush_queue object > of the current CPU. raw_cpu_ptr() does the same except that it not > disable preemption which means the scheduler can move it to

Re: [PATCH v2 0/2] Dual MMU support for TI DRA7xx DSPs

On Tue, Sep 05, 2017 at 05:56:16PM -0500, Suman Anna wrote: > Suman Anna (2): > iommu/omap: Change the attach detection logic > iommu/omap: Add support to program multiple iommus > > drivers/iommu/omap-iommu.c | 375 > ++--- >

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

Hi Nate, On 19.09.2017 04:57, Nate Watterson wrote: 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

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

Hi Robin, On 18.09.2017 18:02, 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

Re: Seeing conflict with IPMMU driver under ACPI

Hi Ananth, On Tuesday, 19 September 2017 09:54:49 EEST Jasty, Ananth wrote: > On Sep 18, 2017, at 11:49 PM, Laurent Pinchart wrote: > > On Tuesday, 19 September 2017 03:43:05 EEST Jasty, Ananth wrote: > >> Hi, with your IPMMU driver enabled under 4.13 we’re seeing a crash on > >> boot: > >> > >>

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

Hi Liviu, Thank you for the patch. On Monday, 18 September 2017 13:04:44 EEST Liviu Dudau wrote: > 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

Re: Seeing conflict with IPMMU driver under ACPI

On Sep 18, 2017, at 11:49 PM, Laurent Pinchart > wrote: Hi Ananth, On Tuesday, 19 September 2017 03:43:05 EEST Jasty, Ananth wrote: Hi, with your IPMMU driver enabled under 4.13 we’re seeing a crash on boot: [

Re: Seeing conflict with IPMMU driver under ACPI

Hi Ananth, On Tuesday, 19 September 2017 03:43:05 EEST Jasty, Ananth wrote: > 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

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

On 2017/9/19 12:31, Nate Watterson wrote: > 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 >>