Re: [PATCH v8 6/8] perf tool: Add support for parsing HiSilicon PCIe Trace packet

On Mon, 16 May 2022 20:52:21 +0800 Yicong Yang wrote: > From: Qi Liu > > Add support for using 'perf report --dump-raw-trace' to parse PTT packet. > > Example usage: > > Output will contain raw PTT data and its textual representation, such > as: > > 0 0 0x5810 [0x30]: PERF_RECORD_AUXTRACE

Re: [PATCH v8 5/8] perf tool: Add support for HiSilicon PCIe Tune and Trace device driver

On Mon, 16 May 2022 20:52:20 +0800 Yicong Yang wrote: > From: Qi Liu > > HiSilicon PCIe tune and trace device (PTT) could dynamically tune > the PCIe link's events, and trace the TLP headers). > > This patch add support for PTT device in perf tool, so users could > use 'perf record' to get

Re: [PATCH v8 4/8] perf arm: Refactor event list iteration in auxtrace_record__init()

in subsequent patches." > > Signed-off-by: Qi Liu > Signed-off-by: Yicong Yang FWIW as this isn't an area I know much about. It seems like a good cleanup and functionally equivalent. Reviewed-by: Jonathan Cameron > --- > tools/perf/arch/arm/util/auxtrace.c | 53 +

Re: [PATCH v8 2/8] hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device

It's been a while since I looked at this driver, so I'll admit I can't remember if any of the things I've raised below were previously discussed. All minor stuff (biggest is question of failing cleanly in unlikely case of failing the allocation in the filter addition vs carrying on anyway), so feel

Re: [PATCH v5 3/8] hisi_ptt: Register PMU device for PTT trace

On Tue, 8 Mar 2022 19:13:08 +0800 Yicong Yang wrote: > On 2022/3/8 18:21, Jonathan Cameron wrote: > > On Tue, 8 Mar 2022 16:49:25 +0800 > > Yicong Yang wrote: > > > >> Register PMU device of PTT trace, then users can use trace through perf > >> command.

Re: [PATCH v5 8/8] MAINTAINERS: Add maintainer for HiSilicon PTT driver

On Tue, 8 Mar 2022 16:49:30 +0800 Yicong Yang wrote: > Add maintainer for driver and documentation of HiSilicon PTT device. > > Signed-off-by: Yicong Yang FWIW Reviewed-by: Jonathan Cameron I've left the perf tool and iommu patches without tags from me as I don't have the backgro

Re: [PATCH v5 4/8] hisi_ptt: Add support for dynamically updating the filter list

s get latest information about available tracing filters and > driver can block the invalid filters of which related devices no longer > exist in the system. > > Signed-off-by: Yicong Yang You've made the change I requested in v4 so Reviewed-by: Jonathan Cameron > --- > dr

Re: [PATCH v5 3/8] hisi_ptt: Register PMU device for PTT trace

following patch. > > Signed-off-by: Yicong Yang It seems to me that you ended up doing both suggestions for how to clean up the remove order when it was meant to be a question of picking one or the other. Otherwise this looks good to me - so with that tidied up Reviewed-by: Jona

Re: [PATCH v4 2/8] hwtracing: Add trace function support for HiSilicon PCIe Tune and Trace device

On Mon, 21 Feb 2022 21:13:45 +0800 Yicong Yang wrote: > Hi Jonathan, > > On 2022/2/21 19:18, Jonathan Cameron wrote: > > On Mon, 21 Feb 2022 16:43:01 +0800 > > Yicong Yang wrote: > > > >> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex &g

Re: [PATCH v4 7/8] docs: Add HiSilicon PTT device driver documentation

On Mon, 21 Feb 2022 16:43:06 +0800 Yicong Yang wrote: > Document the introduction and usage of HiSilicon PTT device driver. > > Signed-off-by: Yicong Yang Reviewed-by: Jonathan Cameron > --- > Documentation/trace/hisi-ptt.rst | 303 +++ > 1

Re: [PATCH v4 4/8] hisi_ptt: Add support for dynamically updating the filter list

