[PATCH v4 21/22] trace/iommu: add sva trace events

Signed-off-by: Jacob Pan --- include/trace/events/iommu.h | 112 +++ 1 file changed, 112 insertions(+) diff --git a/include/trace/events/iommu.h b/include/trace/events/iommu.h index 72b4582..e64eb29 100644 ---

[PATCH v4 18/22] iommu/intel-svm: replace dev ops with fault report API

With the introduction of generic IOMMU device fault reporting API, we can replace the private fault callback functions with standard function and event data. Signed-off-by: Jacob Pan --- drivers/iommu/intel-svm.c | 7 +-- include/linux/intel-svm.h | 20

[PATCH v4 15/22] iommu/config: add build dependency for dmar

Intel VT-d interrupts come from both IRQ remapping and DMA remapping. In order to report non-recoverable faults back to device driver, we need to have access to IOMMU fault reporting APIs. This patch adds build depenency to DMAR code where fault IRQ handlers can selectively report faults.

[PATCH v4 10/22] iommu: introduce device fault data

Device faults detected by IOMMU can be reported outside IOMMU subsystem for further processing. This patch intends to provide a generic device fault data such that device drivers can be communicated with IOMMU faults without model specific knowledge. The proposed format is the result of

[PATCH v4 13/22] iommu: introduce page response function

IO page faults can be handled outside IOMMU subsystem. For an example, when nested translation is turned on and guest owns the first level page tables, device page request can be forwared to the guest for handling faults. As the page response returns by the guest, IOMMU driver on the host need to

[PATCH v4 16/22] iommu/vt-d: report non-recoverable faults to device

Currently, dmar fault IRQ handler does nothing more than rate limited printk, no critical hardware handling need to be done in IRQ context. For some use case such as vIOMMU, it might be useful to report non-recoverable faults outside host IOMMU subsystem. DMAR fault can come from both DMA and

[PATCH v4 14/22] iommu: handle page response timeout

When IO page faults are reported outside IOMMU subsystem, the page request handler may fail for various reasons. E.g. a guest received page requests but did not have a chance to run for a long time. The irresponsive behavior could hold off limited resources on the pending device. There can be

[PATCH v4 17/22] iommu/intel-svm: report device page request

If the source device of a page request has its PASID table pointer bound to a guest, the first level page tables are owned by the guest. In this case, we shall let guest OS to manage page fault. This patch uses the IOMMU fault reporting API to send fault events, possibly via VFIO, to the guest

[PATCH v4 20/22] iommu/vt-d: add intel iommu page response function

This patch adds page response support for Intel VT-d. Generic response data is taken from the IOMMU API then parsed into VT-d specific response descriptor format. Signed-off-by: Jacob Pan --- drivers/iommu/intel-iommu.c | 47

[PATCH v4 09/22] iommu/vt-d: add svm/sva invalidate function

When Shared Virtual Address (SVA) is enabled for a guest OS via vIOMMU, we need to provide invalidation support at IOMMU API and driver level. This patch adds Intel VT-d specific function to implement iommu passdown invalidate API for shared virtual address. The use case is for supporting caching

[PATCH v4 19/22] iommu/intel-svm: do not flush iotlb for viommu

vIOMMU passdown invalidation will be inclusive, PASID cache invalidation includes TLBs. See Intel VT-d Specification Ch 6.5.2.2 for details. Signed-off-by: Jacob Pan --- drivers/iommu/intel-svm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v4 22/22] iommu: use sva invalidate and device fault trace event

For performance and debugging purposes, these trace events help analyzing device faults and passdown invalidations that interact with IOMMU subsystem. E.g. IOMMU::00:0a.0 type=2 reason=0 addr=0x007ff000 pasid=1 group=1 last=0 prot=1 Signed-off-by: Jacob Pan

[PATCH v4 11/22] driver core: add per device iommu param

