Re: [PATCH 2/2] iommu/arm-smmu: Add system PM support

2017-08-11 Thread Jonathan Cameron
On Tue, 8 Aug 2017 13:14:18 +0100 Robin Murphy wrote: > On 08/08/17 12:18, Will Deacon wrote: > > On Tue, Jul 18, 2017 at 01:44:42PM +0100, Robin Murphy wrote: > >> With all our hardware state tracked in such a way that we can naturally > >> restore it as part of the

Re: [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

2017-07-17 Thread Jonathan Cameron
On Mon, 17 Jul 2017 14:06:42 +0100 John Garry wrote: > + > > On 29/06/2017 03:08, Leizhen (ThunderTown) wrote: > > > > > > On 2017/6/28 17:32, Will Deacon wrote: > >> Hi Zhen Lei, > >> > >> Nate (CC'd), Robin and I have been working on something very similar to > >>

Re: [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

2017-07-18 Thread Jonathan Cameron
On Mon, 17 Jul 2017 13:28:47 -0400 Nate Watterson <nwatt...@codeaurora.org> wrote: > Hi Jonathan, > > On 7/17/2017 10:23 AM, Jonathan Cameron wrote: > > On Mon, 17 Jul 2017 14:06:42 +0100 > > John Garry <john.ga...@huawei.com> wrote: > > > &

Re: [PATCH v2 07/40] iommu: Add a page fault handler

2018-05-17 Thread Jonathan Cameron
On Fri, 11 May 2018 20:06:08 +0100 Jean-Philippe Brucker wrote: > Some systems allow devices to handle I/O Page Faults in the core mm. For > example systems implementing the PCI PRI extension or Arm SMMU stall > model. Infrastructure for reporting these recoverable

Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces

2018-05-17 Thread Jonathan Cameron
On Fri, 11 May 2018 20:06:04 +0100 Jean-Philippe Brucker wrote: > Allocate IOMMU mm structures and binding them to devices. Four operations > are added to IOMMU drivers: > > * mm_alloc(): to create an io_mm structure and perform architecture- > specific

Re: [PATCH v2 02/40] iommu/sva: Bind process address spaces to devices

2018-05-17 Thread Jonathan Cameron
On Fri, 11 May 2018 20:06:03 +0100 Jean-Philippe Brucker wrote: > Add bind() and unbind() operations to the IOMMU API. Bind() returns a > PASID that drivers can program in hardware, to let their devices access an > mm. This patch only adds skeletons for the device

Re: [PATCH v2 17/40] iommu/arm-smmu-v3: Link domains and devices

2018-05-17 Thread Jonathan Cameron
On Fri, 11 May 2018 20:06:18 +0100 Jean-Philippe Brucker wrote: > When removing a mapping from a domain, we need to send an invalidation to > all devices that might have stored it in their Address Translation Cache > (ATC). In addition when updating the context

Re: [PATCH v2 05/40] iommu/sva: Track mm changes with an MMU notifier

2018-05-17 Thread Jonathan Cameron
On Fri, 11 May 2018 20:06:06 +0100 Jean-Philippe Brucker wrote: > When creating an io_mm structure, register an MMU notifier that informs > us when the virtual address space changes and disappears. > > Add a new operation to the IOMMU driver, mm_invalidate, called

Re: [PATCH v2 13/40] vfio: Add support for Shared Virtual Addressing

2018-05-17 Thread Jonathan Cameron
On Fri, 11 May 2018 20:06:14 +0100 Jean-Philippe Brucker wrote: > Add two new ioctls for VFIO containers. VFIO_IOMMU_BIND_PROCESS creates a > bond between a container and a process address space, identified by a > Process Address Space ID (PASID). Devices in the

Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces

2018-05-25 Thread Jonathan Cameron
+CC Kenneth Lee On Fri, 25 May 2018 09:33:11 +0300 Ilias Apalodimas wrote: > On Thu, May 24, 2018 at 04:04:39PM +0100, Jean-Philippe Brucker wrote: > > On 24/05/18 12:50, Ilias Apalodimas wrote: > > >> Interesting, I hadn't thought about this use-case before. At

Re: Preferred method to detect if a device is behind an enabled iommu.

2018-02-01 Thread Jonathan Cameron
On Thu, 1 Feb 2018 12:49:24 + Robin Murphy <robin.mur...@arm.com> wrote: > On 01/02/18 10:18, Jonathan Cameron wrote: > > Hi All, > > > > We have a crypto accelerator which needs to have a few different settings > > depending on whether or not the SMMUv3 is

Preferred method to detect if a device is behind an enabled iommu.

2018-02-01 Thread Jonathan Cameron
/dma/rcar-dmac.c) but the precedence is weak enough that confirmation would be good. So whilst it 'works' the question is whether it is safe in general and whether there is a better way. Thanks, -- Jonathan Cameron Huawei ___ iommu mailing list iommu

Re: [PATCH 27/37] iommu/arm-smmu-v3: Register fault workqueue

2018-03-08 Thread Jonathan Cameron
On Mon, 12 Feb 2018 18:33:42 + Jean-Philippe Brucker wrote: > When using PRI or Stall, the PRI or event handler enqueues faults into the > core fault queue. Register it based on the SMMU features. > > When the core stops using a PASID, it notifies the SMMU to

Re: [PATCH 31/37] iommu/arm-smmu-v3: Add support for PCI ATS

2018-03-08 Thread Jonathan Cameron
On Mon, 12 Feb 2018 18:33:46 + Jean-Philippe Brucker wrote: > PCIe devices can implement their own TLB, named Address Translation Cache > (ATC). Enable Address Translation Service (ATS) for devices that support > it and send them invalidation requests whenever

Re: [PATCH 28/37] iommu/arm-smmu-v3: Maintain a SID->device structure

2018-03-08 Thread Jonathan Cameron
On Mon, 12 Feb 2018 18:33:43 + Jean-Philippe Brucker wrote: > When handling faults from the event or PRI queue, we need to find the > struct device associated to a SID. Add a rb_tree to keep track of SIDs. > > Signed-off-by: Jean-Philippe Brucker

Re: [PATCH 35/37] iommu/arm-smmu-v3: Add support for PRI

2018-03-08 Thread Jonathan Cameron
On Mon, 12 Feb 2018 18:33:50 + Jean-Philippe Brucker wrote: > For PCI devices that support it, enable the PRI capability and handle > PRI Page Requests with the generic fault handler. > > Signed-off-by: Jean-Philippe Brucker A

Re: [PATCH 07/37] iommu: Add a page fault handler

2018-03-08 Thread Jonathan Cameron
On Mon, 12 Feb 2018 18:33:22 + Jean-Philippe Brucker wrote: > Some systems allow devices to handle IOMMU translation faults in the core > mm. For example systems supporting the PCI PRI extension or Arm SMMU stall > model. Infrastructure for reporting such

Re: [PATCH 17/37] iommu/arm-smmu-v3: Move context descriptor code

2018-03-09 Thread Jonathan Cameron
On Mon, 12 Feb 2018 18:33:32 + Jean-Philippe Brucker wrote: > In order to add support for substream ID, move the context descriptor code > into a separate library. At the moment it only manages context descriptor > 0, which is used for non-PASID translations. >

Re: [PATCH v2 08/21] iio: adc: Remove depends on HAS_DMA in case of platform dependency

2018-03-17 Thread Jonathan Cameron
ove compile-testing. > > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> > Reviewed-by: Mark Brown <broo...@kernel.org> > Acked-by: Robin Murphy <robin.mur...@arm.com> Great. Acked-by: Jonathan Cameron <jonathan.came...@huawei.com> Thanks for doin

Re: [PATCH v5 4/8] iommu/vt-d: Aux-domain specific domain attach/detach

2019-01-15 Thread Jonathan Cameron
On Tue, 15 Jan 2019 10:10:21 +0800 Lu Baolu wrote: > Hi, > > On 1/14/19 8:26 PM, Jonathan Cameron wrote: > > On Thu, 10 Jan 2019 11:00:23 +0800 > > Lu Baolu wrote: > > > >> When multiple domains per device has been enabled by the > >> device

Re: [PATCH v5 3/8] iommu/vt-d: Move common code out of iommu_attch_device()

2019-01-14 Thread Jonathan Cameron
On Thu, 10 Jan 2019 11:00:22 +0800 Lu Baolu wrote: > This part of code could be used by both normal and aux > domain specific attach entries. Hence move them into a > common function to avoid duplication. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Signed-off-by: Lu Baolu Another

Re: [PATCH v5 1/8] iommu: Add APIs for multiple domains per device

2019-01-14 Thread Jonathan Cameron
On Thu, 10 Jan 2019 11:00:20 +0800 Lu Baolu wrote: > Sharing a physical PCI device in a finer-granularity way > is becoming a consensus in the industry. IOMMU vendors > are also engaging efforts to support such sharing as well > as possible. Among the efforts, the capability of support >

Re: [PATCH 3/8] iommu/arm-smmu-v3: Support platform SSID

2019-06-11 Thread Jonathan Cameron
On Mon, 10 Jun 2019 19:47:09 +0100 Jean-Philippe Brucker wrote: > For platform devices that support SubstreamID (SSID), firmware provides > the number of supported SSID bits. Restrict it to what the SMMU supports > and cache it into master->ssid_bits. > > Signed-off-by: Jean-Philippe Brucker

Re: [PATCH 4/8] iommu/arm-smmu-v3: Add support for Substream IDs

2019-06-11 Thread Jonathan Cameron
On Mon, 10 Jun 2019 19:47:10 +0100 Jean-Philippe Brucker wrote: > At the moment, the SMMUv3 driver implements only one stage-1 or stage-2 > page directory per device. However SMMUv3 allows more than one address > space for some devices, by providing multiple stage-1 page directories. In >

Re: [PATCH 8/8] iommu/arm-smmu-v3: Add support for PCI PASID

2019-06-11 Thread Jonathan Cameron
On Mon, 10 Jun 2019 19:47:14 +0100 Jean-Philippe Brucker wrote: > Enable PASID for PCI devices that support it. Since the SSID tables are > allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough. > arm_smmu_dev_feature_enable() would be too late, since by that time the > main

Re: [PATCH 5/8] iommu/arm-smmu-v3: Add second level of context descriptor table

2019-06-11 Thread Jonathan Cameron
On Mon, 10 Jun 2019 19:47:11 +0100 Jean-Philippe Brucker wrote: > The SMMU can support up to 20 bits of SSID. Add a second level of page > tables to accommodate this. Devices that support more than 1024 SSIDs now > have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context >

Re: [PATCH v4 10/22] iommu: Fix compile error without IOMMU_API

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:10 -0700 Jacob Pan wrote: > struct page_response_msg needs to be defined outside CONFIG_IOMMU_API. What was the error? If this is a fix for an earlier patch in this series role it in there (or put it before it). If more general we should add a fixes tag. Jonathan >

Re: [PATCH v4 09/22] iommu: Introduce cache_invalidate API

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:09 -0700 Jacob Pan wrote: > From: Liu Yi L > > In any virtualization use case, when the first translation stage > is "owned" by the guest OS, the host IOMMU driver has no knowledge > of caching structure updates unless the guest invalidation activities > are trapped by

Re: [PATCH v4 04/22] iommu: Add recoverable fault reporting

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:04 -0700 Jacob Pan wrote: > From: Jean-Philippe Brucker > > Some IOMMU hardware features, for example PCI's PRI and Arm SMMU's Stall, > enable recoverable I/O page faults. Allow IOMMU drivers to report PRI Page > Requests and Stall events through the new fault

Re: [PATCH v4 20/22] iommu/vt-d: Add bind guest PASID support

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:20 -0700 Jacob Pan wrote: > When supporting guest SVA with emulated IOMMU, the guest PASID > table is shadowed in VMM. Updates to guest vIOMMU PASID table > will result in PASID cache flush which will be passed down to > the host as bind guest PASID calls. > > For the

Re: [PATCH v4 15/22] iommu/vt-d: Replace Intel specific PASID allocator with IOASID

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:15 -0700 Jacob Pan wrote: > Make use of generic IOASID code to manage PASID allocation, > free, and lookup. Replace Intel specific code. > > Signed-off-by: Jacob Pan Hi Jacob, One question inline. Jonathan > --- > drivers/iommu/intel-iommu.c | 11 +-- >

Re: [PATCH v4 17/22] iommu/vt-d: Avoid duplicated code for PASID setup

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:17 -0700 Jacob Pan wrote: > After each setup for PASID entry, related translation caches must be flushed. > We can combine duplicated code into one function which is less error prone. > > Signed-off-by: Jacob Pan Formatting nitpick below ;) Otherwise it's cut and

Re: [PATCH v4 02/22] iommu: Introduce device fault data

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:02 -0700 Jacob Pan wrote: > Device faults detected by IOMMU can be reported outside the IOMMU > subsystem for further processing. This patch introduces > a generic device fault data structure. > > The fault can be either an unrecoverable fault or a page request, > also

Re: [PATCH v4 08/22] iommu: Introduce attach/detach_pasid_table API

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:08 -0700 Jacob Pan wrote: > In virtualization use case, when a guest is assigned > a PCI host device, protected by a virtual IOMMU on the guest, > the physical IOMMU must be programmed to be consistent with > the guest mappings. If the physical IOMMU supports two >

Re: [PATCH v4 19/22] iommu/vt-d: Clean up for SVM device list

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:19 -0700 Jacob Pan wrote: > Use combined macro for_each_svm_dev() to simplify SVM device iteration. > > Suggested-by: Andy Shevchenko > Signed-off-by: Jacob Pan > Reviewed-by: Eric Auger > --- > drivers/iommu/intel-svm.c | 79 >

Re: [PATCH v4 12/22] iommu: Add I/O ASID allocator

2019-06-18 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:12 -0700 Jacob Pan wrote: > From: Jean-Philippe Brucker > > Some devices might support multiple DMA address spaces, in particular > those that have the PCI PASID feature. PASID (Process Address Space ID) > allows to share process address spaces with devices (SVA),

Re: [PATCH v4 03/22] iommu: Introduce device fault report API

2019-06-19 Thread Jonathan Cameron
On Sun, 9 Jun 2019 06:44:03 -0700 Jacob Pan wrote: > Traditionally, device specific faults are detected and handled within > their own device drivers. When IOMMU is enabled, faults such as DMA > related transactions are detected by IOMMU. There is no generic > reporting mechanism to report

Re: [PATCH v7 3/3] crypto: hisilicon - register zip engine to uacce

2019-11-11 Thread Jonathan Cameron
On Tue, 5 Nov 2019 16:34:48 +0800 zhangfei wrote: > Hi, Jonathan > > On 2019/11/1 上午1:53, Jonathan Cameron wrote: > > On Tue, 29 Oct 2019 14:40:16 +0800 > > Zhangfei Gao wrote: > > > >> Register qm to uacce framework for user crypto driver > >>

Re: [PATCH v7 2/3] uacce: add uacce driver

2019-11-11 Thread Jonathan Cameron
On Tue, 5 Nov 2019 15:43:31 +0800 zhangfei wrote: > Hi, Jonathan > > Thanks for the suggestions > > On 2019/11/1 上午1:13, Jonathan Cameron wrote: > > On Tue, 29 Oct 2019 14:40:15 +0800 > > Zhangfei Gao wrote: > > > >> From: Kenneth Lee > >

Re: [PATCH v2 7/8] iommu/arm-smmu-v3: Improve add_device() error handling

2019-11-11 Thread Jonathan Cameron
m there is any real connection between them so should be fine. Reviewed-by: Jonathan Cameron > --- > drivers/iommu/arm-smmu-v3.c | 28 +--- > 1 file changed, 21 insertions(+), 7 deletions(-) > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v

Re: [PATCH v2 4/8] iommu/arm-smmu-v3: Prepare for SSID support

2019-11-11 Thread Jonathan Cameron
On Fri, 8 Nov 2019 16:25:04 +0100 Jean-Philippe Brucker wrote: > When a master supports substream ID, allocate a table with multiple > context descriptors for its stage-1 domain. For the moment S1CDMax is > still 0 in the STE, so the additional context descriptors are ignored. > > Context

Re: [PATCH v2 8/8] iommu/arm-smmu-v3: Add support for PCI PASID

2019-11-11 Thread Jonathan Cameron
he > main DMA domain has already been attached. Do it in add_device() instead. > > Signed-off-by: Jean-Philippe Brucker Seems straightforward. Reviewed-by: Jonathan Cameron Thanks for working on this stuff. I hope we an move to get the rest of the SVA elements lined up behind it s

Re: [PATCH v2 6/8] iommu/arm-smmu-v3: Add second level of context descriptor table

2019-11-11 Thread Jonathan Cameron
On Fri, 8 Nov 2019 16:25:06 +0100 Jean-Philippe Brucker wrote: > The SMMU can support up to 20 bits of SSID. Add a second level of page > tables to accommodate this. Devices that support more than 1024 SSIDs now > have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context >

Re: [PATCH v2 5/8] iommu/arm-smmu-v3: Add support for Substream IDs

2019-11-11 Thread Jonathan Cameron
STE |---' SSID->| CD |---' IOVA->| PTE |--> IPA > +++---++---+ > ::: :: : > +++---++---+ > > Implement a single level of context descriptor table for now, but as with > stream and page tables, an SSID can be split to index multiple levels of > tables. >

Re: [PATCH v7 2/3] uacce: add uacce driver

2019-10-31 Thread Jonathan Cameron
On Tue, 29 Oct 2019 14:40:15 +0800 Zhangfei Gao wrote: > From: Kenneth Lee > > Uacce (Unified/User-space-access-intended Accelerator Framework) targets to > provide Shared Virtual Addressing (SVA) between accelerators and processes. > So accelerator can access any data structure of the main

Re: [PATCH v7 1/3] uacce: Add documents for uacce

2019-10-31 Thread Jonathan Cameron
On Tue, 29 Oct 2019 14:40:14 +0800 Zhangfei Gao wrote: > From: Kenneth Lee > > Uacce (Unified/User-space-access-intended Accelerator Framework) is > a kernel module targets to provide Shared Virtual Addressing (SVA) > between the accelerator and process. > > This patch add document to explain

Re: [PATCH v7 3/3] crypto: hisilicon - register zip engine to uacce

2019-10-31 Thread Jonathan Cameron
On Tue, 29 Oct 2019 14:40:16 +0800 Zhangfei Gao wrote: > Register qm to uacce framework for user crypto driver > > Signed-off-by: Zhangfei Gao > Signed-off-by: Zhou Wang Hi. This shows there is probably a race during setup that you should close. Userspace interface is exposed before the

Re: [PATCH v3 00/13] iommu: Add PASID support to Arm SMMUv3

2019-12-13 Thread Jonathan Cameron
uot;) removed the unused PASID stubs. Since the SMMU > driver can be built without PCI, the stubs are now needed. > > [1] > https://lore.kernel.org/linux-iommu/20191108152508.4039168-1-jean-phili...@linaro.org/ Hi Jean-Philippe, Series looks great to me. FWIW Reviewed-by: Jonathan C

