[PATCH] drm/radeon/kms: fix GTT/VRAM overlapping test

From: Jerome Glisse jgli...@redhat.com GTT/VRAM overlapping test had a typo which leaded to not detecting case when vram_end gtt_end. This patch fix the logic and should fix #16574 cc: stable Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon_device.c |2 +-

[PATCH] drm/radeon/kms: r6xx/r7xx flush shader cache at fence emision

From: Jerome Glisse jgli...@redhat.com GPU is prone to lockup if we deallocate shader bo right after submitting command using the shader. Force shader cache flush after each batch submission seems to fix the issue. It could fix some of the lockup people were experiencing. Signed-off-by: Jerome

[PATCH] drm/radeon/kms: r6xx/r7xx flush shader cache at fence emision V2

From: Jerome Glisse jgli...@redhat.com GPU is prone to lockup if we deallocate shader bo right after submitting command using the shader. Force shader cache flush after each batch submission seems to fix the issue. It could fix some of the lockup people were experiencing. V2 move shader flush

[PATCH] drm/radeon/kms: forbid allocating bo bigger than VRAM or GTT (fdo 31708)

From: Jerome Glisse jgli...@redhat.com Forbid allocating buffer bigger than VRAM or GTT, also properly set lpfn field of placement if VRAM is too small. Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon.h|2 +- drivers/gpu/drm/radeon/radeon_object.c |

[PATCH] drm/radeon/kms: forbid big bo allocation (fdo 31708)

From: Jerome Glisse jgli...@redhat.com Forbid allocating buffer bigger than visible VRAM or GTT, also properly set lpfn field. Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon_object.c | 36 ++- 1 files changed, 30 insertions(+), 6

[PATCH] drm/radeon/kms: forbid big bo allocation (fdo 31708) v2

From: Jerome Glisse jgli...@redhat.com Forbid allocating buffer bigger than visible VRAM or GTT, also properly set lpfn field. v2 - use max macro - silence warning Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon_object.c | 34

[PATCH] drm/radeon/kms: forbid big bo allocation (fdo 31708) v3

From: Jerome Glisse jgli...@redhat.com Forbid allocating buffer bigger than visible VRAM or GTT, also properly set lpfn field. v2 - use max macro - silence warning v3 - don't explicitly set range limit - use min macro Cc: stable sta...@kernel.org Signed-off-by: Jerome Glisse

[PATCH] drm/radeon/kms: forbid big bo allocation (fdo 31708) v4

From: Jerome Glisse jgli...@redhat.com Forbid allocating buffer bigger than visible VRAM or GTT, also properly set lpfn field. v2 - use max macro - silence warning v3 - don't explicitly set range limit - use min macro v4 - use max btw GTT VRAM size Cc: stable sta...@kernel.org

[PATCH] radeon/kms: fix dp displayport mode validation

From: Jerome Glisse jgli...@redhat.com Check if there is a big enough dp clock enough dp lane to drive the video mode provided. Signed-off-by: Jerome Glisse jgli...@redhat.com Cc: sta...@kernel.org --- drivers/gpu/drm/radeon/atombios_dp.c |4 ++-- 1 files changed, 2 insertions(+), 2

[PATCH 00/13] mmu_notifier kill invalidate_page callback v2

From: Jérôme Glisse (Sorry for so many list cross-posting and big cc) Changes since v1: - remove more dead code in kvm (no testing impact) - more accurate end address computation (patch 2) in page_mkclean_one and try_to_unmap_one - added tested-by/reviewed-by

[PATCH] drm/nouveau: remove ghost file

From: Jérôme Glisse This ghost file have been haunting us. Signed-off-by: Jérôme Glisse --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gp10b. | 0 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gp10b. diff --git

[PATCH 1/2] gpu/radeon: use HMM mirror instead of mmu_notifier

From: Jérôme Glisse HMM provide a sets of helpers to avoid individual drivers re-doing their own. This patch convert the radeon to use HMM mirror to track CPU page table update and invalidate accordingly for userptr object. Signed-off-by: Jérôme Glisse Cc: dri-devel@lists.freedesktop.org Cc:

[PATCH 2/2] gpu/radeon: use HMM mirror for userptr buffer object.

From: Jérôme Glisse This replace existing code that rely on get_user_page() aka GUP with code that now use HMM mirror to mirror a range of virtual address as a buffer object accessible by the GPU. There is no functional changes from userspace point of view. From kernel point of view we no

[PATCH 2/2] gpu/i915: use HMM mirror for userptr buffer object.

From: Jérôme Glisse This replace existing code that rely on get_user_page() aka GUP with code that now use HMM mirror to mirror a range of virtual address as a buffer object accessible by the GPU. There is no functional changes from userspace point of view. From kernel point of view we no

