Re: [RFC PATCH] iommu/vt-d: Add IOTLB flush support for kernel addresses

[Joerg Roedel <joro@8bytes.org>]

On Tue, Oct 20, 2015 at 05:17:04PM +0100, David Woodhouse wrote:
> Can we assume that only one type of SVM-capable IOMMU will be present
> in the system at a time? Perhaps we could just register a single
> function (intel_iommu_flush_kernel_pasid in the VT-d case) to be used
> as a notifier callback from tlb_flush_kernel_range()? Rather than the
> overhead of a *list* of notifiers?

Yes, a single notifier is certainly preferable to a list. It is just
too easy for others to attach to this list silently and adding more
overhead to kernel TLB flushing.

> But... that's because the PASID-space is currently per-IOMMU. The plan
> is to have a *single* PASID-space system-wide, And then I still want to
> retain the property that there can be only *one* kernel PASID.

That makes a lot of sense. Then we can check in the call-back simply if
this pasid has users and bail out early when not.

> I have forbidden the use of a given PASID to access *both* kernel and
> user addresses. I'm hoping we can get away with putting that
> restriction into the generic SVM APIs.

We have to, having kernel-pasids already nullifies all protection the
IOMMU provides, giving kernel-access to a process-pasid is security wise
equivalent to accessing /dev/mem.

> So yeah, perhaps we can set the notifier pointer to NULL when there's
> no kernel PASID assigned, and only set it to point to
> ${MY_IOMMU}_flush_kernel_pasid() if/when there *is* one?

That sounds like it needs some clever locking. Instead of checking the
function pointer it is probably easier to put the check for pasid-users
into an inline function and just do the real flush-call only when
necessary.


	Joerg

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>