Re: [PATCH v3 01/13] iommu/arm-smmu-v3: Drop __GFP_ZERO flag from DMA allocation

2019-12-13 Thread Jonathan Cameron
more. > > The flag was introduced by commit 04fa26c71be5 ("iommu/arm-smmu: Convert > DMA buffer allocations to the managed API"), since the managed API > didn't provide a dmam_zalloc_coherent() function. > > Signed-off-by: Jean-Philippe Brucker Reviewed-by: Jonathan Cam

Re: [PATCH v3 10/13] iommu/arm-smmu-v3: Add second level of context descriptor table

2019-12-13 Thread Jonathan Cameron
4 context > descriptors (64kB), allocated on demand. > > Signed-off-by: Jean-Philippe Brucker One tiny little comment inline. I really don't mind if you ignore it ;) Reviewed-by: Jonathan Cameron > --- > drivers/iommu/arm-smmu-v3.c | 153 +--- > 1 f

Re: [PATCH v4 02/26] iommu/sva: Manage process address spaces

2020-02-26 Thread Jonathan Cameron
On Mon, 24 Feb 2020 19:23:37 +0100 Jean-Philippe Brucker wrote: > From: Jean-Philippe Brucker > > Add a small library to help IOMMU drivers manage process address spaces > bound to their devices. Register an MMU notifier to track modification > on each address space bound to one or more

