: Ralph Campbell
Tested-by: Ralph Campbell
---
drivers/gpu/drm/drm_edid.c | 1 +
1 file changed, 1 insertion(+)
I don't know how many of these VR headsets are still around but I have a
working one and I saw an entry for HDK 1.x so I thought it would be good
to add HDK 2.0.
v2: The vendor ID was
On 6/10/23 00:22, Jani Nikula wrote:
On Fri, 09 Jun 2023, Ralph Campbell wrote:
On 6/9/23 02:03, Jani Nikula wrote:
On Thu, 08 Jun 2023, Ralph Campbell wrote:
The OSVR virtual reality headset HDK 2.0 uses a different EDID
vendor and device identifier than the HDK 1.1 - 1.4 headsets.
Add
On 6/9/23 02:03, Jani Nikula wrote:
On Thu, 08 Jun 2023, Ralph Campbell wrote:
The OSVR virtual reality headset HDK 2.0 uses a different EDID
vendor and device identifier than the HDK 1.1 - 1.4 headsets.
Add the HDK 2.0 vendor and device identifier to the quirks table so
that window managers
: Ralph Campbell
Tested-by: Ralph Campbell
---
drivers/gpu/drm/drm_edid.c | 1 +
1 file changed, 1 insertion(+)
I don't know how many of these VR headsets are still around but I have a
working one and I saw and entry for HDK 1.x so I thought it would be good
to add HDK 2.0.
diff --git a/driver
iour.
Fixes: 241f68859656 ("mm/migrate_device.c: refactor migrate_vma and
migrate_deivce_coherent_page()")
Signed-off-by: Alistair Popple
Reported-by: Ralph Campbell
You can add
Reviewed-by: Ralph Campbell
Thanks!
t;drm/nouveau/svm: map pages after migration")
Thanks for fixing this!
Reviewed-by: Ralph Campbell
e the
notifiacation when the refcount hits 1 now, the PAGEMAP_OPS Kconfig
symbol can go away and be replaced with a FS_DAX check for this hook
in the put_page fastpath.
Based on an earlier patch from Ralph Campbell .
Signed-off-by: Christoph Hellwig
Thanks for working on this, definite step forward.
Rev
unlikely a second attempt will succeed,
and the retry adds complexity. So clean this up by removing the retry
and MIGRATE_PFN_LOCKED flag.
Destination pages are also meant to have the MIGRATE_PFN_LOCKED flag
set, but nothing actually checks that.
Signed-off-by: Alistair Popple
You can add:
Reviewed
On 10/14/21 11:01 AM, Jason Gunthorpe wrote:
On Thu, Oct 14, 2021 at 10:35:27AM -0700, Ralph Campbell wrote:
I ran xfstests-dev using the kernel boot option to "fake" a pmem device
when I first posted this patch. The tests ran OK (or at least the same
tests passed with and withou
On 10/14/21 10:06 AM, Jason Gunthorpe wrote:
On Thu, Oct 14, 2021 at 10:39:28AM -0500, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference
On 9/13/21 9:15 AM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration
On 8/25/21 4:15 AM, Vlastimil Babka wrote:
On 8/25/21 05:48, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is
On 8/17/21 5:35 PM, Felix Kuehling wrote:
Am 2021-08-17 um 8:01 p.m. schrieb Ralph Campbell:
On 8/12/21 11:31 PM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that
complicates the
code for put_page() and several places in the kernel that need
On 8/12/21 11:31 PM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration
On 6/28/21 9:46 AM, Felix Kuehling wrote:
Am 2021-06-17 um 3:16 p.m. schrieb Ralph Campbell:
On 6/17/21 8:16 AM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that
complicates the
code for put_page() and several places in the kernel that need
On 6/17/21 8:16 AM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration
On 3/3/21 10:16 PM, Alistair Popple wrote:
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this intro
combinations
of TTU_XXX flags are needed in which case a careful check of try_to_migrate()
and try_to_unmap() will be needed.
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo
() which specifies no other flags. Therefore rather than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
Looks good to me.
Reviewed-by: Ralph Campbell
__
both read and write entry
creation.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Looks good to me too.
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
: Ralph Campbell
---
v4:
* Added pfn_swap_entry_to_page()
* Reinstated check that migration entries point to locked pages
* Removed #define swapcache_prepare which isn't needed for CONFIG_SWAP=0
builds
---
arch/s390/mm/pgtable.c | 2 +-
fs/proc/task_mmu.c
Popple
One minor nit below, but you can add
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
> +static int dmirror_exclusive(struct dmirror *dmirror,
> + struct hmm_dmirror_cmd *cmd)
> +{
> + unsigned long start, end, addr;
> + unsigned long s
> From: Alistair Popple
> Sent: Thursday, February 25, 2021 11:18 PM
> To: linux...@kvack.org; nouv...@lists.freedesktop.org;
> bske...@redhat.com; a...@linux-foundation.org
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; Jo
.org; John Hubbard
> ; Ralph Campbell ;
> jgli...@redhat.com; h...@infradead.org; dan...@ffwll.ch
> Subject: Re: [PATCH v3 6/8] mm: Selftests for exclusive device memory
>
> On Fri, Feb 26, 2021 at 06:18:30PM +1100, Alistair Popple wrote:
> > Adds some selftests for exclusi
On 7/30/20 5:03 AM, Jason Gunthorpe wrote:
On Thu, Jul 30, 2020 at 07:21:10PM +1000, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the hmm tree got a conflict in:
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
between commit:
7763d24f3ba0 ("drm/nouveau/vmm/gp100-: f
.pfn = gp100_vmm_pgt_pfn
nvkm_vmm_iter()
REF_PTES == func == gp100_vmm_pgt_pfn()
dma_map_page()
Acked-by: Felix Kuehling
Tested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
---
Documenta
hmm_range_fault()
All the drivers are adjusted to process in the simplified format.
I would appreciated tested-by's for the two drivers, thanks!
For nouveau you can add:
Tested-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ile Karol Herbst's mesa tree and Jerome's SVM tests to
test this with nouveau so for the series you can add,
Tested-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
211 deletions(-)
The series looks good to me so,
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
: Ralph Campbell
---
include/linux/hmm.h | 50 -
mm/hmm.c| 12 +++
2 files changed, 12 insertions(+), 50 deletions(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index bb6be4428633a8..184a8633260f9d 100644
--- a/include
On 3/20/20 9:48 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
I've had these in my work queue for a bit, nothing profound here, just some
small edits for clarity.
The hmm tester changes are clear enough but I'm having a bit of trouble
figuring out
what this series applies cleanly to sin
On 3/19/20 5:14 PM, Jason Gunthorpe wrote:
On Tue, Mar 17, 2020 at 04:14:31PM -0700, Ralph Campbell wrote:
+static int dmirror_fault(struct dmirror *dmirror, unsigned long start,
+unsigned long end, bool write)
+{
+ struct mm_struct *mm = dmirror->
Adding linux-kselft...@vger.kernel.org for the test config question.
On 3/19/20 11:17 AM, Jason Gunthorpe wrote:
On Tue, Mar 17, 2020 at 04:14:31PM -0700, Ralph Campbell wrote:
On 3/17/20 5:59 AM, Christoph Hellwig wrote:
On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
I&#x
695ecdcd759fb16bc1ca3c93 Mon Sep 17 00:00:00 2001
From: Ralph Campbell
Date: Tue, 17 Mar 2020 11:10:38 -0700
Subject: [PATCH] mm/hmm/test: add self tests for HMM
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add some basic stand alone self tests f
On 3/17/20 4:56 AM, Jason Gunthorpe wrote:
On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote:
The reason for it being backwards is that "normally" a device doesn't want
the device private page to be faulted back to system memory, it wants to
get the device private
On 3/17/20 12:34 AM, Christoph Hellwig wrote:
On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote:
On 3/16/20 12:32 PM, Christoph Hellwig wrote:
Remove the code to fault device private pages back into system memory
that has never been used by any driver. Also replace the usage of
ivate memory. Fix this by
passing in an expected pgmap owner in the hmm_range_fault structure.
Signed-off-by: Christoph Hellwig
Fixes: 4ef589dc9b10 ("mm/hmm/devmem: device memory hotplug using ZONE_DEVICE")
Looks good.
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouv
On 3/16/20 12:32 PM, Christoph Hellwig wrote:
Remove the code to fault device private pages back into system memory
that has never been used by any driver. Also replace the usage of the
HMM_PFN_DEVICE_PRIVATE flag in the pfns array with a simple
is_device_private_page check in nouveau.
Signed
ct page so if it
isn't, then it does make sense to not migrate whatever normal page is there.
nouveau_dmem_migrate_to_ram() sets src_owner so this case looks OK.
Just had to think this through.
Reviewed-by: Ralph Campbell
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 1 +
drivers/gpu/dr
looks like a reasonable approach to take.
Reviewed-by: Ralph Campbell
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 2 ++
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
include/linux/memremap.h | 4
mm/memremap.c | 4
4 files changed, 11
On 3/16/20 1:09 PM, Jason Gunthorpe wrote:
On Mon, Mar 16, 2020 at 07:49:35PM +0100, Christoph Hellwig wrote:
On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
On 3/16/20 10:52 AM, Christoph Hellwig wrote:
No driver has actually used properly wire up and support this feature
On 3/16/20 11:49 AM, Christoph Hellwig wrote:
On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
On 3/16/20 10:52 AM, Christoph Hellwig wrote:
No driver has actually used properly wire up and support this feature.
There is various code related to it in nouveau, but as far as I
On 3/16/20 10:52 AM, Christoph Hellwig wrote:
No driver has actually used properly wire up and support this feature.
There is various code related to it in nouveau, but as far as I can tell
it never actually got turned on, and the only changes since the initial
commit are global cleanups.
Thi
m/hmm: change hmm_vma_fault() to allow write fault on page
basis")
Signed-off-by: Jason Gunthorpe
Looks good to me.
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Bonus patch, this one got found after I made the series..
diff --git a/mm/
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index f61fddf2ef6505..ca33d086bdc190 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -335,16 +335,21 @@ static int hmm_vma_handle_pte(struct mm_
horpe
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index bf676cfef3e8ee..f61fddf2ef6505 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -363,8 +363,10 @@ static int hmm_vma_
Gunthorpe
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 35 +++
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index e10cd0adba7b37..bf676cfef3e8ee 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -282,15 +282,6 @@ static int
return should be HMM_PFN_ERROR.
Fixes: a3e0d41c2b1f ("mm/hmm: improve driver API to work and wait over a range")
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/mm/
n pmd")
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 32dcbfd3908315..5f5ccf13dd1e85 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -394,7 +394,7 @@ static int hmm_vma_walk
ewalk: add p4d_entry() and pgd_entry()")
Cc: Steven Price
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 9e8f68eb83287a..32dcbfd3908315 100644
---
m")
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
We talked about just deleting this stuff, but I think it makes alot sense for
hmm_range_fault() to trigger fault on devmap
but one issue noted below.
In any case, you can add:
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 72e5a6d9a41756..35f85424176d14 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -325,6 +325,7 @@ static in
When migrating system memory to GPU memory, check that SVM has been
enabled. Even though most errors can be ignored since migration is
a performance optimization, return an error because this is a violation
of the API.
Signed-off-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 5
-off-by: Ralph Campbell
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: "Jérôme Glisse"
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 46 +---
drivers/gpu/drm/nouveau/nouveau_dmem.h | 2 +
drivers/gpu/drm/nouveau/nouveau_s
ter than
svmm->unmanaged.limit which is greater than svmm->unmanaged.start and the
start = max_t(u64, start, svmm->unmanaged.limit) will change nothing.
Just remove the useless lines of code.
Signed-off-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 3 ---
1 file changed
his and
can call migrate_vma_setup() with a starting address less than
vma->vm_start. This results in migrate_vma_setup() returning -EINVAL for
the range instead of nouveau skipping that part of the range and migrating
the rest.
Signed-off-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 1 +
v2:
Added patches 1-3 to fix some minor issues.
Eliminated nouveau_find_svmm() since it is easily found.
Applied Jason Gunthorpe's suggestions for nouveau_pfns_to_args().
Changes since v1:
Rebase to linux-5.6.0-rc4
Address Christoph Hellwig's comments
Ralph Campbell (4):
nouveau/hmm:
On 3/3/20 4:42 AM, Jason Gunthorpe wrote:
On Mon, Mar 02, 2020 at 05:00:23PM -0800, Ralph Campbell wrote:
When memory is migrated to the GPU, it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the
-off-by: Ralph Campbell
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: "Jérôme Glisse"
Cc: Ben Skeggs
---
Originally this patch was targeted for Jason's rdma tree since other HMM
related changes were queued there. Now that those have been merged, this
patch just contains changes t
On 11/13/19 8:46 AM, Jason Gunthorpe wrote:
On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote:
+int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
+ struct mm_struct *mm, unsigned long start,
+
n add my Tested-by for the mm and nouveau changes.
IOW, patches 1-4, 10-11, and 15.
Tested-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 9/12/19 1:26 AM, Christoph Hellwig wrote:
+static int hmm_pfns_fill(unsigned long addr,
+unsigned long end,
+struct hmm_range *range,
+enum hmm_pfn_value_e value)
Nit: can we use the space a little more efficient, e.g.:
On 9/12/19 1:26 AM, Christoph Hellwig wrote:
On Wed, Sep 11, 2019 at 03:28:27PM -0700, Ralph Campbell wrote:
Allow hmm_range_fault() to return success (0) when the CPU pagetable
entry points to the special shared zero page.
The caller can then handle the zero page by possibly clearing device
point.
[1] https://lore.kernel.org/linux-mm/20190726005650.2566-6-rcampb...@nvidia.com/
Ralph Campbell (4):
mm/hmm: make full use of walk_page_range()
mm/hmm: allow snapshot of the special zero page
mm/hmm: allow hmm_range_fault() of mmap(PROT_NONE)
mm/hmm/test: add self tests for HMM
M
efore calling hmm_range_fault().
If the call to hmm_range_fault() is not a snapshot, the caller can still
check that pfns have the desired access permissions.
Signed-off-by: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: Jason Gunthorpe
Cc: Christoph Hellwig
---
mm/hmm.c | 4 +++-
1 file chan
Allow hmm_range_fault() to return success (0) when the CPU pagetable
entry points to the special shared zero page.
The caller can then handle the zero page by possibly clearing device
private memory instead of DMAing a zero page.
Signed-off-by: Ralph Campbell
Cc: "Jérôme Glisse"
hmm_range_fault() was not checking
start >= vma->vm_start before checking vma->vm_flags so hmm_range_fault()
could return an error based on the wrong vma for the requested range.
Signed-off-by: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: Jason Gunthorpe
Cc: Christoph Hellwig
Add self tests for HMM.
Signed-off-by: Ralph Campbell
---
MAINTAINERS|3 +
drivers/char/Kconfig | 11 +
drivers/char/Makefile |1 +
drivers/char/hmm_dmirror.c | 1504
include/Kbuild
On 8/27/19 11:41 AM, Jason Gunthorpe wrote:
On Fri, Aug 23, 2019 at 03:17:53PM -0700, Ralph Campbell wrote:
Signed-off-by: Ralph Campbell
mm/hmm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/hmm.c b/mm/hmm.c
index 29371485fe94..4882b83aeccb 100644
+++ b/mm/hmm.c
@@ -292,6
On 8/26/19 11:09 AM, Jason Gunthorpe wrote:
On Mon, Aug 26, 2019 at 11:02:12AM -0700, Ralph Campbell wrote:
On 8/24/19 3:37 PM, Christoph Hellwig wrote:
On Fri, Aug 23, 2019 at 03:17:52PM -0700, Ralph Campbell wrote:
Although hmm_range_fault() calls find_vma() to make sure that a vma exists
On 8/24/19 3:37 PM, Christoph Hellwig wrote:
On Fri, Aug 23, 2019 at 03:17:52PM -0700, Ralph Campbell wrote:
Although hmm_range_fault() calls find_vma() to make sure that a vma exists
before calling walk_page_range(), hmm_vma_walk_hole() can still be called
with walk->vma == NULL if the st
returns -EBUSY */
/* returns -EBUSY */
/* loops on -EBUSY and range->valid */
Prevent this by checking for vma->vm_flags & VM_WRITE before calling
handle_mm_fault().
Signed-off-by: Ralph Campbell
---
mm/hmm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/hmm.
xes now since I thought they shouldn't wait.
They should probably have a fixes line but with all the HMM changes,
I wasn't sure exactly which commit to use.
These are based on top of Jason's latest hmm branch.
Ralph Campbell (2):
mm/hmm: hmm_range_fault() NULL pointer bug
mm/hmm: h
nge check */
walk_page_range() /* calls find_vma(), sets walk->vma = NULL */
__walk_page_range()
walk_pgd_range()
walk_p4d_range()
walk_pud_range()
hmm_vma_walk_hole()
hmm_vma_walk_hole_()
hmm_vma_do_fault()
handle_mm_fault(vma=0)
Signed-off-by:
On 8/16/19 10:28 AM, Jason Gunthorpe wrote:
On Fri, Aug 16, 2019 at 10:21:41AM -0700, Dan Williams wrote:
We can do a get_dev_pagemap inside the page_walk and touch the pgmap,
or we can do the 'device mutex && retry' pattern and touch the pgmap
in the driver, under that lock.
However in all c
/linux.git mmu_notifier branch.
So for the series you can add:
Tested-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
3 -
kernel/fork.c| 1 -
mm/hmm.c | 121 +++-
mm/mmu_notifier.c| 230 +--
25 files changed, 408 insertions(+), 559 deletions(-)
For the core
On 8/14/19 3:14 PM, Andrew Morton wrote:
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
nge code were overly cautious, drivers are
already not permitted to free the mirror while a range exists.
Signed-off-by: Jason Gunthorpe
Looks good.
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.fr
llwig
Signed-off-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
include/linux/mmu_notifier.h | 35
mm/mmu_notifier.c| 156 +--
2 files changed, 185 insertions(+), 6 deletions(-)
diff --git a
eterministic and we can use that to
decide if the allocation path is required, without speculation.
The actual update to mmu_notifier_mm must still be done under the
mm_take_all_locks() to ensure read-side coherency.
Signed-off-by: Jason Gunthorpe
Looks good to me.
Revi
to check that the callers are holding the lock
as expected.
Suggested-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
Nice clean up.
Reviewed-by: Ralph Campbell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
On 8/10/19 4:13 AM, Christoph Hellwig wrote:
On something vaguely related to this patch:
You use the NVIF_VMM_PFNMAP_V0_V* defines from nvif/if000c.h, which are
a little odd as we only ever set these bits, but they also don't seem
to appear to be in values that are directly fed to the hardware.
On 8/8/19 12:07 AM, Christoph Hellwig wrote:
On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote:
When memory is migrated to the GPU it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the
stoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 159 +++--
1 file changed, 40 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 21052a4aaf69..473195762974 1
-off-by: Ralph Campbell
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: "Jérôme Glisse"
Cc: Ben Skeggs
---
This patch is based on top of Christoph Hellwig's 9 patch series
https://lore.kernel.org/linux-mm/20190729234611.gc7...@redhat.com/T/#u
"turn the hmm migrate_vma upside dow
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
There isn't any good reason to pass callbacks to migrate_vma. Instead
we can just export the three steps done by this function to drivers and
let them sequence the operation without callbacks. This removes a lot
of boilerplate code as-is, and will a
On 7/29/19 10:51 PM, Christoph Hellwig wrote:
The pagewalk code already passes the value as the hmask parameter.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index f26d6abc4ed2..88b77a4a6a1e 1006
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
where it can be replaced with a simple boolean local variable.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
mm
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
No one ever checks this flag, and we could easily get that information
from the page if needed.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
include/linux/migrate.h
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
We don't use this flag anymore, so remove it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/migrate.h b/include/linux/migr
once and reuses it for each
subsequent chunk of work.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 185 -
1 file changed, 56 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_d
stoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 158 ++---
1 file changed, 39 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 21052a4aaf69..036e6c0
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor out the end of fencing logic from the two migration routines.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 33 --
1 file changed, 15 insertions
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor out the repeated device memory address calculation into
a helper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 42 +++---
1 file changed, 17 insertions
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
When we start a new batch of dma_map operations we need to reset dma_nr,
as we start filling a newly allocated array.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
1 file
will allow the drivers to drastically
improve code flow and error handling further on.
Signed-off-by: Christoph Hellwig
Except for a few white space errors ( and $),
looks OK.
Reviewed-by: Ralph Campbell
---
Documentation/vm/hmm.rst | 55 +-
drivers/gpu/drm/no
On 7/25/19 11:23 PM, Christoph Hellwig wrote:
Note: it seems like you've only CCed me on patches 2-7, but not on the
cover letter and patch 1. I'll try to find them later, but to make Ccs
useful they should normally cover the whole series.
Otherwise this looks fine to me:
Reviewed-by: Christo
On 7/24/19 6:14 PM, Jason Gunthorpe wrote:
On Tue, Jul 23, 2019 at 02:05:06PM -0700, Ralph Campbell wrote:
The hmm_mirror_ops callback function sync_cpu_device_pagetables() passes
a struct hmm_update which is a simplified version of struct
mmu_notifier_range. This is unnecessary so replace
1 - 100 of 154 matches
Mail list logo