On Mon, 21 Feb 2022 16:43:03 +0800 Yicong Yang wrote: > The PCIe devices supported by the PTT trace can be removed/rescanned > by hotplug or through sysfs. Add support for dynamically updating > the available filter list by registering a PCI bus notifier block. > Then user can always get latest

Re: [PATCH v4 3/8] hisi_ptt: Register PMU device for PTT trace

On Mon, 21 Feb 2022 16:43:02 +0800 Yicong Yang wrote: > Register PMU device of PTT trace, then users can use > trace through perf command. The driver makes use of perf > AUX trace and support following events to configure the > trace: > > - filter: select Root port or Endpoint to trace > -

Re: [PATCH v4 2/8] hwtracing: Add trace function support for HiSilicon PCIe Tune and Trace device

On Mon, 21 Feb 2022 16:43:01 +0800 Yicong Yang wrote: > HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex > integrated Endpoint(RCiEP) device, providing the capability > to dynamically monitor and tune the PCIe traffic, and trace > the TLP headers. > > Add the driver for the

Re: [PATCH v3 6/8] docs: Add HiSilicon PTT device driver documentation

On Mon, 24 Jan 2022 21:11:16 +0800 Yicong Yang wrote: > Document the introduction and usage of HiSilicon PTT device driver. > > Signed-off-by: Yicong Yang Nice document. A few trivial typos inline. I would give a RB except I've suggested you change a part of the sysfs interface which will

Re: [PATCH v3 5/8] perf tool: Add support for HiSilicon PCIe Tune and Trace device driver

On Mon, 24 Jan 2022 21:11:15 +0800 Yicong Yang wrote: > From: Qi Liu > > 'perf record' and 'perf report --dump-raw-trace' supported in this > patch. > > Example usage: > > Output will contain raw PTT data and its textual representation, such > as: > > 0 0 0x5810 [0x30]: PERF_RECORD_AUXTRACE

Re: [PATCH v3 4/8] hisi_ptt: Add tune function support for HiSilicon PCIe Tune and Trace device

eneral to me. With those tidied up Reviewed-by: Jonathan Cameron > --- > drivers/hwtracing/ptt/hisi_ptt.c | 154 +++ > drivers/hwtracing/ptt/hisi_ptt.h | 19 > 2 files changed, 173 insertions(+) > > diff --git a/drivers/hwtracing/ptt/hisi_pt

Re: [PATCH v3 1/8] hwtracing: Add trace function support for HiSilicon PCIe Tune and Trace device

On Mon, 24 Jan 2022 21:11:11 +0800 Yicong Yang wrote: > HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex > integrated Endpoint(RCiEP) device, providing the capability > to dynamically monitor and tune the PCIe traffic, and trace > the TLP headers. > > Add the driver for the

Re: [PATCH v3 2/8] hisi_ptt: Register PMU device for PTT trace

On Mon, 24 Jan 2022 21:11:12 +0800 Yicong Yang wrote: > Register PMU device of PTT trace, then users can use > trace through perf command. The driver makes use of perf > AUX trace and support following events to configure the > trace: > > - filter: select Root port or Endpoint to trace > -

Re: [patch 08/37] genirq/msi: Provide msi_device_populate/destroy_sysfs()

On Sat, 27 Nov 2021 02:20:19 +0100 (CET) Thomas Gleixner wrote: > Add new allocation functions which can be activated by domain info > flags. They store the groups pointer in struct msi_device_data. > > Signed-off-by: Thomas Gleixner A few trivial comments... > --- > include/linux/msi.h |

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

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

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

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 v11 10/10] iommu/arm-smmu-v3: Add stall support for platform devices

. 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 0/3] iommu/arm-smmu-v3: TLB invalidation for SVA

