Re: [PATCH] mm: Remove double faults once write a device pfn

"Zhou, Xianrong" writes: > [AMD Official Use Only - General] > >> > The vmf_insert_pfn_prot could cause unnecessary double faults on a >> > device pfn. Because currently the vmf_insert_pfn_prot does not >> > make the pfn writable so the pte entry is normally read-only or >> > di

Re: [Intel-gfx] [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

Christian König writes: > Am 01.12.23 um 06:48 schrieb Zeng, Oak: >> [SNIP] >> Besides memory eviction/oversubscription, there are a few other pain points >> when I use hmm: >> >> 1) hmm doesn't support file-back memory, so it is hard to share > memory b/t process in a gpu environment. You me

Re: [Intel-gfx] [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

"Zeng, Oak" writes: > See inline comments > >> -Original Message- >> From: dri-devel On Behalf Of >> zhuweixi >> Sent: Thursday, November 30, 2023 5:48 AM >> To: Christian König ; Zeng, Oak >> ; Christian König ; linux- >> m...@kvack.org; linux-ker...@vger.kernel.org; a...@linux-founda

Re: [Intel-gfx] [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

zhuweixi writes: > Glad to know that there is a common demand for a new syscall like > hmadvise(). I expect it would also be useful for homogeneous NUMA > cases. Credits to cudaMemAdvise() API which brought this idea to > GMEM's design. It's not clear to me that this would need to be a new sys

[Intel-gfx] [PATCH v4 1/5] arm64/smmu: Use TLBI ASID when invalidating entire range

: Alistair Popple Reviewed-by: Jason Gunthorpe --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c index a5a63b1

[Intel-gfx] [PATCH v4 2/5] mmu_notifiers: Fixup comment in mmu_interval_read_begin()

The comment in mmu_interval_read_begin() refers to a function that doesn't exist and uses the wrong call-back name. The op for mmu interval notifiers is mmu_interval_notifier_ops->invalidate() so fix the comment up to reflect that. Signed-off-by: Alistair Popple Reviewed-by: Jason G

[Intel-gfx] [PATCH v4 5/5] mmu_notifiers: Rename invalidate_range notifier

arch_invalidate_secondary_tlbs() and update documention. Signed-off-by: Alistair Popple Suggested-by: Jason Gunthorpe Acked-by: Catalin Marinas Reviewed-by: Jason Gunthorpe --- arch/arm64/include/asm/tlbflush.h | 6 +- arch/powerpc/mm/book3s64/radix_hugetlbpage.c| 2 +- arch/powerpc/mm

Re: [Intel-gfx] Regression in linux-next

420 > <4>[ 76.369537] ? __pfx_i915_gem_userptr_ioctl+0x10/0x10 [i915] > <4>[ 76.375242] ? find_held_lock+0x2b/0x80 > <4>[ 76.379046] __x64_sys_ioctl+0x79/0xb0 > <4>[ 76.382766] do_syscall_64+0x3c/0x90 > <4>[ 76.386312] entry_SYSCA

[Intel-gfx] [PATCH v4 0/5] Invalidate secondary IOMMU TLB on permission upgrade

re.kernel.org/all/20230602011518.787006-1-sea...@google.com/ [2] - https://lore.kernel.org/linux-mm/zjmr5bw8l+bbz...@ziepe.ca/ Alistair Popple (5): arm64/smmu: Use TLBI ASID when invalidating entire range mmu_notifiers: Fixup comment in mmu_interval_read_begin() mmu_notifiers: C

[Intel-gfx] [PATCH v4 4/5] mmu_notifiers: Don't invalidate secondary TLBs as part of mmu_notifier_invalidate_range_end()

() functions. Signed-off-by: Alistair Popple Reviewed-by: Jason Gunthorpe --- include/linux/mmu_notifier.h | 56 + kernel/events/uprobes.c | 2 +- mm/huge_memory.c | 25 ++--- mm/hugetlb.c | 1 +- mm/memory.c

[Intel-gfx] [PATCH v4 3/5] mmu_notifiers: Call invalidate_range() when invalidating TLBs

the IOMMUs require this. Signed-off-by: Alistair Popple Suggested-by: Jason Gunthorpe Tested-by: SeongJae Park Acked-by: Catalin Marinas Reviewed-by: Jason Gunthorpe --- arch/arm64/include/asm/tlbflush.h | 5 + arch/powerpc/include/asm/book3s/64/tlbflush.h | 1 + arch/