linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <jweiner@redhat.com>,
	Jerome Glisse <jglisse@redhat.com>,
	jroedel@suse.de, Jay.Cornwall@amd.com, Oded.Gabbay@amd.com,
	John.Bridgman@amd.com, Suravee.Suthikulpanit@amd.com,
	ben.sander@amd.com, Jesse Barnes <jbarnes@virtuousgeek.org>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	iommu@lists.linux-foundation.org
Subject: Re: [PATCH 0/3 v2] mmu_notifier: Allow to manage CPU external TLBs
Date: Thu, 31 Jul 2014 10:54:16 -0400	[thread overview]
Message-ID: <20140731145414.GA1955@gmail.com> (raw)
In-Reply-To: <1406650693-23315-1-git-send-email-joro@8bytes.org>

On Tue, Jul 29, 2014 at 06:18:10PM +0200, Joerg Roedel wrote:
> Changes V1->V2:
> 
> * Rebase to v3.16-rc7
> * Added call of ->invalidate_range to
>   __mmu_notifier_invalidate_end() so that the subsystem
>   doesn't need to register an ->invalidate_end() call-back,
>   subsystems will likely either register
>   invalidate_range_start/end or invalidate_range, so that
>   should be fine.
> * Re-orded declarations a bit to reflect that
>   invalidate_range is not only called between
>   invalidate_range_start/end
> * Updated documentation to cover the case where
>   invalidate_range is called outside of
>   invalidate_range_start/end to flush page-table pages out
>   of the TLB
> 
> Hi,
> 
> here is a patch-set to extend the mmu_notifiers in the Linux
> kernel to allow managing CPU external TLBs. Those TLBs may
> be implemented in IOMMUs or any other external device, e.g.
> ATS/PRI capable PCI devices.
> 
> The problem with managing these TLBs are the semantics of
> the invalidate_range_start/end call-backs currently
> available. Currently the subsystem using mmu_notifiers has
> to guarantee that no new TLB entries are established between
> invalidate_range_start/end. Furthermore the
> invalidate_range_start() function is called when all pages
> are still mapped and invalidate_range_end() when the pages
> are unmapped an already freed.
> 
> So both call-backs can't be used to safely flush any non-CPU
> TLB because _start() is called too early and _end() too
> late.
> 
> In the AMD IOMMUv2 driver this is currently implemented by
> assigning an empty page-table to the external device between
> _start() and _end(). But as tests have shown this doesn't
> work as external devices don't re-fault infinitly but enter
> a failure state after some time.
> 
> Next problem with this solution is that it causes an
> interrupt storm for IO page faults to be handled when an
> empty page-table is assigned.
> 
> Furthermore the _start()/end() notifiers only catch the
> moment when page mappings are released, but not page-table
> pages. But this is necessary for managing external TLBs when
> the page-table is shared with the CPU.
> 
> To solve this situation I wrote a patch-set to introduce a
> new notifier call-back: mmu_notifer_invalidate_range(). This
> notifier lifts the strict requirements that no new
> references are taken in the range between _start() and
> _end(). When the subsystem can't guarantee that any new
> references are taken is has to provide the
> invalidate_range() call-back to clear any new references in
> there.
> 
> It is called between invalidate_range_start() and _end()
> every time the VMM has to wipe out any references to a
> couple of pages. This are usually the places where the CPU
> TLBs are flushed too and where its important that this
> happens before invalidate_range_end() is called.
> 
> Any comments and review appreciated!

For the series :

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

> 
> Thanks,
> 
> 	Joerg
> 
> Joerg Roedel (3):
>   mmu_notifier: Add mmu_notifier_invalidate_range()
>   mmu_notifier: Call mmu_notifier_invalidate_range() from VMM
>   mmu_notifier: Add the call-back for mmu_notifier_invalidate_range()
> 
>  include/linux/mmu_notifier.h | 75 +++++++++++++++++++++++++++++++++++++++++---
>  kernel/events/uprobes.c      |  2 +-
>  mm/fremap.c                  |  2 +-
>  mm/huge_memory.c             |  9 +++---
>  mm/hugetlb.c                 |  7 ++++-
>  mm/ksm.c                     |  4 +--
>  mm/memory.c                  |  3 +-
>  mm/migrate.c                 |  3 +-
>  mm/mmu_notifier.c            | 25 +++++++++++++++
>  mm/rmap.c                    |  2 +-
>  10 files changed, 115 insertions(+), 17 deletions(-)
> 
> -- 
> 1.9.1
> 
> --
> 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>

--
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>

      parent reply	other threads:[~2014-07-31 14:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29 16:18 [PATCH 0/3 v2] mmu_notifier: Allow to manage CPU external TLBs Joerg Roedel
2014-07-29 16:18 ` [PATCH 1/3] mmu_notifier: Add mmu_notifier_invalidate_range() Joerg Roedel
2014-07-29 16:18 ` [PATCH 2/3] mmu_notifier: Call mmu_notifier_invalidate_range() from VMM Joerg Roedel
2014-08-16 12:55   ` Oded Gabbay
2014-07-29 16:18 ` [PATCH 3/3] mmu_notifier: Add the call-back for mmu_notifier_invalidate_range() Joerg Roedel
2014-07-31 14:54 ` Jerome Glisse [this message]

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=20140731145414.GA1955@gmail.com \
    --to=j.glisse@gmail.com \
    --cc=Jay.Cornwall@amd.com \
    --cc=John.Bridgman@amd.com \
    --cc=Oded.Gabbay@amd.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben.sander@amd.com \
    --cc=dwmw2@infradead.org \
    --cc=hughd@google.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jglisse@redhat.com \
    --cc=joro@8bytes.org \
    --cc=jroedel@suse.de \
    --cc=jweiner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=riel@redhat.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).