Re: [PATCH v4 03/26] iommu: Add a page fault handler

2020-02-26 Thread Jonathan Cameron
On Mon, 24 Feb 2020 19:23:38 +0100 Jean-Philippe Brucker wrote: > From: Jean-Philippe Brucker > > Some systems allow devices to handle I/O Page Faults in the core mm. For > example systems implementing the PCI PRI extension or Arm SMMU stall > model. Infrastructure for reporting these

Re: [PATCH v4 02/26] iommu/sva: Manage process address spaces

2020-02-28 Thread Jonathan Cameron
On Fri, 28 Feb 2020 15:43:04 +0100 Jean-Philippe Brucker wrote: > On Wed, Feb 26, 2020 at 12:35:06PM +0000, Jonathan Cameron wrote: > > > + * A single Process Address Space ID (PASID) is allocated for each mm. > > > In the > > > + * example, devices use PASID 1 to

Re: [PATCH v4 07/26] arm64: mm: Pin down ASIDs for sharing mm with devices

2020-02-27 Thread Jonathan Cameron
On Mon, 24 Feb 2020 19:23:42 +0100 Jean-Philippe Brucker wrote: > From: Jean-Philippe Brucker > > To enable address space sharing with the IOMMU, introduce mm_context_get() > and mm_context_put(), that pin down a context and ensure that it will keep > its ASID after a rollover. Export the

