RE: [PATCH 1/9] iommu/vt-d: Global PASID name space

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > > This adds the system wide PASID name space for the PASID > allocation. Currently we are using per IOMMU PASID name > spaces which are not suitable for some use cases. For an > example, one application (

RE: [PATCH 2/9] iommu/vt-d: Decouple idr bond pointer from svm

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > Subject: [PATCH 2/9] iommu/vt-d: Decouple idr bond pointer from svm > > As we move the PASID idr out of SVM code and make it serving > as a global PASID name space, the consumer can specify a ptr > to bin

RE: [PATCH 4/9] iommu/vt-d: Move device_domain_info to header

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > > This allows the per device iommu data to be accessed from other > files. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Cc: Liu Yi L > Signed-off-by: Lu Baolu Looks good to me. Reviewed-by:

RE: [PATCH 5/9] iommu/vt-d: Per domain pasid table interfaces

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > > This patch adds the interfaces for per domain pasid table > management. Currently we allocate one pasid table for all > devices under the scope of an IOMMU. It's insecure in the > cases where multiple d

RE: [PATCH 3/9] iommu/vt-d: Use global PASID for SVM usage

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > This patch switches PASID management for SVM from per iommu idr to the global > idr. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Cc: Liu Yi L > Signed-off-by: Lu Baolu > Reviewed-by: Kevin

RE: [PATCH 6/9] iommu/vt-d: Allocate and free pasid table

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > > This patch allocates PASID table for a domain at the time when > it is being created (if any devices using this domain supports > PASID feature), and free it when the domain is freed. > > Cc: Ashok Raj

RE: [PATCH 7/9] iommu/vt-d: Calculate PTS value

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > > Calculate PTS (PASID Table Size) value for the extended > context entry from the real size of the PASID table for > a domain. > > Cc: Ashok Raj > Cc: Jacob Pan > Cc: Kevin Tian > Cc: Liu Yi L > Sig

RE: [PATCH 8/9] iommu/vt-d: Use per-domain pasid table

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > > This patch replaces current per iommu pasid table with > the new added per domain pasid table. Each svm-capable > PCI device will have its own pasid table. This is not accurate. pasid table is per-iomm

RE: [PATCH 9/9] iommu/vt-d: Clean up PASID talbe management for SVM

> From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, April 17, 2018 11:03 AM > > The previous per iommu pasid table alloc/free interfaces > are no longer used. Clean up the driver by removing it. I think this patch major cleans intel_svm_alloc_pasid_tables and intel_svm_free_pasid_

Re: [PATCH v2] iommu/rockchip: make clock handling optional

Ho Joerg, Am Dienstag, 17. April 2018, 14:09:15 CEST schrieb Heiko Stuebner: > iommu clocks are optional, so the driver should not fail if they are not > present. Instead just set the number of clocks to 0, which the clk-blk APIs > can handle just fine. > > Fixes: f2e3a5f557ad ("iommu/rockchip: C

Re: [PATCH v4 2/2] drivers: remove force dma flag from buses

On Sat, Apr 28, 2018 at 08:21:59AM +0530, Nipun Gupta wrote: > With each bus implementing its own DMA configuration callback, > there is no need for bus to explicitly have force_dma in its > global structure. This patch modifies of_dma_configure API to > accept an input parameter which specifies if

Re: [PATCH v4 2/6] iommu: of: make of_pci_map_rid() available for other devices too

On Mon, Apr 30, 2018 at 11:57:17AM +0530, Nipun Gupta wrote: > iommu-map property is also used by devices with fsl-mc. This > patch moves the of_pci_map_rid to generic location, so that it > can be used by other busses too. > > 'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no > fun

[PATCH] swiotlb: Fix inversed DMA_ATTR_NO_WARN test

From: Michel Dänzer The result was printing the warning only when we were explicitly asked not to. Cc: sta...@vger.kernel.org Fixes: 0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor coherent buffer allocation" Signed-off-by: Michel Dänzer --- lib/swiotlb.c | 2 +- 1 file changed, 1

[PATCH 1/2] iommu/amd - Update the PASID information printed to the system log

Provide detailed data for each event, as appropriate. Signed-off-by: Gary R Hook --- drivers/iommu/amd_iommu.c | 31 +-- 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 8c469b51185f..a557565

[PATCH 0/2] Tweak AMD IOMMU logging

Update the AMD IOMMU log messages to be more precise, and add a log message for a new event type. --- Gary R Hook (2): iommu/amd - Update the PASID information printed to the system log iommu/amd - Update logging information for new event type drivers/iommu/amd_iommu.c | 39

[PATCH 2/2] iommu/amd - Update logging information for new event type

A new events have been defined in the AMD IOMMU spec: 0x09 - "invalid PPR request" Add support for logging this type of event. Signed-off-by: Gary R Hook ~ ~ ~ --- drivers/iommu/amd_iommu.c | 10 +- drivers/iommu/amd_iommu_types.h |1 + 2 files changed, 10 insertions(+), 1

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On Fri, 27 Apr 2018 19:07:43 +0100 Jean-Philippe Brucker wrote: > On 23/04/18 21:43, Jacob Pan wrote: > [...] > >> The last name is a bit unfortunate. Since the Arm architecture uses > >> the name "context" for what a PASID points to, "Device cache" would > >> suit us better but it's not importan

Re: [PATCHv4 1/2] iommu/vt-d: Ratelimit each dmar fault printing

Hi Joerg, is there anything I may do about those two patches? In 2/2 I've limited loop cnt as discussed in v3. This one solves softlockup for us, might be useful. On Sat, 2018-03-31 at 01:33 +0100, Dmitry Safonov wrote: > There is a ratelimit for printing, but it's incremented each time the > cpu

Re: [PATCH 5/9] iommu/vt-d: Per domain pasid table interfaces

Hi Yi, Thank you very much for reviewing my patches. On 05/01/2018 05:22 PM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Tuesday, April 17, 2018 11:03 AM >> >> This patch adds the interfaces for per domain pasid table >> management. Currently we allocate one pasi

Re: [PATCH 6/9] iommu/vt-d: Allocate and free pasid table

Hi, On 05/01/2018 05:22 PM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Tuesday, April 17, 2018 11:03 AM >> >> This patch allocates PASID table for a domain at the time when >> it is being created (if any devices using this domain supports >> PASID feature), and f

Re: [PATCH 8/9] iommu/vt-d: Use per-domain pasid table

Hi, On 05/01/2018 05:23 PM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Tuesday, April 17, 2018 11:03 AM >> >> This patch replaces current per iommu pasid table with >> the new added per domain pasid table. Each svm-capable >> PCI device will have its own pasid ta

Re: [PATCH 9/9] iommu/vt-d: Clean up PASID talbe management for SVM

Hi, On 05/01/2018 05:24 PM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Tuesday, April 17, 2018 11:03 AM >> >> The previous per iommu pasid table alloc/free interfaces >> are no longer used. Clean up the driver by removing it. > I think this patch major cleans int

Re: [PATCHv4 2/2] iommu/vt-d: Limit number of faults to clear in irq handler

Hi, On 03/31/2018 08:33 AM, Dmitry Safonov wrote: > Theoretically, on some machines faults might be generated faster than > they're cleared by CPU. Is this a real case? > Let's limit the cleaning-loop by number of hw > fault registers. Will this cause the fault recording registers full of faul