[PATCH 0/2] [i915] Getting rid of GUP and use HMM for user ptr features.

From: Jérôme Glisse [This depends on some HMM patchset queued upstream see branch [1]] This is simple change to switch to use HMM for user ptr buffer object which conveniently avoid to pin pages. I have more things in the pipe to make HMM more usefull for such cases (like sharing more resources

[PATCH 0/2] [radeon] Getting rid of GUP and use HMM for user ptr features.

From: Jérôme Glisse [This depends on some HMM patchset queued upstream see branch [1]] This is simple change to switch to use HMM for user ptr buffer object which conveniently avoid to pin pages. I have more things in the pipe to make HMM more usefull for such cases (like sharing more resources

[PATCH 1/2] gpu/i915: use HMM mirror instead of mmu_notifier

From: Jérôme Glisse HMM provide a sets of helpers to avoid individual drivers re-doing their own. This patch convert the radeon to use HMM mirror to track CPU page table update and invalidate accordingly for userptr object. Signed-off-by: Jérôme Glisse Cc: dri-devel@lists.freedesktop.org Cc:

[RFC PATCH 11/13] drm/nouveau: add HMM area creation user interface

From: Jérôme Glisse User API to create HMM area. Signed-off-by: Jérôme Glisse Cc: Ben Skeggs --- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 9 + drivers/gpu/drm/nouveau/include/nvif/vmm.h | 2 +

[RFC PATCH 09/13] drm/nouveau: add SVM through HMM support to nouveau client

From: Jérôme Glisse SVM (Share Virtual Memory) through HMM (Heterogeneous Memory Management) to nouveau client. SVM means that any valid pointer (private anonymous, share memory or mmap of regular file) on the CPU is also valid on the GPU. To achieve SVM with nouveau we use

[RFC PATCH 06/13] drm/nouveau/fault/gp100: initial implementation of MaxwellFaultBufferA

From: Ben Skeggs Signed-off-by: Ben Skeggs --- drivers/gpu/drm/nouveau/include/nvif/class.h | 2 + drivers/gpu/drm/nouveau/include/nvif/clb069.h | 8 ++ .../gpu/drm/nouveau/include/nvkm/engine/fault.h| 1 +

[RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau

From: Jérôme Glisse (mm is cced just to allow exposure of device driver work without ccing a long list of peoples. I do not think there is anything usefull to discuss from mm point of view but i might be wrong, so just for the curious :)).

[RFC PATCH 05/13] drm/nouveau/mc/gp100-: handle replayable fault interrupt

From: Ben Skeggs Signed-off-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp100.c | 20 +++- drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp10b.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/mc/priv.h | 2 ++ 3 files changed, 22

[RFC PATCH 01/13] drm/nouveau/vmm: enable page table iterator over non populated range

From: Jérôme Glisse This patch modify the page table iterator to support empty range when unmaping a range (ie when it is not trying to populate the range). Signed-off-by: Jérôme Glisse Cc: Ben Skeggs ---

[RFC PATCH 02/13] drm/nouveau/core/memory: add some useful accessor macros

From: Jérôme Glisse Adds support for 64-bits read. Signed-off-by: Jérôme Glisse --- drivers/gpu/drm/nouveau/include/nvkm/core/memory.h | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h

[RFC PATCH 03/13] drm/nouveau/core: define engine for handling replayable faults

From: Ben Skeggs Signed-off-by: Ben Skeggs --- drivers/gpu/drm/nouveau/include/nvkm/core/device.h | 3 +++ drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h | 4 drivers/gpu/drm/nouveau/nvkm/core/subdev.c | 1 +

[RFC PATCH 10/13] drm/nouveau: add HMM area creation

From: Jérôme Glisse HMM area is a virtual address range under HMM control, GPU access inside such range is like CPU access. For thing to work properly HMM range should cover everything except a reserved range for GEM buffer object. Signed-off-by: Jérôme Glisse

[RFC PATCH 08/13] drm/nouveau: special mapping method for HMM (user interface)

From: Jérôme Glisse Signed-off-by: Jérôme Glisse Cc: Ben Skeggs --- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 17 drivers/gpu/drm/nouveau/include/nvif/vmm.h| 2 +

[RFC PATCH 07/13] drm/nouveau: special mapping method for HMM

From: Jérôme Glisse HMM does not have any of the usual memory object properties. For HMM inside any range the following is true: - not all page in a range are valid - not all page have same permission (read only, read and write) - not all page are in same memory

[RFC PATCH 12/13] drm/nouveau: HMM area creation helpers for nouveau client

From: Jérôme Glisse Helpers to create area of virtual address under HMM control for a nouveau client. GPU access to HMM area are valid as long as the hole vma exist in the process virtual address space. Signed-off-by: Jérôme Glisse Cc: Ben Skeggs

[RFC PATCH 04/13] drm/nouveau/mmu/gp100: allow gcc/tex to generate replayable faults

From: Ben Skeggs Signed-off-by: Ben Skeggs --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c

[RFC PATCH 13/13] drm/nouveau: HACK FOR HMM AREA

From: Jérôme Glisse Allow userspace to create a virtual address range hole for GEM object. Signed-off-by: Jérôme Glisse --- drivers/gpu/drm/nouveau/nouveau_ttm.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git

[PATCH v4 2/9] mm/mmu_notifier: contextual information for event triggering invalidation

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH v4 3/9] mm/mmu_notifier: use correct mmu_notifier events for each invalidation

From: Jérôme Glisse This update each existing invalidation to use the correct mmu notifier event that represent what is happening to the CPU page table. See the patch which introduced the events to see the rational behind this. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Jan Kara

[PATCH v4 0/9] mmu notifier provide context informations

From: Jérôme Glisse Hi Andrew, i see that you still have my event patch in you queue [1]. This patchset replace that single patch and is broken down in further step so that it is easier to review and ascertain that no mistake were made during mechanical changes. Here are the step: Patch 1 -

[PATCH v4 4/9] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH v4 1/9] mm/mmu_notifier: contextual information for event enums

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). This patch introduce a set of enums that can be