Re: [PATCH v4 23/26] iommu/arm-smmu-v3: Add stall support for platform devices

2020-02-27 Thread Jonathan Cameron
On Mon, 24 Feb 2020 19:23:58 +0100 Jean-Philippe Brucker wrote: > From: Jean-Philippe Brucker > > The SMMU provides a Stall model for handling page faults in platform > devices. It is similar to PCI PRI, but doesn't require devices to have > their own translation cache. Instead, faulting

Re: [PATCH v4 00/26] iommu: Shared Virtual Addressing and SMMUv3 support

2020-02-27 Thread Jonathan Cameron
On Mon, 24 Feb 2020 19:23:35 +0100 Jean-Philippe Brucker wrote: > Shared Virtual Addressing (SVA) allows to share process page tables with > devices using the IOMMU. Add a generic implementation of the IOMMU SVA > API, and add support in the Arm SMMUv3 driver. > > Previous versions of this

Re: [PATCH v10 2/4] uacce: add uacce driver

2020-01-09 Thread Jonathan Cameron
off-by: Zhou Wang > Signed-off-by: Jean-Philippe Brucker > Signed-off-by: Zhangfei Gao Hi, Two small things I'd missed previously. Fix those and for what it's worth Reviewed-by: Jonathan Cameron > --- > Documentation/ABI/testing/sysfs-driver-uacce | 37 ++ >

