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
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
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 +
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
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.
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
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
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
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
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
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
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
> -
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
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
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
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
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
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
> -
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 |
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
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 |
. 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/
/
> [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/
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
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
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
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(-)
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
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
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 --
>
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
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
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.
>
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
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
+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;
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
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
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
> > >
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
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
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
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
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
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
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
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
> >>
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
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
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
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 ++
>
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
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
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
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
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
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
>
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.
>
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
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
> >>
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
> >
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
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
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
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
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),
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
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
>
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
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 +--
>
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
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
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
>
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
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
>
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
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
>
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
>
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
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
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
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
>
+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
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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
/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
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
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 - 100 of 101 matches
Mail list logo