[PATCH v4 5/9] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper

From: Jérôme Glisse Helper to test if a range is updated to read only (it is still valid to read from the range). This is useful for device driver or anyone who wish to optimize out update when they know that they already have the range map read only. Signed-off-by: Jérôme Glisse Cc: Christian

[PATCH v4 6/9] gpu/drm/radeon: optimize out the case when a range is updated to read only

From: Jérôme Glisse When range of virtual address is updated read only and corresponding user ptr object are already read only it is pointless to do anything. Optimize this case out. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Jan Kara Cc: Felix Kuehling Cc: Jason Gunthorpe Cc:

[PATCH v4 9/9] RDMA/umem_odp: optimize out the case when a range is updated to read only

From: Jérôme Glisse When range of virtual address is updated read only and corresponding user ptr object are already read only it is pointless to do anything. Optimize this case out. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Jan Kara Cc: Felix Kuehling Cc: Jason Gunthorpe Cc:

[PATCH v4 8/9] gpu/drm/i915: optimize out the case when a range is updated to read only

From: Jérôme Glisse When range of virtual address is updated read only and corresponding user ptr object are already read only it is pointless to do anything. Optimize this case out. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Jan Kara Cc: Felix Kuehling Cc: Jason Gunthorpe Cc:

[PATCH v4 7/9] gpu/drm/amdgpu: optimize out the case when a range is updated to read only

From: Jérôme Glisse When range of virtual address is updated read only and corresponding user ptr object are already read only it is pointless to do anything. Optimize this case out. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Jan Kara Cc: Felix Kuehling Cc: Jason Gunthorpe Cc:

[PATCH v3 1/3] mm/mmu_notifier: use structure for invalidate_range_start/end callback v2

From: Jérôme Glisse To avoid having to change many callback definition everytime we want to add a parameter use a structure to group all parameters for the mmu_notifier invalidate_range_start/end callback. No functional changes with this patch. Changed since v1: - fix make htmldocs warning

[PATCH v3 0/3] mmu notifier contextual informations

From: Jérôme Glisse Changes since v2: - fix build warning with CONFIG_MMU_NOTIFIER=n - fix make htmldocs warning Changes since v1: - fix build with CONFIG_MMU_NOTIFIER=n - kernel docs Original cover letter: This patchset add contextual information, why an invalidation is happening, to

[PATCH v3 2/3] mm/mmu_notifier: use structure for invalidate_range_start/end calls v3

From: Jérôme Glisse To avoid having to change many call sites everytime we want to add a parameter use a structure to group all parameters for the mmu_notifier invalidate_range_start/end cakks. No functional changes with this patch. Changes since v2: - fix build warning in migrate.c when

[PATCH v3 3/3] mm/mmu_notifier: contextual information for event triggering invalidation v2

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH 3/3] mm/mmu_notifier: contextual information for event triggering invalidation

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH 2/3] mm/mmu_notifier: use structure for invalidate_range_start/end calls

