linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Joerg Roedel <joro@8bytes.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	iommu@lists.linux-foundation.org,
	Sudeep Dutt <sudeep.dutt@intel.com>
Subject: Re: [RFC PATCH] iommu/vt-d: Add IOTLB flush support for kernel addresses
Date: Tue, 20 Oct 2015 17:17:04 +0100	[thread overview]
Message-ID: <1445357824.4486.65.camel@infradead.org> (raw)
In-Reply-To: <20151020160328.GV27420@8bytes.org>

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

On Tue, 2015-10-20 at 18:03 +0200, Joerg Roedel wrote:
> Hi David,
> 
> On Tue, Oct 20, 2015 at 04:52:59PM +0100, David Woodhouse wrote:
> >  void flush_tlb_kernel_range(unsigned long start, unsigned long end)
> >  {
> > +> > 	> > intel_iommu_flush_kernel_pasid(start, end);
> 
> A more generic naming would be good, and probably expose it through a
> function in the IOMMU-API.

Yeah. *All* the SVM functionality needs to be exposed through the DMA
API (for native drivers like i915) and the IOMMU API (so VM guests can
see an IOMMU and do SVM on assigned devices).

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?

> > +void intel_iommu_flush_kernel_pasid(unsigned long start, unsigned long end)
> > +{
> > +> > 	> > struct dmar_drhd_unit *drhd;
> > +> > 	> > struct intel_iommu *iommu;
> > +> > 	> > unsigned long pages;
> 
> And I think, as a performance optimiztion, we should bail out early here
> if the pasid has no users.

If the PASID has no users, it won't exist (iommu->kernel_svm will be
NULL). We still have to walk each IOMMU to see if it has one.

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.

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.

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 way, tlb_flush_kernel_range() doesn't even need to make the call
when there's no work to do...

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

  reply	other threads:[~2015-10-20 16:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-20 15:52 [RFC PATCH] iommu/vt-d: Add IOTLB flush support for kernel addresses David Woodhouse
2015-10-20 16:03 ` Joerg Roedel
2015-10-20 16:17   ` David Woodhouse [this message]
2015-10-23 10:20     ` Joerg Roedel
2015-10-23 10:33       ` David Woodhouse
2015-10-23 11:03         ` Joerg Roedel
2015-10-23 11:37           ` David Woodhouse
2015-10-23 12:42             ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1445357824.4486.65.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-mm@kvack.org \
    --cc=sudeep.dutt@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).