Re: [PATCH v10 3/4] crypto: hisilicon - Remove module_param uacce_mode

2020-01-09 Thread Jonathan Cameron
On Mon, 16 Dec 2019 11:08:16 +0800 Zhangfei Gao wrote: > Remove the module_param uacce_mode, which is not used currently. > > Signed-off-by: Zhangfei Gao > Signed-off-by: Zhou Wang Reviewed-by: Jonathan Cameron > --- > drivers/crypto/hisilicon/z

Re: [PATCH v10 0/4] Add uacce module for Accelerator

2020-01-09 Thread Jonathan Cameron
On Mon, 16 Dec 2019 11:08:13 +0800 Zhangfei Gao wrote: > Uacce (Unified/User-space-access-intended Accelerator Framework) targets to > provide Shared Virtual Addressing (SVA) between accelerators and processes. > So accelerator can access any data structure of the main cpu. > This differs from

Re: [PATCH v10 4/4] crypto: hisilicon - register zip engine to uacce

2020-01-09 Thread Jonathan Cameron
g at changes in a crypto driver, this will need a crypto Ack. Herbert, this is about as non invasive as things can get and provide a user space shared virtual addressing based interface. What do you think? >From my side, for what it's worth... Reviewed-by: Jonathan Cameron > --- > dri