From: Jérôme Glisse To avoid having to change many call sites everytime we want to add a parameter use a structure to group all parameters for the mmu_notifier invalidate_range_start/end cakks. No functional changes with this patch. Signed-off-by: Jérôme Glisse Cc: Andrew Morton Cc: Matthew

[PATCH 0/3] mmu notifier contextual informations

From: Jérôme Glisse This patchset add contextual information, why an invalidation is happening, to mmu notifier callback. This is necessary for user of mmu notifier that wish to maintains their own data structure without having to add new fields to struct vm_area_struct (vma). For instance

[PATCH 1/3] mm/mmu_notifier: use structure for invalidate_range_start/end callback

From: Jérôme Glisse To avoid having to change many callback definition everytime we want to add a parameter use a structure to group all parameters for the mmu_notifier invalidate_range_start/end callback. No functional changes with this patch. Signed-off-by: Jérôme Glisse Cc: Andrew Morton

[PATCH] dma-buf: fix debugfs versus rcu and fence dumping

From: Jérôme Glisse The debugfs take reference on fence without dropping them. Also the rcu section are not well balance. Fix all that ... Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Daniel Vetter Cc: Sumit Semwal Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org

[PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

From: Jérôme Glisse The debugfs take reference on fence without dropping them. Also the rcu section are not well balance. Fix all that ... Changed since v1: - moved fobj logic around to be rcu safe Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Daniel Vetter Cc: Sumit Semwal Cc:

[PATCH] dma-buf: balance refcount inbalance

From: Jérôme Glisse The debugfs take reference on fence without dropping them. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Daniel Vetter Cc: Sumit Semwal Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Cc: Stéphane Marchesin

[PATCH v2 1/3] mm/mmu_notifier: use structure for invalidate_range_start/end callback

From: Jérôme Glisse To avoid having to change many callback definition everytime we want to add a parameter use a structure to group all parameters for the mmu_notifier invalidate_range_start/end callback. No functional changes with this patch. Signed-off-by: Jérôme Glisse Cc: Andrew Morton

[PATCH v2 2/3] mm/mmu_notifier: use structure for invalidate_range_start/end calls v2

From: Jérôme Glisse To avoid having to change many call sites everytime we want to add a parameter use a structure to group all parameters for the mmu_notifier invalidate_range_start/end cakks. No functional changes with this patch. Changes since v1: - introduce mmu_notifier_range_init() as

[PATCH v2 3/3] mm/mmu_notifier: contextual information for event triggering invalidation v2

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH v6 1/8] mm/mmu_notifier: helper to test if a range invalidation is blockable

From: Jérôme Glisse Simple helpers to test if range invalidation is blockable. Latter patches use cocinnelle to convert all direct dereference of range-> blockable to use this function instead so that we can convert the blockable field to an unsigned for more flags. Signed-off-by: Jérôme Glisse

[PATCH v6 5/8] mm/mmu_notifier: contextual information for event triggering invalidation v2

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH v6 4/8] mm/mmu_notifier: contextual information for event enums

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). This patch introduce a set of enums that can be

[PATCH v6 7/8] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH v6 8/8] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper

From: Jérôme Glisse Helper to test if a range is updated to read only (it is still valid to read from the range). This is useful for device driver or anyone who wish to optimize out update when they know that they already have the range map read only. Signed-off-by: Jérôme Glisse Cc: Andrew

[PATCH v6 3/8] mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags

From: Jérôme Glisse Use an unsigned field for flags other than blockable and convert the blockable field to be one of those flags. Signed-off-by: Jérôme Glisse Cc: Andrew Morton Cc: linux...@kvack.org Cc: Christian König Cc: Joonas Lahtinen Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Jan Kara

[PATCH v6 0/8] mmu notifier provide context informations

From: Jérôme Glisse (Andrew this apply on top of my HMM patchset as otherwise you will have conflict with changes to mm/hmm.c) Changes since v5: - drop KVM bits waiting for KVM people to express interest if they do not then i will post patchset to remove change_pte_notify as

[PATCH v6 2/8] mm/mmu_notifier: convert user range->blockable to helper function

From: Jérôme Glisse Use the mmu_notifier_range_blockable() helper function instead of directly dereferencing the range->blockable field. This is done to make it easier to change the mmu_notifier range field. This patch is the outcome of the following coccinelle patch:

[PATCH v6 6/8] mm/mmu_notifier: use correct mmu_notifier events for each invalidation

From: Jérôme Glisse This update each existing invalidation to use the correct mmu notifier event that represent what is happening to the CPU page table. See the patch which introduced the events to see the rational behind this. Signed-off-by: Jérôme Glisse Cc: Andrew Morton Cc:

[PATCH] gpu/nouveau: empty chunk do not have a buffer object associated with them.

