linux-toradex.git/include/linux/intel-svm.h, branch v5.1-rc1

iommu/vt-d: Support page request in scalable mode

2019-01-11T12:10:03+00:00

VT-d Rev3.0 has made a few changes to the page request interface,

1. widened PRQ descriptor from 128 bits to 256 bits;
2. removed streaming response type;
3. introduced private data that requires page response even the
   request is not last request in group (LPIG).

This is a supplement to commit 1c4f88b7f1f92 ("iommu/vt-d: Shared
virtual address in scalable mode") and makes the svm code compliant
with VT-d Rev3.0.

Cc: Ashok Raj 
Cc: Liu Yi L 
Cc: Kevin Tian 
Signed-off-by: Jacob Pan 
Fixes: 1c4f88b7f1f92 ("iommu/vt-d: Shared virtual address in scalable mode")
Signed-off-by: Lu Baolu 
Signed-off-by: Joerg Roedel

iommu/vt-d: Helper function to query if a pasid has any active users

2017-05-17T12:57:56+00:00

A driver would need to know if there are any active references to a
a PASID before cleaning up its resources. This function helps check
if there are any active users of a PASID before it can perform any
recovery on that device.

To: Joerg Roedel 
To: linux-kernel@vger.kernel.org
To: David Woodhouse 
Cc: Jean-Phillipe Brucker 
Cc: iommu@lists.linux-foundation.org

Signed-off-by: CQ Tang 
Signed-off-by: Ashok Raj 
Signed-off-by: Joerg Roedel

iommu/vt-d: Expose struct svm_dev_ops without CONFIG_INTEL_IOMMU_SVM

2015-10-26T23:36:08+00:00

The point in providing an inline version of intel_svm_bind_mm() which
just returns -ENOSYS is that people are supposed to be able to *use* it
and just see that it fails. So we need to let them have a definition of
struct svm_dev_ops (and the flags) too.

Signed-off-by: David Woodhouse

iommu/vt-d: Implement SVM_FLAG_SUPERVISOR_MODE for kernel access

2015-10-15T14:52:21+00:00

This is only usable for the static 1:1 mapping of physical memory.

Any access to vmalloc or module regions will require some way of doing
an IOTLB flush. It's theoretically possible to hook into the
tlb_flush_kernel_range() function, but that seems like overkill — most
of the addresses accessed through a kernel PASID *will* be in the 1:1
mapping.

If we really need to allow access to more interesting kernel regions,
then the answer will probably be an explicit IOTLB flush call after use,
akin to the DMA API's unmap function.

In fact, it might be worth introducing that sooner rather than later, and
making it just BUG() if the address isn't in the static 1:1 mapping.

Signed-off-by: David Woodhouse

iommu/vt-d: Implement SVM_FLAG_PRIVATE_PASID to allocate unique PASIDs

2015-10-15T14:35:32+00:00

Signed-off-by: David Woodhouse

iommu/vt-d: Add callback to device driver on page faults

2015-10-15T14:35:28+00:00

Signed-off-by: David Woodhouse

iommu/vt-d: Add basic SVM PASID support

2015-10-15T11:55:45+00:00

This provides basic PASID support for endpoint devices, tested with a
version of the i915 driver.

Signed-off-by: David Woodhouse