Re: [PATCH v10 2/4] uacce: add uacce driver

2020-01-10 Thread Jonathan Cameron
On Fri, 10 Jan 2020 14:55:39 +0800 "zhangfei@foxmail.com" wrote: > On 2020/1/10 上午1:38, Jonathan Cameron wrote: > > On Mon, 16 Dec 2019 11:08:15 +0800 > > Zhangfei Gao wrote: > > > >> From: Kenneth Lee > >> > >> Uacce (Unified

Re: [PATCH v10 0/4] Add uacce module for Accelerator

2020-01-10 Thread Jonathan Cameron
On Fri, 10 Jan 2020 15:03:25 +0800 zhangfei wrote: > On 2020/1/10 上午1:49, Jonathan Cameron wrote: > > On Mon, 16 Dec 2019 11:08:13 +0800 > > Zhangfei Gao wrote: > > > >> Uacce (Unified/User-space-access-intended Accelerator Framework) targets to > >>

Re: [PATCH v4 23/26] iommu/arm-smmu-v3: Add stall support for platform devices

2020-03-09 Thread Jonathan Cameron
On Wed, 4 Mar 2020 15:08:33 +0100 Jean-Philippe Brucker wrote: > On Thu, Feb 27, 2020 at 06:17:26PM +0000, Jonathan Cameron wrote: > > On Mon, 24 Feb 2020 19:23:58 +0100 > > Jean-Philippe Brucker wrote: > > > > > From: Jean-Philippe Brucker > > >

Re: [PATCH v2] of_device: removed #include that caused a recursion in included headers

2020-04-18 Thread Jonathan Cameron
Hmm. I guess the chances of this causing merge problems are fairly low so perhaps not worth doing additions of headers via individual subsystems and actually dropping the header include after another cycle. So on that basis Acked-by: Jonathan Cameron #for-iio > --- > v2: add include to of_pla

Re: [PATCH v3 14/14] iommu/amd: Adopt IO page table framework

2020-10-05 Thread Jonathan Cameron
On Sun, 4 Oct 2020 01:45:49 + Suravee Suthikulpanit wrote: > Switch to using IO page table framework for AMD IOMMU v1 page table. > > Signed-off-by: Suravee Suthikulpanit One minor thing inline. > --- > drivers/iommu/amd/iommu.c | 26 ++ > 1 file changed, 26

Re: [PATCH v10 09/13] iommu/arm-smmu-v3: Seize private ASID

2020-09-18 Thread Jonathan Cameron
On Fri, 18 Sep 2020 12:18:49 +0200 Jean-Philippe Brucker wrote: > The SMMU has a single ASID space, the union of shared and private ASID > sets. This means that the SMMU driver competes with the arch allocator > for ASIDs. Shared ASIDs are those of Linux processes, allocated by the > arch, and

Re: [PATCH v10 00/13] iommu: Shared Virtual Addressing for SMMUv3 (PT sharing part)

2020-09-18 Thread Jonathan Cameron
pe, It's been a rather long time since I last looked at this stuff (about v4 I think!), but I just had a read through this set and they all look good to me. FWIW: Reviewed-by: Jonathan Cameron Thanks, Jonathan > > v10: > * Fix patches 3, 8, 9 and 10 following Eric's review. >

Re: [PATCH] iommu/arm-smmu-v3: expose numa_node attribute to users in sysfs

2020-07-06 Thread Jonathan Cameron
+CC Brice. On Sun, 5 Jul 2020 09:53:58 + "Song Bao Hua (Barry Song)" wrote: > > -Original Message- > > From: Will Deacon [mailto:w...@kernel.org] > > Sent: Saturday, July 4, 2020 4:22 AM > > To: Song Bao Hua (Barry Song) > > Cc: robin.mur...@arm.com; h...@lst.de;

Re: [PATCH v2 1/3] docs: IOMMU user API

2020-06-11 Thread Jonathan Cameron
On Wed, 10 Jun 2020 21:12:13 -0700 Jacob Pan wrote: > IOMMU UAPI is newly introduced to support communications between guest > virtual IOMMU and host IOMMU. There has been lots of discussions on how > it should work with VFIO UAPI and userspace in general. > > This document is indended to

Re: [PATCH 04/15] arm64: numa: simplify dummy_numa_init()

2020-07-29 Thread Jonathan Cameron
f memblocks. > > memblks[0] = [0x00..0x1f] in node 0 > memblks[1] = [0x20..0x2f] in node MAX_NUM_NODES. > > i = 2 off the end of the now reduced array of memblocks, so exit the loop. > (if we restart the loop here everything will be fine). > > Later sparse_init_nid

Re: [PATCH v9 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF

2021-01-19 Thread Jonathan Cameron
On Fri, 8 Jan 2021 15:52:13 +0100 Jean-Philippe Brucker wrote: > The IOPF (I/O Page Fault) feature is now enabled independently from the > SVA feature, because some IOPF implementations are device-specific and > do not require IOMMU support for PCIe PRI or Arm SMMU stall. > > Enable IOPF

Re: [PATCH v9 06/10] iommu: Add a page fault handler

2021-01-19 Thread Jonathan Cameron
register_device_fault_handler(). > > Signed-off-by: Jean-Philippe Brucker One really minor inconsistency inline that made me look twice.. With or without that tided up FWIW. Reviewed-by: Jonathan Cameron ... > +/** > + * iopf_queue_add_device - Add producer to the fault

Re: [PATCH v9 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure

2021-01-19 Thread Jonathan Cameron
t if you happen to be spinning again. Acked-by: Jonathan Cameron with or without that. > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 13 +- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 161 > 2 files changed, 144 insertions(+), 30 deletions(-)

Re: [PATCH v10 10/10] iommu/arm-smmu-v3: Add stall support for platform devices

2021-01-22 Thread Jonathan Cameron
On Fri, 22 Jan 2021 09:51:20 +0100 Jean-Philippe Brucker wrote: > On Thu, Jan 21, 2021 at 07:12:36PM +0000, Jonathan Cameron wrote: > > > @@ -2502,6 +2647,7 @@ static void arm_smmu_release_device(struct device > > > *dev) > > > > > > master = d

Re: [PATCH 0/3] iommu/arm-smmu-v3: TLB invalidation for SVA

2021-01-22 Thread Jonathan Cameron
/ > [4] > https://lore.kernel.org/linux-pci/1610960316-28935-1-git-send-email-zhangfei@linaro.org/ Whole series looks good to me so FWIW Reviewed-by: Jonathan Cameron Will be very nice to have mainline support for SVA with those accelerators :) > > Jean-Philippe Brucker (3): > iommu/

Re: [PATCH v10 09/10] ACPI/IORT: Enable stall support for platform devices

2021-01-21 Thread Jonathan Cameron
On Thu, 21 Jan 2021 13:36:23 +0100 Jean-Philippe Brucker wrote: > Copy the "Stall supported" bit, that tells whether a named component > supports stall, into the dma-can-stall device property. > > Signed-off-by: Jean-Philippe Brucker FWIW given how simple this is : Acke

Re: [PATCH v10 10/10] iommu/arm-smmu-v3: Add stall support for platform devices

2021-01-21 Thread Jonathan Cameron
On Thu, 21 Jan 2021 13:36:24 +0100 Jean-Philippe Brucker wrote: > The SMMU provides a Stall model for handling page faults in platform > devices. It is similar to PCIe PRI, but doesn't require devices to have > their own translation cache. Instead, faulting transactions are parked > and the OS

Re: [PATCH v9 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits

2021-01-19 Thread Jonathan Cameron
ested-by: Robin Murphy > Signed-off-by: Jean-Philippe Brucker Nice Acked-by: Jonathan Cameron Looks like we are fine not checking for missing properties because ssid_bits == 0 corresponds to pasid off anyway. > --- > include/linux/iommu.h | 2 -- >

Re: [PATCH v11 10/10] iommu/arm-smmu-v3: Add stall support for platform devices

2021-01-25 Thread Jonathan Cameron
. Either fix that or tell me why you don't need it and then I'm happy. With that resolved Reviewed-by: Jonathan Cameron > --- > git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > index bb251cab61f3..ee66d1f4cb81 100644 > --- a/

Re: [PATCH v9 01/10] iommu: Remove obsolete comment

2021-01-19 Thread Jonathan Cameron
On Fri, 8 Jan 2021 15:52:09 +0100 Jean-Philippe Brucker wrote: > Commit 986d5ecc5699 ("iommu: Move fwspec->iommu_priv to struct > dev_iommu") removed iommu_priv from fwspec. Update the struct doc. > > Signed-off-by: Jean-Philippe Brucker Jonathan > --- > include/linux/iommu.h | 1 - > 1

Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

2021-06-16 Thread Jonathan Cameron
etree/bindings/iio/adc/amlogic,meson-saradc.yaml | 1 - For this one, the fact it overrides maxItems elsewhere makes this a little bit odd. I guess we can get used to it being implicit. > .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml |

Re: [PATCH v2 6/9] PCI: Add pci_find_dvsec_capability to find designated VSEC

2021-10-01 Thread Jonathan Cameron
ic capabilities that aren't tied to the vendor ID of > the PCI component. > > DVSEC is critical for both the Compute Express Link (CXL) driver as well > as the driver for OpenCAPI coherent accelerator (OCXL). > > Cc: David E. Box > Cc: Jonathan Cameron > Cc: Bjorn H