/ > [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 10/10] iommu/arm-smmu-v3: Add stall support for platform devices

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 v10 10/10] iommu/arm-smmu-v3: Add stall support for platform devices

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 v10 09/10] ACPI/IORT: Enable stall support for platform devices

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 v9 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure

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 v9 06/10] iommu: Add a page fault handler

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 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF

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 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits

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 v9 01/10] iommu: Remove obsolete comment

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 v3 14/14] iommu/amd: Adopt IO page table framework

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 00/13] iommu: Shared Virtual Addressing for SMMUv3 (PT sharing part)

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 v10 09/13] iommu/arm-smmu-v3: Seize private ASID

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 04/15] arm64: numa: simplify dummy_numa_init()

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] iommu/arm-smmu-v3: expose numa_node attribute to users in sysfs

+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

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 v2] of_device: removed #include that caused a recursion in included headers

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 v4 23/26] iommu/arm-smmu-v3: Add stall support for platform devices

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 v4 02/26] iommu/sva: Manage process address spaces

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 00/26] iommu: Shared Virtual Addressing and SMMUv3 support

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 v4 23/26] iommu/arm-smmu-v3: Add stall support for platform devices

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 07/26] arm64: mm: Pin down ASIDs for sharing mm with devices

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 03/26] iommu: Add a page fault handler

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

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 v10 2/4] uacce: add uacce driver

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

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 v10 0/4] Add uacce module for Accelerator

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

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 3/4] crypto: hisilicon - Remove module_param uacce_mode

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 2/4] uacce: add uacce driver

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 v3 00/13] iommu: Add PASID support to Arm SMMUv3

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 10/13] iommu/arm-smmu-v3: Add second level of context descriptor table

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 v3 01/13] iommu/arm-smmu-v3: Drop __GFP_ZERO flag from DMA allocation

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 v2 8/8] iommu/arm-smmu-v3: Add support for PCI PASID

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 7/8] iommu/arm-smmu-v3: Improve add_device() error handling

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 6/8] iommu/arm-smmu-v3: Add second level of context descriptor table

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

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 v2 4/8] iommu/arm-smmu-v3: Prepare for SSID support

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 v7 3/3] crypto: hisilicon - register zip engine to uacce

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

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 v7 1/3] uacce: Add documents for uacce

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 2/3] uacce: add uacce driver

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 3/3] crypto: hisilicon - register zip engine to uacce

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 v4 03/22] iommu: Introduce device fault report API

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 v4 12/22] iommu: Add I/O ASID allocator

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 20/22] iommu/vt-d: Add bind guest PASID support

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 19/22] iommu/vt-d: Clean up for SVM device list

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 17/22] iommu/vt-d: Avoid duplicated code for PASID setup

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 15/22] iommu/vt-d: Replace Intel specific PASID allocator with IOASID

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 04/22] iommu: Add recoverable fault reporting

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 02/22] iommu: Introduce device fault data

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

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 09/22] iommu: Introduce cache_invalidate API

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 10/22] iommu: Fix compile error without IOMMU_API

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 8/8] iommu/arm-smmu-v3: Add support for PCI PASID

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

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 4/8] iommu/arm-smmu-v3: Add support for Substream IDs

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 3/8] iommu/arm-smmu-v3: Support platform SSID

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 v5 4/8] iommu/vt-d: Aux-domain specific domain attach/detach

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()

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

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 v2 03/40] iommu/sva: Manage process address spaces

+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: [PATCH v2 05/40] iommu/sva: Track mm changes with an MMU notifier

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 03/40] iommu/sva: Manage process address spaces

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

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

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 13/40] vfio: Add support for Shared Virtual Addressing

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 07/40] iommu: Add a page fault handler

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 08/21] iio: adc: Remove depends on HAS_DMA in case of platform dependency

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 17/37] iommu/arm-smmu-v3: Move context descriptor code

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 27/37] iommu/arm-smmu-v3: Register fault workqueue

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 28/37] iommu/arm-smmu-v3: Maintain a SID->device structure

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 31/37] iommu/arm-smmu-v3: Add support for PCI ATS

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 35/37] iommu/arm-smmu-v3: Add support for PRI

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

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: Preferred method to detect if a device is behind an enabled iommu.

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.

/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 2/2] iommu/arm-smmu: Add system PM support

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

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: > > > &

  1   2   >