Re: [PATCH 1/2] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

On Fri, 17 Nov 2017 14:51:52 -0700 Alex Williamson wrote: > On Fri, 17 Nov 2017 15:11:19 -0600 > Suravee Suthikulpanit wrote: > > > From: Suravee Suthikulpanit > > > > VFIO IOMMU type1 currently upmaps

Re: [PATCH 2/2] iommu/amd: Add support for fast IOTLB flushing

On 11/17/2017 3:11 PM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit Implement the newly added IOTLB flushing interface by introducing per-protection-domain IOTLB flush list, which maintains a list of IOVAs to be invalidated (by INVALIDATE_IOTLB_PAGES

Re: [PATCH 1/2] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

On Fri, 17 Nov 2017 15:11:19 -0600 Suravee Suthikulpanit wrote: > From: Suravee Suthikulpanit > > VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which requires > IOTLB flushing for every unmapping. This results in large

[PATCH 1/2] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

From: Suravee Suthikulpanit VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which requires IOTLB flushing for every unmapping. This results in large IOTLB flushing overhead when handling pass-through devices with a large number of mapped IOVAs (e.g.

[PATCH 0/2] Reduce IOTLB flush when pass-through dGPU devices

From: Suravee Suthikulpanit Currently, when pass-through dGPU to a guest VM, there are thousands of IOTLB flush commands sent from IOMMU to end-point-device. This cause performance issue when launching new VMs, and could cause IOTLB invalidate time-out issue on

[PATCH 2/2] iommu/amd: Add support for fast IOTLB flushing

From: Suravee Suthikulpanit Implement the newly added IOTLB flushing interface by introducing per-protection-domain IOTLB flush list, which maintains a list of IOVAs to be invalidated (by INVALIDATE_IOTLB_PAGES command) during IOTLB sync. Cc: Joerg Roedel

[PATCH v3 12/16] iommu/vt-d: report unrecoverable device faults

Currently, when device DMA faults are detected by IOMMU the fault reasons are printed but the driver of the offending device is involved in fault handling. This patch uses per device fault reporting API to send fault event data for further processing. Offending device is identified by the source

[PATCH v3 14/16] 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 v3 11/16] iommu/vt-d: use threaded irq for dmar_fault

Currently, dmar fault IRQ handler does nothing more than rate limited printk, no critical hardware handling need to be done in IRQ context. Convert it to threaded IRQ would allow fault processing that requires process context. e.g. find out offending device based on source ID in the fault rasons.

[PATCH v3 08/16] 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 v3 16/16] 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 | 30 ++ 1 file

[PATCH v3 13/16] iommu/intel-svm: notify page request to guest

If the source device of a page request has its PASID table pointer bond 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 notification API to send notifications, possibly via VFIO, to the guest

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

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 v3 10/16] 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 v3 06/16] iommu/vt-d: add svm/sva invalidate function

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 structure invalidation of assigned SVM capable devices. Emulated IOMMU exposes queue invalidation capability and passes down all descriptors

[PATCH v3 15/16] iommu: introduce page response function

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 process the response which informs the device and completes the page

[PATCH v3 05/16] iommu/vt-d: support flushing more TLB types

With shared virtual memory vitualization, extended IOTLB invalidation may be passed down from outside IOMMU subsystems. This patch adds invalidation functions that can be used for each IOTLB types. Signed-off-by: Jacob Pan Signed-off-by: Liu, Yi L

[PATCH v3 07/16] iommu/vt-d: assign PFSID in device TLB invalidation

When SRIOV VF device IOTLB is invalidated, we need to provide the PF source SID 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. Signed-off-by: Jacob Pan

[PATCH v3 00/16] [PATCH v3 00/16] IOMMU driver support for SVM virtualization

Hi All, Shared virtual memory (SVM), or more precisely shared virtual address (SVA), between device DMA and applications can reduce programming complexity and enhance security. To enable SVM in the guest, i.e. shared guest application address space and physical device DMA address, IOMMU driver

[PATCH v3 02/16] 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 v3 03/16] 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 v3 01/16] 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 v3 04/16] 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

[RFC PATCH v2 5/5] ACPI/IORT: Move IORT to the ACPI folder

IORT can be used (by QEMU) to describe a virtual topology containing an architecture-agnostic paravirtualized device. The rationale behind this blasphemy is explained in patch 4/5. In order to build IORT for x86 systems, the driver has to be moved outside of arm64/. Since there is nothing

[RFC PATCH v2 4/5] ACPI/IORT: Support paravirtualized IOMMU

To describe the virtual topology in relation to a virtio-iommu device, ACPI-based systems use a "paravirtualized IOMMU" IORT node. Add support for it. This is a RFC because the IORT specification doesn't describe the paravirtualized node at the moment, it is only provided as an example in the

[RFC PATCH v2 2/5] iommu/virtio-iommu: Add probe request

When the device offers the probe feature, send a probe request for each device managed by the IOMMU. Extract RESV_MEM information. When we encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. This will tell other subsystems that there is no need to map the MSI doorbell in the

[RFC PATCH v2 3/5] iommu/virtio-iommu: Add event queue

The event queue offers a way for the device to report access faults from devices. It is implemented on virtqueue #1, whenever the host needs to signal a fault it fills one of the buffers offered by the guest and interrupts it. Signed-off-by: Jean-Philippe Brucker

[RFC PATCH v2 1/5] iommu: Add virtio-iommu driver

The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio-mmio transport without emulating page tables. This implementation handle ATTACH, DETACH, MAP and UNMAP requests. The bulk of the code is to create requests and send them through virtio.

[RFC PATCH v2 0/5] Add virtio-iommu driver

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good

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

On Fri, 17 Nov 2017 17:44:57 + Casey Leedom wrote: > | From: Raj, Ashok > | Sent: Friday, November 17, 2017 7:48 AM > | > | Reported by: Harsh > | Reviewed by: Ashok Raj > | Tested by: Jacob Pan

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

| From: Raj, Ashok | Sent: Friday, November 17, 2017 7:48 AM | | Reported by: Harsh | Reviewed by: Ashok Raj | Tested by: Jacob Pan Thanks everyone! I've updated our internal bug on this issue and noted

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

Hi Alex On Fri, Nov 17, 2017 at 09:18:14AM -0700, Alex Williamson wrote: > On Thu, 16 Nov 2017 13:09:33 -0800 > "Raj, Ashok" wrote: > > > > > > > What do we do about this? I certainly can't rip out large page support > > > and put a stable tag on the patch. I'm not

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

On Thu, 16 Nov 2017 13:09:33 -0800 "Raj, Ashok" wrote: > Hi Alex > > On Thu, Nov 16, 2017 at 02:32:44PM -0700, Alex Williamson wrote: > > On Wed, 15 Nov 2017 15:54:56 -0800 > > Jacob Pan wrote: > > > > > Hi Alex and all, > > > > > > Just

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

On 17/11/17 06:11, Bharat Kumar Gogada wrote: [...] > Thanks Jean, I see that currently vfio_group_fops_open does not allow > multiple instances. > If a device supports multiple PASID there might be different applications > running parallel. > So why is multiple instances restricted ? You