From: Jérôme Glisse Empty chunk do not have a bo associated with them so no need to pin/unpin on suspend/resume. This fix suspend/resume on 5.1rc1 when NOUVEAU_SVM is enabled. Signed-off-by: Jérôme Glisse Reviewed-by: Tobias Klausmann Tested-by: Tobias Klausmann Cc: Ben Skeggs Cc:

[PATCH v5 6/9] mm/mmu_notifier: use correct mmu_notifier events for each invalidation

From: Jérôme Glisse This update each existing invalidation to use the correct mmu notifier event that represent what is happening to the CPU page table. See the patch which introduced the events to see the rational behind this. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Joonas

[PATCH v5 7/9] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH v5 0/9] mmu notifier provide context informations

From: Jérôme Glisse Since last version [4] i added the extra bits needed for the change_pte optimization (which is a KSM thing). Here i am not posting users of this, they will be posted to the appropriate sub-systems (KVM, GPU, RDMA, ...) once this serie get upstream. If you want to look at

[PATCH v5 2/9] mm/mmu_notifier: convert user range->blockable to helper function

From: Jérôme Glisse Use the mmu_notifier_range_blockable() helper function instead of directly dereferencing the range->blockable field. This is done to make it easier to change the mmu_notifier range field. This patch is the outcome of the following coccinelle patch:

[PATCH v5 4/9] mm/mmu_notifier: contextual information for event enums

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). This patch introduce a set of enums that can be

[PATCH v5 5/9] mm/mmu_notifier: contextual information for event triggering invalidation v2

From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). Users of mmu notifier API track changes to the CPU

[PATCH v5 3/9] mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags

From: Jérôme Glisse Use an unsigned field for flags other than blockable and convert the blockable field to be one of those flags. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Joonas Lahtinen Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Jan Kara Cc: Andrea Arcangeli Cc: Peter Xu Cc:

[PATCH v5 1/9] mm/mmu_notifier: helper to test if a range invalidation is blockable

From: Jérôme Glisse Simple helpers to test if range invalidation is blockable. Latter patches use cocinnelle to convert all direct dereference of range-> blockable to use this function instead so that we can convert the blockable field to an unsigned for more flags. Signed-off-by: Jérôme Glisse

[PATCH v5 8/9] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper

From: Jérôme Glisse Helper to test if a range is updated to read only (it is still valid to read from the range). This is useful for device driver or anyone who wish to optimize out update when they know that they already have the range map read only. Signed-off-by: Jérôme Glisse Cc: Christian

[PATCH v5 9/9] mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where appropriate v2

From: Jérôme Glisse When notifying change for a range use MMU_NOTIFIER_USE_CHANGE_PTE flag for page table update that use set_pte_at_notify() and where the we are going either from read and write to read only with same pfn or read only to read and write with new pfn. Note that

[RFC PATCH 5/5] mm/hmm: add support for peer to peer to special device vma

From: Jérôme Glisse Special device vma (mmap of a device file) can correspond to device driver object that some device driver might want to share with other device (giving access to). This add support for HMM to map those special device vma if the owning device (exporter) allows it.

[RFC PATCH 4/5] mm/hmm: add support for peer to peer to HMM device memory

From: Jérôme Glisse Signed-off-by: Jérôme Glisse Cc: Logan Gunthorpe Cc: Greg Kroah-Hartman Cc: Rafael J. Wysocki Cc: Bjorn Helgaas Cc: Christian Koenig Cc: Felix Kuehling Cc: Jason Gunthorpe Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Christoph Hellwig Cc:

[RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

From: Jérôme Glisse Allow mmap of device file to export device memory to peer to peer devices. This will allow for instance a network device to access a GPU memory or to access a storage device queue directly. The common case will be a vma created by userspace device driver that is then share

[RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability

From: Jérôme Glisse device_test_p2p() return true if two devices can peer to peer to each other. We add a generic function as different inter-connect can support peer to peer and we want to genericaly test this no matter what the inter-connect might be. However this version only support PCIE for

[RFC PATCH 2/5] drivers/base: add a function to test peer to peer capability

From: Jérôme Glisse device_test_p2p() return true if two devices can peer to peer to each other. We add a generic function as different inter-connect can support peer to peer and we want to genericaly test this no matter what the inter-connect might be. However this version only support PCIE for

[RFC PATCH 0/5] Device peer to peer (p2p) through vma

From: Jérôme Glisse This patchset add support for peer to peer between device in two manner. First for device memory use through HMM in process regular address space (ie inside a regular vma that is not an mmap of device file or special file). Second for special vma ie mmap of a device file, in