linux-toradex.git/drivers/iommu/intel-svm.c, branch v4.4.3

iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts

2016-02-25T20:01:22+00:00

commit 46924008273ed03bd11dbb32136e3da4cfe056e1 upstream.

According to the VT-d specification we need to clear the PPR bit in
the Page Request Status register when handling page requests, or the
hardware won't generate any more interrupts.

This wasn't actually necessary on SKL/KBL (which may well be the
subject of a hardware erratum, although it's harmless enough). But
other implementations do appear to get it right, and we only ever get
one interrupt unless we clear the PPR bit.

Reported-by: CQ Tang 
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users

2016-02-25T20:01:21+00:00

commit e57e58bd390a6843db58560bf7b8341665d2e058 upstream.

Holding mm_users works OK for graphics, which was the first user of SVM
with VT-d. However, it works less well for other devices, where we actually
do a mmap() from the file descriptor to which the SVM PASID state is tied.

In this case on process exit we end up with a recursive reference count:
 - The MM remains alive until the file is closed and the driver's release()
   call ends up unbinding the PASID.
 - The VMA corresponding to the mmap() remains intact until the MM is
   destroyed.
 - Thus the file isn't closed, even when exit_files() runs, because the
   VMA is still holding a reference to it. And the MM remains alive…

To address this issue, we *stop* holding mm_users while the PASID is bound.
We already hold mm_count by virtue of the MMU notifier, and that can be
made to be sufficient.

It means that for a period during process exit, the fun part of mmput()
has happened and exit_mmap() has been called so the MM is basically
defunct. But the PGD still exists and the PASID is still bound to it.

During this period, we have to be very careful — exit_mmap() doesn't use
mm->mmap_sem because it doesn't expect anyone else to be touching the MM
(quite reasonably, since mm_users is zero). So we also need to fix the
fault handler to just report failure if mm_users is already zero, and to
temporarily bump mm_users while handling any faults.

Additionally, exit_mmap() calls mmu_notifier_release() *before* it tears
down the page tables, which is too early for us to flush the IOTLB for
this PASID. And __mmu_notifier_release() removes every notifier from the
list, so when exit_mmap() finally *does* tear down the mappings and
clear the page tables, we don't get notified. So we work around this by
clearing the PASID table entry in our MMU notifier release() callback.
That way, the hardware *can't* get any pages back from the page tables
before they get cleared.

Hardware designers have confirmed that the resulting 'PASID not present'
faults should be handled just as gracefully as 'page not present' faults,
the important criterion being that they don't perturb the operation for
any *other* PASID in the system.

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Do access checks before calling handle_mm_fault()

2015-12-14T14:37:55+00:00

Not doing so is a bug and might trigger a BUG_ON in
handle_mm_fault(). So add the proper permission checks
before calling into mm code.

Reviewed-by: Jesse Barnes 
Acked-By: David Woodhouse 
Signed-off-by: Joerg Roedel

iommu/vt-d: Fix rwxp flags in SVM device fault callback

2015-10-28T06:14:09+00:00

This is the downside of using bitfields in the struct definition, rather
than doing all the explicit masking and shifting.

Signed-off-by: David Woodhouse

iommu/vt-d: Handle Caching Mode implementations of SVM

2015-10-24T19:06:39+00:00

Not entirely clear why, but it seems we need to reserve PASID zero and
flush it when we make a PASID entry present.

Quite we we couldn't use the true PASID value, isn't clear.

Signed-off-by: David Woodhouse

iommu/vt-d: Fix SVM IOTLB flush handling

2015-10-20T15:26:21+00:00

Change the 'pages' parameter to 'unsigned long' to avoid overflow.

Fix the device-IOTLB flush parameter calculation — the size of the IOTLB
flush is indicated by the position of the least significant zero bit in
the address field. For example, a value of 0x12345f000 will flush from
0x123440000 to 0x12347ffff (256KiB).

Finally, the cap_pgsel_inv() is not relevant to SVM; the spec says that
*all* implementations must support page-selective invaliation for
"first-level" translations. So don't check for it.

Signed-off-by: David Woodhouse

iommu/vt-d: fix a loop in prq_event_thread()

2015-10-18T14:26:04+00:00

There is an extra semi-colon on this if statement so we always break on
the first iteration.

Fixes: 0204a4960982 ('iommu/vt-d: Add callback to device driver on page faults')
Signed-off-by: Dan Carpenter 
Signed-off-by: David Woodhouse

iommu/vt-d: Fix IOTLB flushing for global pages

2015-10-16T18:37:04+00:00

When flushing kernel-mode PASIDs, we need to flush global pages too.

Signed-off-by: David Woodhouse

iommu/vt-d: Fix address shifting in page request handler

2015-10-16T16:22:34+00:00

This really should be VTD_PAGE_SHIFT, not PAGE_SHIFT. Not that we ever
really anticipate seeing this used on IA64, but we should get it right
anyway.

Signed-off-by: David Woodhouse

iommu/vt-d: shift wrapping bug in prq_event_thread()

2015-10-15T20:16:47+00:00

The "req->addr" variable is a bit field declared as "u64 addr:52;".
The "address" variable is a u64.  We need to cast "req->addr" to a u64
before the shift or the result is truncated to 52 bits.

Fixes: a222a7f0bb6c ('iommu/vt-d: Implement page request handling')
Signed-off-by: Dan Carpenter 
Signed-off-by: David Woodhouse