commit e7598fac323aad0e502415edeffd567315994dd6 upstream.
The intel_svm_is_pasid_valid() needs to be marked inline, otherwise it
causes the compile warning below:
CC [M] drivers/dma/idxd/cdev.o
In file included from drivers/dma/idxd/cdev.c:9:0:
./include/linux/intel-svm.h:125:12: warning: ‘intel_svm_is_pasid_valid’ defined but not used [-Wunused-function]
static int intel_svm_is_pasid_valid(struct device *dev, int pasid)
^~~~~~~~~~~~~~~~~~~~~~~~
Reported-by: Borislav Petkov <bp@alien8.de>
Fixes: 15060aba71 ('iommu/vt-d: Helper function to query if a pasid has any active users')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <David.Woodhouse@intel.com>
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 <David.Woodhouse@intel.com>
This provides basic PASID support for endpoint devices, tested with a
version of the i915 driver.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