DMA faults can be detected by IOMMU at device level. Adding a pointer to struct device allows IOMMU subsystem to report relevant faults back to the device driver for further handling. For direct assigned device (or user space drivers), guest OS holds responsibility to handle and respond per device

[PATCH v4 12/22] iommu: introduce device fault report API

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 faults back to the in-kernel device driver or the guest OS in case

[PATCH v4 07/22] iommu/vt-d: fix dev iotlb pfsid use

PFSID should be used in the invalidation descriptor for flushing device IOTLBs on SRIOV VFs. Signed-off-by: Jacob Pan --- drivers/iommu/dmar.c| 6 +++--- drivers/iommu/intel-iommu.c | 16 +++- include/linux/intel-iommu.h | 5 ++--- 3 files

[PATCH v4 08/22] iommu/vt-d: support flushing more translation cache types

When Shared Virtual Memory is exposed to a guest via vIOMMU, extended IOTLB invalidation may be passed down from outside IOMMU subsystems. This patch adds invalidation functions that can be used for additional translation cache types. Signed-off-by: Jacob Pan ---

[PATCH v4 02/22] iommu/vt-d: move device_domain_info to header

Allow both intel-iommu.c and dmar.c to access device_domain_info. Prepare for additional per device arch data used in TLB flush function Signed-off-by: Jacob Pan --- drivers/iommu/intel-iommu.c | 18 -- include/linux/intel-iommu.h | 19

[PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

Add Intel VT-d ops to the generic iommu_bind_pasid_table API functions. The primary use case is for direct assignment of SVM capable device. Originated from emulated IOMMU in the guest, the request goes through many layers (e.g. VFIO). Upon calling host IOMMU driver, caller passes guest PASID

[PATCH v4 06/22] iommu/vt-d: add definitions for PFSID

When SRIOV VF device IOTLB is invalidated, we need to provide the PF source ID such that IOMMU hardware can gauge the depth of invalidation queue which is shared among VFs. This is needed when device invalidation throttle (DIT) capability is supported. This patch adds bit definitions for checking

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

From: "Liu, Yi L" When an SVM capable device is assigned to a guest, the first level page tables are owned by the guest and the guest PASID table pointer is linked to the device context entry of the physical IOMMU. Host IOMMU driver has no knowledge of caching

[PATCH v4 00/22] IOMMU and VT-d driver support for Shared Virtual Address (SVA)

Hi All, Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel platforms allow address space sharing between device DMA and applications. SVA can reduce programming complexity and enhance security. To enable SVA in the guest, i.e. shared guest application address space and

[PATCH v4 01/22] iommu: introduce bind_pasid_table API function

Virtual IOMMU was proposed to support Shared Virtual Memory (SVM) use in the guest: https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg05311.html As part of the proposed architecture, when an SVM capable PCI device is assigned to a guest, nested mode is turned on. Guest owns the first level

[PATCH v4 03/22] iommu/vt-d: add a flag for pasid table bound status

Adding a flag in device domain into to track whether a guest or user PASID table is bound to a device. Signed-off-by: Jacob Pan --- include/linux/intel-iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/intel-iommu.h

Re: [PATCH v5 7/7] iommu/dma: Move PCI window region reservation back into dma specific path.

On 22/03/18 16:21, Alex Williamson wrote: On Thu, 15 Mar 2018 16:35:09 + Shameer Kolothum wrote: This pretty much reverts commit 273df9635385 ("iommu/dma: Make PCI window reservation generic") by moving the PCI window region reservation back into the

Re: [PATCH v5 7/7] iommu/dma: Move PCI window region reservation back into dma specific path.

On Thu, 15 Mar 2018 16:35:09 + Shameer Kolothum wrote: > This pretty much reverts commit 273df9635385 ("iommu/dma: Make PCI > window reservation generic") by moving the PCI window region > reservation back into the dma specific path so that these

[PATCH 08/10] iommu/amd: drop the lock while allocating new irq remap table

The irq_remap_table is allocated while the iommu_table_lock is held with interrupts disabled. >From looking at the call sites, all callers are in the early device initialisation (apic_bsp_setup(), pci_enable_device(), pci_enable_msi()) so make sense to drop the lock which also enables interrupts

[PATCH 05/10] iommu/amd: remove the special case from alloc_irq_table()

alloc_irq_table() has a special ioapic argument. If set then it will pre-allocate / reserve the first 32 indexes. The argument is only once true and it would make alloc_irq_table() a little simpler if we would extract the special bits to the caller. The caller of irq_remapping_alloc() is holding

[PATCH 09/10] iommu/amd: make amd_iommu_devtable_lock a spin_lock

Before commit 0bb6e243d7fb ("iommu/amd: Support IOMMU_DOMAIN_DMA type allocation") amd_iommu_devtable_lock had a read_lock() user but now there are none. In fact, after the mentioned commit we had only write_lock() user of the lock. Since there is no reason to keep it as writer lock, change its

[PATCH 07/10] iommu/amd: factor out setting the remap table for a devid

Setting the IRQ remap table for a specific devid (or its alias devid) includes three steps. Those three steps are always repeated each time this is done. Introduce a new helper function, move those steps there and use that function instead. The compiler can still decide if it is worth to inline.

[PATCH 10/10] iommu/amd: return proper error code in irq_remapping_alloc()

In the unlikely case when alloc_irq_table() is not able to return a remap table then "ret" will be assigned with an error code. Later, the code checks `index' and if it is negative (which it is because it is initialized with `-1') and then then function properly aborts but returns `-1' instead

[PATCH 06/10] iommu/amd: use `table' instead `irt' as variable name in amd_iommu_update_ga()

The variable of type struct irq_remap_table is always named `table' except in amd_iommu_update_ga() where it is called `irt'. Make it consistent and name it also `table'. Signed-off-by: Sebastian Andrzej Siewior --- drivers/iommu/amd_iommu.c | 10 +- 1 file

[PATCH 04/10] iommu/amd: split irq_lookup_table out of the amd_iommu_devtable_lock

The function get_irq_table() reads/writes irq_lookup_table while holding the amd_iommu_devtable_lock. It also modifies amd_iommu_dev_table[].data[2]. set_dte_entry() is using amd_iommu_dev_table[].data[0|1] (under the domain->lock) so it should be okay. The access to the iommu is serialized with

[PATCH 03/10] iommu/amd: split domain id out of amd_iommu_devtable_lock

domain_id_alloc() and domain_id_free() is used for id management. Those two function share a bitmap (amd_iommu_pd_alloc_bitmap) and set/clear bits based on id allocation. There is no need to share this with amd_iommu_devtable_lock, it can use its own lock for this operation. Signed-off-by:

[PATCH 02/10] iommu/amd: turn dev_data_list into a lock less list

alloc_dev_data() adds new items to dev_data_list and search_dev_data() is searching for items in this list. Both protect the access to the list with a spinlock. There is no need to navigate forth and back within the list and there is also no deleting of a specific item. This qualifies the list to

[PATCH 01/10] iommu/amd: take into account that alloc_dev_data() may return NULL

find_dev_data() does not check whether the return value alloc_dev_data() is NULL. This was okay once because the pointer was returned once as-is. Since commit df3f7a6e8e85 ("iommu/amd: Use is_attach_deferred call-back") the pointer may be used within find_dev_data() so a NULL check is required.

[PATCH 00/10 v3] iommu/amd: lock splitting & GFP_KERNEL allocation

Hi, this is the rebase on top of iommu/x86/amd of my last series. It takes Scotts comments into consideration from my v2. It contains lock splitting and GFP_KERNEL allocation of remap-table. Mostly cleanup. The patches were boot tested on an AMD EPYC 7601. Sebastian

RE: [PATCH v2 2/2] drivers: remove force dma flag from buses

> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Thursday, March 22, 2018 13:49 > To: Nipun Gupta > > > --- a/drivers/dma/qcom/hidma_mgmt.c > > +++ b/drivers/dma/qcom/hidma_mgmt.c > > @@ -398,7 +398,7 @@ static int __init >

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Thursday, March 22, 2018 13:46 > To: Nipun Gupta > > > +static int amba_dma_configure(struct device *dev) > > +{ > > + return dma_common_configure(dev); > > +} > > So it turns out we

[PATCH] iommu/vt-d, trivial: Remove unused variable

Unused after commit <42e8c186b595> ("iommu/vt-d: Simplify io/tlb flushing in intel_iommu_unmap"), cleanup it. Cc: David Woodhouse Cc: Joerg Roedel Signed-off-by: Shaokun Zhang --- drivers/iommu/intel-iommu.c | 6 +- 1 file

[PATCH v11 0/4] iommu/arm-smmu: Add runtime pm/sleep support

This series provides the support for turning on the arm-smmu's clocks/power domains using runtime pm. This is done using the recently introduced device links patches, which lets the smmu's runtime to follow the master's runtime pm, so the smmu remains powered only when the masters use it. As not

[PATCH v11 1/4] iommu/arm-smmu: Add pm_runtime/sleep ops

From: Sricharan R The smmu needs to be functional only when the respective master's using it are active. The device_link feature helps to track such functional dependencies, so that the iommu gets powered when the master device enables itself using pm_runtime. So by

[PATCH v11 3/4] iommu/arm-smmu: Add the device_link between masters and smmu

From: Sricharan R Finally add the device link between the master device and smmu, so that the smmu gets runtime enabled/disabled only when the master needs it. This is done from add_device callback which gets called once when the master is added to the smmu.

[PATCH v11 4/4] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. This smmu core is used with multiple masters on msm8996, viz. mdss, video, etc. Add bindings for the same. Signed-off-by: Vivek Gautam Reviewed-by: Rob Herring

[PATCH v11 2/4] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

From: Sricharan R The smmu device probe/remove and add/remove master device callbacks gets called when the smmu is not linked to its master, that is without the context of the master device. So calling runtime apis in those places separately. Signed-off-by: Sricharan R

RE: [PATCH 1/4] iommu: Add virtio-iommu driver

> From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Wednesday, March 21, 2018 10:24 PM > > On 21/03/18 13:14, Jean-Philippe Brucker wrote: > > On 21/03/18 06:43, Tian, Kevin wrote: > > [...] > >>> + > >>> +#include > >>> + > >>> +#define MSI_IOVA_BASE0x800 > >>>

RE: [PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Wednesday, March 21, 2018 4:31 PM > To: Tian, Kevin > Cc: Shameerali Kolothum Thodi ; > eric.au...@redhat.com; pmo...@linux.vnet.ibm.com;

RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list management

> From: Alex Williamson > Sent: Thursday, March 22, 2018 1:11 AM > > On Wed, 21 Mar 2018 03:28:16 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, March 21, 2018 6:55 AM > > > > > > On Mon, 19 Mar 2018

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

> --- a/drivers/dma/qcom/hidma_mgmt.c > +++ b/drivers/dma/qcom/hidma_mgmt.c > @@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct > device_node *np) > } > of_node_get(child); > new_pdev->dev.of_node = child; > -

Re: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

> > +int dma_configure(struct device *dev) > > +{ > > + if (dev->bus->dma_configure) > > + return dev->bus->dma_configure(dev); > > What if dma_common_configure() is called in case "bus->dma_configure" is not > defined? Then we'd still have a dependency of common code on OF and

Re: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

> +static int amba_dma_configure(struct device *dev) > +{ > + return dma_common_configure(dev); > +} So it turns out we only end with two callers of dma_common_configure after this series. Based ont hat I'm tempted with the suggestion from Robin to just have amba call platform_dma_configure,