[RFC PATCH 10/10] vfio/type1: Allocate domain for mediated device

This allocates a domain for the mediated device if it is able to be isolated and protected individually by IOMMU. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Cc: Liu Yi L Signed-off-by: Sanjay Kumar Signed-off-by: Lu Baolu --- drivers/vfio/vfio_iommu_type1.c | 43

[RFC PATCH 09/10] vfio/mdev: Add mediated device domain type

A parent device might create different types of mediated devices. For example, a mediated device could be created on the parent device with a PASID tagged. When the iommu supports PASID-granular translations, the mediated device is individually protected and isolated by the iommu. It's hence possib

[RFC PATCH 08/10] vfio/mdev: Set iommu ops for mdev bus

This sets the iommu ops for the mdev bus with iommu_set_bus(). With the iommu ops setting, a mediated device might be isolated and protected by an IOMMU unit. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Cc: Liu Yi L Signed-off-by: Sanjay Kumar Signed-off-by: Lu Baolu --- drivers/vfio/mdev/md

[RFC PATCH 07/10] iommu/vt-d: Add set_bus iommu ops

This specifies the Intel IOMMU specific set_bus operation. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Cc: Liu Yi L Signed-off-by: Sanjay Kumar Signed-off-by: Lu Baolu --- drivers/iommu/intel-iommu.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/iommu/intel-

[RFC PATCH 06/10] iommu: Add iommu_set_bus API interface

This adds iommu_set_bus API by adding a new set_bus ops in the iommu_ops structure. A vendor IOMMU driver could either specify its callback or safely ignore it. This interface could be used to set the iommu methods used for a particular non-pci bus. One consumer of this interface could be vfio/mdev

[RFC PATCH 05/10] iommu/vt-d: Setup DMA remapping for mediated devices

This configures the second level page table when external components request to allocate a domain for a mediated device. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Cc: Liu Yi L Signed-off-by: Sanjay Kumar Signed-off-by: Lu Baolu --- drivers/iommu/intel-iommu.c | 73 +

[RFC PATCH 04/10] iommu/vt-d: Get pasid table for a mediated device

This patch adds the support to get the pasid table for a mediated device. The assumption is that each mediated device is a minimal assignable set of a physical PCI device. Hence, we should use the pasid table of the parent PCI device to manage the translation. Cc: Ashok Raj Cc: Jacob Pan Cc: Kev

[RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices

With the Intel IOMMU supporting PASID granularity isolation and protection, a mediated device could be isolated and protected by an IOMMU unit. We need to allocate a new group instead of a PCI group. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Cc: Liu Yi L Signed-off-by: Sanjay Kumar Signed-of

[RFC PATCH 02/10] iommu/vt-d: Alloc domain for a mediated device

The PASID-granular 2nd level address translation makes it possible to isolate and protect a mediated device exposed by a real device which support PCI PASID features. This patch adds support to allocate a domain for a mediated device. A default pasid value will be allocated as well for the mediated

[RFC PATCH 01/10] iommu/vt-d: Get iommu device for a mediated device

This patch adds the support to get the iommu device for a mediated device. The assumption is that each mediated device is a minimal assignable set of a physical PCI device. Hence, we should use the iommu device of the parent PCI device to manage the translation. Cc: Ashok Raj Cc: Jacob Pan Cc: K

[RFC PATCH 00/10] vfio/mdev: IOMMU aware mediated device

Hi, The Mediate Device is a framework for fine-grained physical device sharing across the isolated domains. Currently the mdev framework is designed to be independent of the platform IOMMU support. As the result, the DMA isolation relies on the mdev parent device in a vendor specific way. There a

Re: use the generic dma-noncoherent code for openrisc

On Thu, Jul 19, 2018 at 06:02:28AM -0700, Christoph Hellwig wrote: > Hi Openrisc maintainers, > > can you review these patches to switch openrisc to use the generic > dma-noncoherent code? All the requirements are in mainline already > and we've switched various architectures over to it already.

Re: use the generic dma-noncoherent code for openrisc

On Sat, Jul 21, 2018 at 02:31:42PM +0900, Stafford Horne wrote: > For upstreaming, do you want me to send these through the openrisc tree, or do > you want to send with the dma tree? Feel free to merge them through the openrisc tree. ___ iommu mailing li

Re: usb HC busted?

Hi Mathias, On Fri, Jul 20, 2018 at 01:54:21PM +0100, Sudip Mukherjee wrote: > Hi Mathias, > > On Fri, Jul 20, 2018 at 02:10:58PM +0300, Mathias Nyman wrote: > > On 19.07.2018 20:32, Sudip Mukherjee wrote: > > > Hi Mathias, > > > > > > On Thu, Jul 19, 2018 at 06:42:19PM +0300, Mathias Nyman wrot

Re: [PATCH] iommu/ipmmu-vmsa: Fix allocation in atomic context

Hi Geert, Thank you for the patch. On Friday, 20 July 2018 19:16:59 EEST Geert Uytterhoeven wrote: > When attaching a device to an IOMMU group with > CONFIG_DEBUG_ATOMIC_SLEEP=y: > > BUG: sleeping function called from invalid context at mm/slab.h:421 > in_atomic(): 1, irqs_disabled(): 12