Re: [PATCH] iommu/amd: Do not disable SWIOTLB if SME is active

On 10/6/2017 4:35 PM, Tom Lendacky wrote: When SME memory encryption is active it will rely on SWIOTLB to handle DMA for devices that cannot support the addressing requirements of having the encryption mask set in the physical address. The IOMMU currently disables SWIOTLB if it is not running

[PATCH] iommu/amd: Do not disable SWIOTLB if SME is active

When SME memory encryption is active it will rely on SWIOTLB to handle DMA for devices that cannot support the addressing requirements of having the encryption mask set in the physical address. The IOMMU currently disables SWIOTLB if it is not running in passthrough mode. This is not desired as

Re: [RFCv2 PATCH 34/36] PCI: Make "PRG Response PASID Required" handling common

On Fri, Oct 06, 2017 at 02:32:01PM +0100, Jean-Philippe Brucker wrote: > The PASID ECN to the PCIe spec added a bit in the PRI status register that > allows a Function to declare whether a PRG Response should contain the > PASID prefix or not. > > Move the helper that accesses it from amd_iommu

Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data

On Fri, 6 Oct 2017 10:39:31 +0200 Joerg Roedel wrote: > On Fri, Oct 06, 2017 at 12:11:45AM -0700, Christoph Hellwig wrote: > > This is the 3rd iommu field, in addition to 8 dma-specific fields > > that we carry around for each struct device. > > Agreed, consolidating the

Re: the imfamous asix ax88179 iommu error

On 06/10/17 13:14, Robin Murphy wrote: > Hi Will, > > On 06/10/17 01:19, Will Trives wrote: >> Hello, >> >> Just reporting that it looks like this patch may fix the error (so >> people having issues with VIA controller hosts may also want to try it): >> >>

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

On Fri, Oct 06, 2017 at 04:43:09PM +0200, Joerg Roedel wrote: > On Tue, Oct 03, 2017 at 07:05:17PM +0100, Robin Murphy wrote: > > Now, there are indeed plenty of drivers and subsystems which do work on > > lists of explicitly single pages - anything doing some variant of > > "addr =

Re: Task based virtual address spaces

On Thu, Oct 05, 2017 at 11:08:12AM +0100, Jean-Philippe Brucker wrote: > Hi Jordan, > > On 04/10/17 20:43, Jordan Crouse wrote: > > Trying to start back up the conversation about multiple address > > spaces for IOMMU devices. If you will remember Jean-Philippe posted > > some patches back in

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

On Tue, Oct 03, 2017 at 07:05:17PM +0100, Robin Murphy wrote: > Now, there are indeed plenty of drivers and subsystems which do work on > lists of explicitly single pages - anything doing some variant of > "addr = kmap_atomic(sg_page(sg)) + sg->offset;" is easy to spot - but I > don't think DMA

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

Hi Shameer > -Original Message- > From: Shameerali Kolothum Thodi > Sent: 06 October 2017 15:05 > To: lorenzo.pieral...@arm.com; marc.zyng...@arm.com; > sudeep.ho...@arm.com; will.dea...@arm.com; robin.mur...@arm.com; > j...@8bytes.org; bhelg...@google.com; Gabriele Paoloni > Cc: John

[PATCH v9 3/4] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

The HiSilicon erratum 161010801 describes the limitation of HiSilicon platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions. On these platforms GICv3 ITS translator is presented with the deviceID by extending the MSI payload data to 64 bits to include the deviceID. Hence, the

[PATCH v9 1/4] ACPI/IORT: Add msi address regions reservation helper

On some platforms msi parent address regions have to be excluded from normal IOVA allocation in that they are detected and decoded in a HW specific way by system components and so they cannot be considered normal IOVA address space. Add a helper function that retrieves ITS address regions - the

[PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC deviates from the standard implementation and this breaks PCIe MSI functionality when SMMU is enabled. The HiSilicon erratum 161010801 describes this limitation of certain HiSilicon platforms to support the SMMU mappings for MSI

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

IOMMU drivers can use this to implement their .get_resv_regions callback for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region). Signed-off-by: Shameer Kolothum --- drivers/iommu/dma-iommu.c | 20 include/linux/dma-iommu.h | 7

Re: Task based virtual address spaces

On 05/10/17 11:08, Jean-Philippe Brucker wrote: > but I'll Cc you so we can work something out. D'oh! I knew I would forget some Ccs... Very sorry about that, please find the thread here: https://lists.linuxfoundation.org/pipermail/iommu/2017-October/024502.html Thanks, Jean

[RFCv2 PATCH 35/36] iommu/arm-smmu-v3: Add support for PRI

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 --- drivers/iommu/arm-smmu-v3.c | 176 ++-- 1 file changed, 122

