There isn't really much value add in the hmm_devmem_add wrapper and
more, as using devm_memremap_pages directly now is just as simple.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 26
include/linux/hmm.h | 129
The migrate_vma helper is only used by noveau to migrate device private
pages around. Other HMM_MIRROR users like amdgpu or infiniband don't
need it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/Kconfig | 1 +
mm/Kconfig | 1
hmm_vma_alloc_locked_page is scheduled to go away, use the proper
mm function directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau
The ZONE_DEVICE support doesn't depend on anything HMM related, just on
various bits of arch support as indicated by the architecture. Also
don't select the option from nouveau as it isn't present in many setups,
and depend on it instead.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm
On Fri, Jul 05, 2019 at 09:33:36AM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 03, 2019 at 03:02:08PM -0700, Christoph Hellwig wrote:
> > Hi Jérôme, Ben and Jason,
> >
> > below is a series against the hmm tree which fixes up the mmap_sem
> > locking in nouveau a
On Wed, Jul 03, 2019 at 03:01:25PM -0300, Jason Gunthorpe wrote:
> Christoph, I guess you didn't mean to send this branch to the mailing
> list?
>
> In any event some of these, like this one, look obvious and I could
> still grab a few for hmm.git.
>
> Let me know what you'd like please
>
>
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
Checking range->valid is trivial and has no meaningful cost, but
nicely simplifies the fastpath in typical callers. Also remove the
hmm_vma_range_done function, which now is a trivial wrapper around
hmm_range_unregister.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
driv
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index e831f4184a17..c0cf7aeaefb3 100644
--- a/drivers/gpu
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 34 --
2 files
hmm_vma_fault is marked as a legacy API to get rid of, but seems to suit
the current nouveau flow. Move it to the only user in preparation for
fixing a locking bug involving caller and callee.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which fixes up the mmap_sem
locking in nouveau and while at it also removes leftover legacy HMM APIs
only used by nouveau.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
On Wed, Jul 03, 2019 at 03:03:56PM -0300, Jason Gunthorpe wrote:
> I was thinking about doing exactly this too, but amdgpu started using
> this already obsolete API in their latest driver :(
>
> So, we now need to get both drivers to move to the modern API.
Actually the AMD folks fixed this up
On Wed, Jul 03, 2019 at 07:00:50PM +, Jason Gunthorpe wrote:
> I don't think the API should be encouraging some shortcut here..
>
> We can't do the above pattern because the old hmm_vma API didn't allow
> it, which is presumably a reason why it is obsolete.
>
> I'd rather see drivers move to
wrong and simpler.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index b9ced2e61667..a5d9b537cbaf 100644
On Wed, Jul 03, 2019 at 01:46:02PM -0700, Ralph Campbell wrote:
> You can delete the comment "With the old API the driver must ..."
> (not visible in the patch here).
Sure.
> I suggest moving the two assignments:
> range->default_flags = 0;
> range->pfn_flags_mask = -1UL;
> to just
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 9a9f71e4be29..d97d862e8b7d 100644
--- a/drivers/gpu/drm
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which fixes up the mmap_sem
locking in nouveau and while at it also removes leftover legacy HMM APIs
only used by nouveau.
Changes since v1:
- don't return the valid state from hmm_range_unregister
- additional nouveau cleanups
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 34
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 52 +-
include/linux/hmm.h | 63 ---
2 files changed, 50 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm
-EAGAIN has a magic meaning for non-blocking faults, so don't overload
it. Given that the caller doesn't check for specific error codes this
change is purely cosmetic.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
The parameter is always false, so remove it as well as the -EAGAIN
handling that can only happen for the non-blocking case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
On Tue, Jul 02, 2019 at 10:45:34PM +, Weiny, Ira wrote:
> >
> > On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > > And I've demonstrated that I can't send patch series.. While this has
> > > all the right patches, it also has the extra pa
And I've demonstrated that I can't send patch series.. While this
has all the right patches, it also has the extra patches already
in the hmm tree, and four extra patches I wanted to send once
this series is merged. I'll give up for now, please use the git
url for anything serious, as it
On Wed, Jun 26, 2019 at 12:04:46PM -0700, Ira Weiny wrote:
> > +static int devmap_managed_enable_get(struct device *dev, struct
> > dev_pagemap *pgmap)
> > +{
> > + if (!pgmap->ops->page_free) {
>
> NIT: later on you add the check for pgmap->ops... it should probably be here.
>
> But not
On Wed, Jun 26, 2019 at 02:47:50PM -0700, Ira Weiny wrote:
> > +
> > + init_completion(>done);
> > + error = percpu_ref_init(>internal_ref,
> > + dev_pagemap_percpu_release, 0, GFP_KERNEL);
> > + if (error)
> > + return
On Fri, Jun 28, 2019 at 11:44:35AM -0700, Dan Williams wrote:
> There is a problem with the series in CH's tree. It removes the
> ->page_free() callback from the release_pages() path because it goes
> too far and removes the put_devmap_managed_page() call.
release_pages only called
On Fri, Jun 28, 2019 at 11:59:19AM -0700, Dan Williams wrote:
> It's a bug that the call to put_devmap_managed_page() was gated by
> MEMORY_DEVICE_PUBLIC in release_pages(). That path is also applicable
> to MEMORY_DEVICE_FSDAX because it needs to trigger the ->page_free()
> callback to wake up
be valid as part of a registered mirror so all we
need in hmm_register_range() is a simple kref_get.
Suggested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Reviewed-by: Ira Weiny
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
wed-by: Ira Weiny
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
mm/hmm.c | 77 ++--
1 file changed, 30 insertions(+), 47 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 080b17a2e87e..0423f4ca3a7e 100644
--- a/mm/hmm.c
+++ b/mm/hm
From: Ralph Campbell
Update the HMM documentation to reflect the latest API and make a few
minor wording changes.
Cc: John Hubbard
Cc: Ira Weiny
Cc: Dan Williams
Cc: Arnd Bergmann
Cc: Balbir Singh
Cc: Dan Carpenter
Cc: Matthew Wilcox
Cc: Souptick Joarder
Cc: Andrew Morton
ely.
Signed-off-by: Jason Gunthorpe
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 26 --
mm/hmm.c| 32 +++-
2 files changed, 11 insertions(+),
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ira Weiny
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 1 +
mm/hmm.c| 23 +--
2 files changed, 18 insertions(+), 6 deletions(-)
wed-by: Ira Weiny
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
mm/hmm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 0423f4ca3a7e..73c8af4827fe 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -912,7 +912,7 @@ int hmm_range_register(str
From: Ralph Campbell
There are no functional changes, just some coding style clean ups and
minor comment changes.
Cc: John Hubbard
Cc: Ira Weiny
Cc: Dan Williams
Cc: Arnd Bergmann
Cc: Balbir Singh
Cc: Dan Carpenter
Cc: Matthew Wilcox
Cc: Souptick Joarder
Cc: Andrew Morton
Checking range->valid is trivial and has no meaningful cost, but
nicely simplifies the fastpath in typical callers. Also remove the
hmm_vma_range_done function, which now is a trivial wrapper around
hmm_range_unregister.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouv
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 8 +++-
1
From: Jason Gunthorpe
Trying to misuse a range outside its lifetime is a kernel bug. Use poison
bytes to help detect this condition. Double unregister will reliably crash.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
Reviewed-by: John Hubbard
Acked-by: Souptick Joarder
() (along with its internal
barriers) to compute the result of the function.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
Reviewed-by: John Hubbard
Reviewed-by: Ira Weiny
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 13 ++---
1 file c
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index e831f4184a17..c0cf7aeaefb3 100644
--- a/drivers/gpu
From: Jason Gunthorpe
So we can check locking at runtime.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Acked-by: Souptick Joarder
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
mm/hmm.c | 4 ++--
1 file
From: Philip Yang
While the page is migrating by NUMA balancing, HMM failed to detect this
condition and still return the old page. Application will use the new page
migrated, but driver pass the old page physical address to GPU, this crash
the application later.
Use pte_protnone(pte) to return
off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 2 +-
mm/hmm.c| 69 ++---
2 files changed, 41 insertions(+), 30 deletions(-)
diff --git a/include/linux/hmm.
The only user we have today for ops->release is an empty function, so this
is unambiguously safe.
As a consequence of plugging this race drivers are not allowed to
register/unregister mirrors from within a release op.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Christoph Hellwig
Tested-by: Philip
Hi Dan, Jérôme and Jason,
below is a series that cleans up the dev_pagemap interface so that
it is more easily usable, which removes the need to wrap it in hmm
and thus allowing to kill a lot of code
Note: this series is on top of Linux 5.2-rc6 and has some minor
conflicts with the hmm tree that
From: Jason Gunthorpe
gcc reports that several variables are defined but not used.
For the first hunk CONFIG_HUGETLB_PAGE the entire if block is already
protected by pud_huge() which is forced to 0. None of the stuff under the
ifdef causes compilation problems as it is already stubbed out in
ete the hmm_hmm_destroy().
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Reviewed-by: Ira Weiny
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 3 ---
kernel/fork.c | 1 -
mm/hm
From: "Kuehling, Felix"
Don't set this flag by default in hmm_vma_do_fault. It is set
conditionally just a few lines below. Setting it unconditionally can lead
to handle_mm_fault doing a non-blocking fault, returning -EBUSY and
unlocking mmap_sem unexpectedly.
Signed-off-by: Felix Kuehling
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 36 --
2 files changed, 1 insertion(+), 37
hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
the current nouvea flow. Move it to the only user in preparation for
fixing a locking bug involving caller and callee.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 54
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
mm/hmm.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 6f5dc6d568fe..2ef14b2b5505 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -276,17
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 changed, 1 insertion(+)
diff --git a/drivers/gpu/drm
flow and error handling further on.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
Documentation/vm/hmm.rst | 55 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 122 +++--
include/linux/migrate.h| 118 ++--
mm/migrate.c
makes it relatively easy to add multi page
support back if needed in the future. But at least for now this avoid
the needed to dynamically allocate memory for the dma addresses in
what is essentially the page fault path.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers
CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper
devic private memory support. Remove the option and just check for
CONFIG_DEVICE_PRIVATE instead.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/Kconfig | 1 -
mm/Kconfig | 3 ---
mm
nouveau_dmem_migrate_vma and nouveau_dmem_convert_pfn are only called
when CONFIG_DRM_NOUVEAU_SVM is enabled, so there is no need to provide
!CONFIG_DRM_NOUVEAU_SVM stubs for them.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.h | 11 ---
1 file changed, 11
.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 184 -
1 file changed, 55 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index
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(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
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(+), 25 deletions(-)
diff --git a/drivers/gpu/drm
Now that we can rely errors in the normal control flow there is no
need for this flag, 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/migrate.h
index
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| 1 -
mm/migrate.c
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which starts revamping the
migrate_vma functionality. The prime idea is to export three slightly
lower level functions and thus avoid the need for migrate_vma_ops
callbacks.
Diffstat:
7 files changed, 282 insertions(+), 614
There isn't really any architecture specific code in this page table
walk implementation, so drop the dependencies.
Signed-off-by: Christoph Hellwig
---
mm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 56cec636a1fc..b18782be969c
Stub out the whole function when CONFIG_TRANSPARENT_HUGEPAGE is not set
to make the function easier to read.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 4d3bd41b6522..f4e90ea5779f
pte_index is an internal arch helper in various architectures,
without consistent semantics. Open code that calculation of a PMD
index based on the virtual address instead.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm
The start, end and page_shift values are all saved in the range
structure, so we might as well use that for argument passing.
Signed-off-by: Christoph Hellwig
---
Documentation/vm/hmm.rst| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +--
drivers/gpu/drm/nouveau
All users pass PAGE_SIZE here, and if we wanted to support single
entries for huge pages we should really just add a HMM_FAULT_HUGEPAGE
flag instead that uses the huge page size instead of having the
caller calculate that size once, just for the hmm code to verify it.
Signed-off-by: Christoph
The list is used to add the range to another list as an entry in the
core hmm code, so there is no need to initialize it in a driver.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu
Signed-off-by: Christoph Hellwig
---
include/linux/hmm.h | 1 -
mm/hmm.c| 2 --
2 files changed, 3 deletions(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 82265118d94a..59be0aa2476d 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -422,7 +422,6 @@ long
Hi Jérôme, Ben, Felxi and Jason,
below is a series against the hmm tree which cleans up various minor
bits and allows HMM_MIRROR to be built on all architectures.
Diffstat:
7 files changed, 81 insertions(+), 171 deletions(-)
A git tree is also available at:
architectures when helpers like pud_pfn are not
implemented.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index e63ab7f11334..4d3bd41b6522 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
There is only a single place where the pgmap is passed over a function
call, so replace it with local variables in the places where we deal
with the pgmap.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 62
1 file changed, 27 insertions
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 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -771,19
Stub out the whole function and assign NULL to the .hugetlb_entry method
if CONFIG_HUGETLB_PAGE is not set, as the method won't ever be called in
that case.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/hmm.c b/mm
hmm_range_fault can only return -EAGAIN if called with the block
argument set to false, so remove the special handling for it.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git
This avoid having to abuse the vma field in struct hmm_range to unlock
the mmap_sem.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm
On Mon, Jul 29, 2019 at 07:30:44PM -0400, Jerome Glisse wrote:
> On Mon, Jul 29, 2019 at 05:28:43PM +0300, 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.
>
On Fri, Aug 16, 2019 at 12:30:41PM +, Jason Gunthorpe wrote:
>
> For instance, a system may have multiple DEVICE_PRIVATE map's owned by
> the same driver - but multiple physical devices using that driver.
>
> Each physical device's driver should only ever get DEVICE_PRIVATE
> pages for it's
On Fri, Aug 16, 2019 at 05:11:07PM +, Jason Gunthorpe wrote:
> - if (args->cpages)
> - migrate_vma_prepare(args);
> - if (args->cpages)
> - migrate_vma_unmap(args);
> + if (!args->cpages)
> + return 0;
> +
> + migrate_vma_prepare(args);
> +
On Wed, Aug 14, 2019 at 05:09:54PM -0700, Ralph Campbell wrote:
> Some of the patches seem to have been mangled in the mail.
Weird, I never had such a an issue with git-send-email.
But to be covered for such weird cases I also posted a git url
for exactly the tree I've been working on.
> I was
On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote:
> > Hello
> >
> > Since lot of release (at least since 4.19), I hit the following error
> > message:
> > DMA-API: cacheline tracking ENOMEM, dma-debug disabled
> >
>
On Fri, Aug 16, 2019 at 12:43:07AM +, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote:
>
> > struct page. In this case any way we can update the
> > nouveau_dmem_page() to check that page page->pgmap == the
> > expected pgmap.
>
> I was also wondering
On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> So nor HMM nor driver should dereference the struct page (i do not
> think any iommu driver would either),
Both current hmm drivers convert the hmm pfn back to a page and
eventually call dma_map_page on it. As do the ODP patches
Jason,
are you going to look into picking this up? Unfortunately there is
a hole pile in this area still pending, including the kvmppc secure
memory driver from Bharata that depends on the work.
mm folks: migrate.c is mostly a classic MM file except for the hmm
additions. Do you want to also
On Mon, Aug 12, 2019 at 12:42:30PM -0700, Ralph Campbell wrote:
>
> 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
Thanks, I've added the fixups for v3.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Thu, Aug 08, 2019 at 02:29:34PM -0700, Ralph Campbell wrote:
>>> {
>>> struct nouveau_fence *fence;
>>> unsigned long addr = args->start, nr_dma = 0, i;
>>> for (i = 0; addr < args->end; i++) {
>>> args->dst[i] = nouveau_dmem_migrate_copy_one(drm, args->vma,
On Sat, Aug 17, 2019 at 11:05:36AM +1000, Ben Skeggs wrote:
> > >> constants with similar names and identical values, and those are used
> > >> in mmu/vmmgp100.c and what appears to finally do the low-level dma
> > >> mapping and talking to the hardware. Are these two sets of constants
> > >>
WRITE before calling
> handle_mm_fault().
>
> Signed-off-by: Ralph Campbell
Looks good,
Reviewed-by: Christoph Hellwig
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
ned
> within the vma range.
Should we convert to walk_vma_range instead? Or keep walk_page_range
but drop searching the vma ourselves?
Except for that the patch looks good to me:
Reviewed-by: Christoph Hellwig
> +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.:
static int hmm_pfns_fill(unsigned long addr,
MAing a zero page.
>
> Signed-off-by: Ralph Campbell
> Cc: "Jérôme Glisse"
> Cc: Jason Gunthorpe
> Cc: Christoph Hellwig
> ---
> mm/hmm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 06041d4399ff
On Tue, Jul 30, 2019 at 12:55:17PM +, Jason Gunthorpe wrote:
> I suspect this was added for the ODP conversion that does use both
> page sizes. I think the ODP code for this is kind of broken, but I
> haven't delved into that..
>
> The challenge is that the driver needs to know what page size
On Tue, Jul 30, 2019 at 01:14:58PM +, Jason Gunthorpe wrote:
> I have a patch deleting hmm->mm, so using svmm seems cleaner churn
> here, we could defer and I can fold this into that patch?
Sounds good. If I don't need to resend feel fee to fold it, otherwise
I'll fix it up.
On Tue, Jul 30, 2019 at 12:35:59PM +, Jason Gunthorpe wrote:
> On Tue, Jul 30, 2019 at 08:51:53AM +0300, Christoph Hellwig wrote:
> > This avoid having to abuse the vma field in struct hmm_range to unlock
> > the mmap_sem.
>
> I think the change inside hmm_range_fau
On Tue, Jul 30, 2019 at 12:32:24PM +, Jason Gunthorpe wrote:
> Does this only impact hmm users, or does migrate.c have a broader
> usage?
migrate.c really contains two things: the traditional page migration
code implementing aops ->migrate semantics, and migrate_vma and its
callbacks. The
On Wed, Aug 07, 2019 at 11:47:22AM -0700, Dan Williams wrote:
> > Unrelated to this patch, but what is the point of getting checking
> > that the pgmap exists for the page and then immediately releasing it?
> > This code has this pattern in several places.
> >
> > It feels racy
>
> Agree, not
s the source CPU page table entries. This preserves copy on write
> semantics.
>
> Signed-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
On Tue, Jul 30, 2019 at 06:46:25PM -0700, Ralph Campbell wrote:
>> for (i = 0; i < npages; i += c) {
>> -unsigned long next;
>> -
>> c = min(SG_MAX_SINGLE_ALLOC, npages);
>> -next = start + (c << PAGE_SHIFT);
>> -ret =
101 - 200 of 514 matches
Mail list logo