[RFCv2 PATCH 36/36] iommu/arm-smmu-v3: Add support for PCI PASID

Enable PASID for PCI devices that support it. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 52 + 1 file changed, 52 insertions(+) diff --git a/drivers/iommu/arm-smmu-v3.c

[RFCv2 PATCH 34/36] PCI: Make "PRG Response PASID Required" handling common

The PASID ECN to the PCIe spec added a bit in the PRI status register that allows a Function to declare whether a PRG Response should contain the PASID prefix or not. Move the helper that accesses it from amd_iommu into the PCI subsystem, renaming it to be consistent with the current spec (PRPR -

[RFCv2 PATCH 32/36] iommu/arm-smmu-v3: Hook ATC invalidation to process ops

The core calls us when a process is modified. Perform the required ATC invalidations. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/arm-smmu-v3.c

[RFCv2 PATCH 33/36] iommu/arm-smmu-v3: Disable tagged pointers

The ARM architecture has a "Top Byte Ignore" (TBI) option that makes the MMU mask out bits [63:56] of an address, allowing a userspace application to store data in its pointers. This option is incompatible with PCI ATS. If TBI is enabled in the SMMU and userspace triggers DMA transactions on

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

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 --- drivers/iommu/arm-smmu-v3.c | 104 1

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

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 we invalidate the IOTLBs. Range calculation - The invalidation packet itself is a

[RFCv2 PATCH 30/36] ACPI/IORT: Check ATS capability in root complex nodes

Root complex node in IORT has a bit telling whether it supports ATS or not. Store this bit in the IOMMU fwspec when setting up a device, so it can be accessed later by an IOMMU driver. Use the negative version at the moment because it's not clear if/how the bit needs to be integrated in other

[RFCv2 PATCH 29/36] iommu/arm-smmu-v3: Add stall support for platform devices

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 transactions are parked and the OS is given a chance to fix the page tables and retry the transaction. Enable

[RFCv2 PATCH 26/36] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update

If the SMMU supports it and the kernel was built with HTTU support, enable hardware update of access and dirty flags. This is essential for shared page tables, to reduce the number of access faults on the fault queue. Signed-off-by: Jean-Philippe Brucker ---

[RFCv2 PATCH 27/36] iommu/arm-smmu-v3: Register fault workqueue

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 flush all instances of this PASID from the PRI queue. Add a way to flush the PRI and event queue. PRI and

[RFCv2 PATCH 25/36] iommu/arm-smmu-v3: Use shared ASID set

We now have two exclusive sets of ASIDs: private and shared. SMMUv3 allows for contexts to take part in distributed TLB maintenance via the ASET bit. When this bit is 0 for a given context, TLB entries tagged with its ASID are invalidated by broadcast TLB maintenance. Set ASET=0 for process

[RFCv2 PATCH 24/36] iommu/arm-smmu-v3: Steal private ASID from a domain

The SMMU only has one ASID space, so the process allocator competes with the domain allocator for ASIDs. Process ASIDs are allocated by the arch allocator and shared with CPUs, whereas domain ASIDs are private to the SMMU, and not affected by broadcast TLB invalidations. When the process

[RFCv2 PATCH 23/36] iommu/arm-smmu-v3: Share process page tables

Copy the content of TCR, MAIR and TTBR of a given task into a context descriptor. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 38 -- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git

[RFCv2 PATCH 22/36] iommu/io-pgtable-arm: Factor out ARM LPAE register defines

For SVM, we'll need to extract CPU page table information and mirror it in the substream setup. Move relevant defines to a common header. Fix TCR_SZ_MASK while we're at it. Signed-off-by: Jean-Philippe Brucker --- MAINTAINERS| 1 +

[RFCv2 PATCH 16/36] iommu/arm-smmu-v3: Add support for VHE

ARMv8.1 extensions added Virtualization Host Extensions (VHE), which allow to run a host kernel at EL2. When using normal DMA, Device and CPU address spaces are orthogonal, and do not need to implement the same capabilities, so VHE hasn't been in use on the SMMU side until now. With shared

[RFCv2 PATCH 18/36] iommu/arm-smmu-v3: Add SVM feature checking

Aggregate all sanity-checks for sharing CPU page tables with the SMMU under a single ARM_SMMU_FEAT_SVM bit. For PCIe SVM, users also need to check FEAT_ATS and FEAT_PRI. For platform SVM, they will most likely have to check FEAT_STALLS and FEAT_BTM. Signed-off-by: Jean-Philippe Brucker

[RFCv2 PATCH 21/36] iommu/arm-smmu-v3: Implement process operations

Hook process operations to support PASID and page table sharing with the SMMUv3: * process_allocate pins down its ASID and initializes the context descriptor fields. * process_free releases the ASID. * process_attach checks device capabilities and writes the context descriptor. More work is

[RFCv2 PATCH 19/36] arm64: mm: Pin down ASIDs for sharing contexts with devices

In order to enable address space sharing with the IOMMU, we introduce functions mm_context_get and mm_context_put, that pin down a context and ensure that its ASID won't be modified willy-nilly after a rollover. Pinning is necessary because, once a device is using an ASID, it needs a valid and

[RFCv2 PATCH 17/36] iommu/arm-smmu-v3: Support broadcast TLB maintenance

The SMMUv3 can handle invalidation targeted at TLB entries with shared ASIDs. If the implementation supports broadcast TLB maintenance, enable it and keep track of it in a feature bit. The SMMU will then take into account the following CPU instruction for ASIDs in the shared set: * TLBI

[RFCv2 PATCH 20/36] iommu/arm-smmu-v3: Track ASID state

At the moment each SMMU has a 8- or 16-bit ASID set and allocates one ASID per device via a bitmap. ASIDs are used to differentiate address spaces in SMMU TLB entries. With SVM, sharing process address spaces with the SMMU, we need to use CPU ASIDs in SMMU contexts, to ensure that broadcast TLB

[RFCv2 PATCH 15/36] iommu/arm-smmu-v3: Add second level of context descriptor table

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 descriptors (64kB), allocated on demand. Signed-off-by: Jean-Philippe Brucker

[RFCv2 PATCH 13/36] iommu/of: Add stall and pasid properties to iommu_fwspec

Add stall and pasid properties to iommu_fwspec, and fill them when dma-can-stall and pasid-bits properties are present in the device tree. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/of_iommu.c | 10 ++ include/linux/iommu.h| 2 ++ 2 files

[RFCv2 PATCH 07/36] iommu: Add a fault handler

Some systems allow devices to do paging. For example systems supporting PCI's PRI extension or ARM SMMU's stall model. As more IOMMU drivers are adding support for page faults, we see a number of patterns that are common to all implementations. Let's try to unify some of the generic code. Add

[RFCv2 PATCH 08/36] iommu/fault: Handle mm faults

When a recoverable page fault is handled by the fault workqueue, find the associated process and call handle_mm_fault. In theory, we don't even need to take a reference to the iommu_process, because any release of the structure is preceded by a flush of the queue. I don't feel comfortable

[RFCv2 PATCH 10/36] vfio: Add support for Shared Virtual Memory

Add two new ioctl for VFIO containers. VFIO_DEVICE_BIND_PROCESS creates a bond between a container and a process address space, identified by a device-specific ID named PASID. This allows the device to target DMA transactions at the process virtual addresses without a need for mapping and

[RFCv2 PATCH 11/36] iommu/arm-smmu-v3: Link domains and devices

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 with SVM, we'll need to invalidate context descriptors of all devices attached to a live domain. Maintain a list of devices in each

[RFCv2 PATCH 14/36] iommu/arm-smmu-v3: Add support for Substream IDs

At the moment, the SMMUv3 driver offers only one stage-1 or stage-2 address space to each device. SMMUv3 allows to associate multiple address spaces per device. In addition to the Stream ID (SID), that identifies a device, we can now have Substream IDs (SSID) identifying an address space. In PCIe

[RFCv2 PATCH 12/36] dt-bindings: document stall and PASID properties for IOMMU masters

On ARM systems, some platform devices behind an IOMMU may support stall and PASID features. Stall is the ability to recover from page faults and PASID offers multiple process address spaces to the device. Together they allow to do paging with a device. Let the firmware tell us when a device

[RFCv2 PATCH 05/36] iommu/process: Bind and unbind process to and from devices

Add bind and unbind operations to the IOMMU API. Device drivers can use them to share process page tables with their device. iommu_process_bind_group is provided for VFIO's convenience, as it needs to provide a coherent interface on containers. Device drivers will most likely want to use

[RFCv2 PATCH 03/36] iommu/process: Add public function to search for a process

The fault handler will need to find a process given its PASID. This is the reason we have an IDR for storing processes, so hook it up. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/iommu-process.c | 35 +++

[RFCv2 PATCH 09/36] iommu/fault: Allow blocking fault handlers

Allow device driver to register their fault handler at various stages of the handling path, by adding flags to iommu_set_ext_fault_handler. Since we now have a fault workqueue, it is quite easy to call their handler from thread context instead of IRQ handler. A driver can request to be called

[RFCv2 PATCH 06/36] iommu: Extend fault reporting

A number of new users will need additional information in the IOMMU fault report, such as PASID and/or PRI group. Pass a new iommu_fault structure to the driver callbacks. For the moment add the new API in parallel, with an "ext" prefix, to let users move to the new API at their pace. I think it

[RFCv2 PATCH 01/36] iommu: Keep track of processes and PASIDs

IOMMU drivers need a way to bind Linux processes to devices. This is used for Shared Virtual Memory (SVM), where devices support paging. In that mode, DMA can directly target virtual addresses of a process. Introduce boilerplate code for allocating process structures and binding them to devices.

[RFCv2 PATCH 00/36] Process management for IOMMU + SVM for SMMUv3

Following discussions at plumbers and elsewhere, it seems like we need to unify some of the Shared Virtual Memory (SVM) code, in order to define clear semantics for the SVM API. My previous RFC [1] was centered on the SMMUv3, but some of this code will need to be reused by the SMMUv2 and

[RFCv2 PATCH 04/36] iommu/process: Track process changes with an mmu_notifier

When creating an iommu_process structure, register a notifier to be informed of changes to the virtual address space and to know when the process exits. Two new operations are added to the IOMMU driver: * process_invalidate when a range of addresses is unmapped, to let the IOMMU driver send

[RFCv2 PATCH 02/36] iommu: Add a process_exit callback for device drivers

When a process exits, we need to ensure that devices attached to it stop issuing transactions with its PASID. Let device drivers register a callback to be notified on process exit. At the moment the callback is set on the domain like the fault handler, because we don't have a structure available

[PATCH] iommu/vt-d: Don't register bus-notifier under

Hey Jan, On Wed, Sep 27, 2017 at 04:19:15PM +0200, Jan Kiszka wrote: > If we could drop the dmar_global_lock around bus_register_notifier in > dmar_dev_scope_init, the issue above would likely be resolved. That is true. Can you please try this patch? >From

Re: the imfamous asix ax88179 iommu error

Hi Will, On 06/10/17 01:19, Will Trives wrote: > Hello, > > Just reporting that it looks like this patch may fix the error (so > people having issues with VIA controller hosts may also want to try it): > > https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html > > It

[PATCH 1/2] iommu/amd: Add align parameter to alloc_irq_index()

From: Joerg Roedel For multi-MSI IRQ ranges the IRQ index needs to be aligned to the power-of-two of the requested IRQ count. Extend the alloc_irq_index() function to allow such an allocation. Reported-by: Thomas Gleixner Fixes: 2b324506341cb ('iommu/amd:

[PATCH 2/2] iommu/amd: Enforce alignment for MSI IRQs

From: Joerg Roedel Make use of the new alignment capability of alloc_irq_index() to enforce IRQ index alignment for MSI. Reported-by: Thomas Gleixner Fixes: 2b324506341cb ('iommu/amd: Add routines to manage irq remapping tables') Signed-off-by: Joerg Roedel

[PATCH 0/2] iommu/amd: Correctly Align Multiple MSI IRQs

Hi, Thomas made me recently aware of the fact that the IRQ remapping code in the AMD IOMMU driver does not enforce the required alignment of IRQ indexes for multiple MSI IRQs. This patch-set adds the correct alignment for these IRQs. Regards, Joerg Joerg Roedel (2): iommu/amd: Add

RE: [PATCH v8 2/5] ACPI/IORT: Add msi address regions reservation helper

> -Original Message- > From: Marc Zyngier [mailto:marc.zyng...@arm.com] > Sent: Wednesday, October 04, 2017 3:18 PM > To: Shameerali Kolothum Thodi ; > lorenzo.pieral...@arm.com; sudeep.ho...@arm.com; will.dea...@arm.com; > robin.mur...@arm.com;

Re: [PATCH v2 10/16] iommu: introduce device fault report API

Hi Jacob, On 06/10/17 00:03, 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 faults back

Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data

On Fri, Oct 06, 2017 at 12:11:45AM -0700, Christoph Hellwig wrote: > This is the 3rd iommu field, in addition to 8 dma-specific fields > that we carry around for each struct device. Agreed, consolidating the iommu-fields in 'struct device' into a single 'struct iommu_data' is on my todo-list.

Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data

On Fri, Oct 06, 2017 at 12:11:45AM -0700, Christoph Hellwig wrote: > On Thu, Oct 05, 2017 at 04:03:37PM -0700, Jacob Pan wrote: > > 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

Re: [PATCH] iommu/arm-smmu-v3: Ensure we sync STE when only changing config field

Hi Will, On 05/10/2017 18:54, Robin Murphy wrote: > On 05/10/17 17:49, Will Deacon wrote: >> The SMMUv3 architecture permits caching of data structures deemed to be >> "reachable" by the SMU, which includes STEs marked as invalid. When >> transitioning an STE to a bypass/fault configuration at

Re: [PATCH v2 09/16] driver core: add iommu device fault reporting data

On Thu, Oct 05, 2017 at 04:03:37PM -0700, Jacob Pan wrote: > 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