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 = migrate_vma(&nouveau_dmem_
On Wed, Jul 31, 2019 at 03:27:35PM +0530, Bharata B Rao wrote:
> > - kfree(fault->dma);
> > + return VM_FAULT_SIGBUS;
> Looks like nouveau_dmem_fault_copy_one() is now returning VM_FAULT_SIGBUS
> for success case. Is this expected?
No, fixed.
Hi Jérôme, Ben, Felix 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:
11 files changed, 94 insertions(+), 210 deletions(-)
A git tree is also available at:
git://git.infradead.org/us
The list is used to add the range to another list as an entry in the
core hmm code, and intended as a private member not exposed to drivers.
There is no need to initialize it in a driver.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Felix Kuehling
---
drivers/gpu
We'll need the nouveau_svmm structure to improve the function soon.
For now this allows using the svmm->mm reference to unlock the
mmap_sem, and thus the same dereference chain that the caller uses
to lock and unlock it.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouve
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
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
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
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
Reviewed-by: Jason Gunthorpe
Reviewed-by: Felix Kuehling
---
Documentation/vm/hmm.rst| 2 +-
drivers/gpu/drm/amd
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
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 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..03d37e102e3b 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -771,19
hmm_range_fault can only return -EAGAIN if called with the
HMM_FAULT_ALLOW_RETRY flag, which amdgpu never does. Remove the
handling for the -EAGAIN case with its non-standard locking scheme.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Felix Kuehling
---
drivers
There isn't really any architecture specific code in this page table
walk implementation, so drop the dependencies.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
mm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
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, 8 insertions(+), 10 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 5e7afe685213..4aa7135f1094
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
Reviewed-by: Jason Gunthorpe
---
mm/hmm.c | 8
1 file changed, 4 insertions(+), 4 dele
architectures when helpers like pud_pfn are not
implemented.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
mm/hmm.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 2083e4db46f5..5e7afe685213 100644
Make HMM_MIRROR an option that is selected by drivers wanting to use it
instead of a user visible option as it is just a low-level
implementation detail.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/Kconfig | 4 +++-
drivers/gpu/drm/nouveau/Kconfig| 4 +++-
mm/Kconfig
The option is just used to select HMM mirror support and has a very
confusing help text. Just pull in the HMM mirror code by default
instead.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/Kconfig | 2 ++
drivers/gpu/drm/amd/amdgpu/Kconfig | 10 --
drivers
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 sure
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
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:
5 files changed, 281 insertions(+), 607 de
code 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/migr
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
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
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
ction 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
---
drivers/gpu/drm/nouveau/nouveau_d
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
work.
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
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
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 Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote:
> Section alignment constraints somewhat save us here. The only example
> I can think of a PMD not containing a uniform pgmap association for
> each pte is the case when the pgmap overlaps normal dram, i.e. shares
> the same 'struct memo
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 de
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
code 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/migr
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
ction 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
---
dr
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
work.
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
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
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
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 a
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 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 fro
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 if
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 l
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 as we only
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 o
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
> > >> supp
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);
> +
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
; VM_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
> +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
Reviewed-by: Christoph Hellwig
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Looks good,
Reviewed-by: Christoph Hellwig
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
ifier_ops *ops)
Odd indentation - we usuall do two tabs (my preference) or align after
the opening brace.
> + * This function must be paired with mmu_interval_notifier_insert(). It
> cannot be
line > 80 chars.
Otherwise this looks good and very similar to what I reviewed earl
Looks good,
Reviewed-by: Christoph Hellwig
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Looks good:
Reviewed-by: Christoph Hellwig
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Thu, Nov 07, 2019 at 08:06:08PM +, Jason Gunthorpe wrote:
> >
> > enum mmu_range_notifier_event {
> > MMU_NOTIFY_RELEASE,
> > };
> >
> > ...assuming that we stay with "mmu_range_notifier" as a core name for this
> > whole thing.
> >
> > Also, it is best moved down to be next to the n
The name is weird, normally we call functions like this _locked.
Additionally it will need a lockdep_assert_held to ensure the caller
actually holds the lock.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li
On Tue, Mar 03, 2020 at 01:15:21PM -0800, Ralph Campbell wrote:
>>> +static inline struct nouveau_pfnmap_args *
>>> +nouveau_pfns_to_args(void *pfns)
>>
>> don't use static inline inside C files
>
> OK.
>
>>> +{
>>> + struct nvif_vmm_pfnmap_v0 *p =
>>> + container_of(pfns, struct nvif_v
Add a new opaque owner field to struct dev_pagemap, which will allow
the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
and refuse to work on mappings not owned by the calling entity.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 4
When acting on device private mappings a driver needs to know if the
device (or other entity in case of kvmppc) actually owns this private
mapping. This series adds an owner field and converts the migrate_vma
code over to check it. I looked into doing the same for
hmm_range_fault, but as far as I
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.
Signed-off-by: Christoph Hellwig
---
drivers/gpu
On Mon, Mar 16, 2020 at 03:17:07PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 16, 2020 at 06:52:58PM +0100, Christoph Hellwig wrote:
> > Add a new opaque owner field to struct dev_pagemap, which will allow
> > the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
&g
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 can tell
>> it neve
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 Mon, Mar 16, 2020 at 04:04:43PM -0300, Jason Gunthorpe wrote:
> > This is not actually true. OpenCL 2.x does support SVM with nouveau and
> > device private memory via clEnqueueSVMMigrateMem().
> > Also, Ben Skeggs has accepted a set of patches to map GPU memory after being
> > migrated and this
When acting on device private mappings a driver needs to know if the
device (or other entity in case of kvmppc) actually owns this private
mapping. This series adds an owner field and converts the migrate_vma
code over to check it. I looked into doing the same for
hmm_range_fault, but as far as I
Add a new opaque owner field to struct dev_pagemap, which will allow
the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
and refuse to work on mappings not owned by the calling entity.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 2 ++
drivers
Add a new src_owner field to struct migrate_vma. If the field is set,
only device private pages with page->pgmap->owner equal to that field
are migrated. If the field is not set only "normal" pages are migrated.
Signed-off-by: Christoph Hellwig
Fixes: df6ad69838fc ("mm
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-off-by: Christoph Hellwig
---
drivers/gpu/drm
owner in the hmm_range_fault structure.
Signed-off-by: Christoph Hellwig
Fixes: 4ef589dc9b10 ("mm/hmm/devmem: device memory hotplug using ZONE_DEVICE")
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 12
include/linux/hmm.h|
On Mon, Mar 16, 2020 at 04:59:23PM -0300, Jason Gunthorpe wrote:
> However, between patch 3 and 4 doesn't this break amd gpu as it will
> return device_private pages now if not requested? Squash the two?
No change in behavior in this patch as long as HMM_PFN_DEVICE_PRIVATE
isn't set in ->pfns or -
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 the
>> HMM_PFN_DEVIC
On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote:
> > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a driver
> > can
> > look at the struct page but what if a driver needs to fault in a page from
> > another device's private memory? Should it call handle_mm_faul
On Tue, Mar 17, 2020 at 01:24:45PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote:
> > > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a
> > > driver can
> > > look at the struct page but what i
On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
> I've been using v7 of Ralph's tester and it is working well - it has
> DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
> you able?
>
> This hunk seems trivial enough to me, can we include it now?
I can send
On Fri, Mar 13, 2020 at 06:22:58PM -0400, Mikel Rychliski wrote:
> /**
> + * pci_platform_rom - ioremap() the ROM image provided by the platform
> * @pdev: pointer to pci device struct
> * @size: pointer to receive size of pci window over ROM
> + *
> + * Return: kernel virtual pointer to image
On Tue, Mar 17, 2020 at 09:34:33PM -0400, Mikel Rychliski wrote:
> I think the direct access to pdev->rom you suggest makes sense, especially
> because users of the pci_platform_rom() are exposed to the fact that it just
> calls ioremap().
>
> I decided against wrapping the iounmap() with a pci_
On Tue, Mar 17, 2020 at 03:43:47PM -0700, Ralph Campbell wrote:
>> Obviously no driver cared for that so far. Once we have test cases
>> for that and thus testable code we can add code to fault it in from
>> hmm_vma_handle_pte.
>>
>
> I'm OK with the series. I think I would have been less confused
On Wed, Mar 18, 2020 at 09:28:49PM -0300, Jason Gunthorpe wrote:
> > Changes since v1:
> > - split out the pgmap->owner addition into a separate patch
> > - check pgmap->owner is set for device private mappings
> > - rename the dev_private_owner field in struct migrate_vma to src_owner
> > - re
On Thu, Mar 19, 2020 at 09:03:45PM -0300, Jason Gunthorpe wrote:
> > Should tests enable the feature or the feature enable the test?
> > IMHO, if the feature is being compiled into the kernel, that should
> > enable the menu item for the test. If the feature isn't selected,
> > no need to test it :
On Fri, Mar 20, 2020 at 10:41:09AM -0300, Jason Gunthorpe wrote:
> Thinking about this some more, does the locking work out here?
>
> hmm_range_fault() runs with mmap_sem in read, and does not lock any of
> the page table levels.
>
> So it relies on accessing stale pte data being safe, and here w
On Sat, Mar 21, 2020 at 09:38:04AM -0300, Jason Gunthorpe wrote:
> > I don't think there is any specific protection. Let me see if we
> > can throw in a get_dev_pagemap here
>
> The page tables are RCU protected right? could we do something like
>
> if (is_device_private_entry()) {
>rcu
Currently all drivers provide a feature kconfig that will disable use of
> DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if
> they don't want the overhead.
>
> Signed-off-by: Jason Gunthorpe
Looks good,
Reviewed-by: Christoph Hellwig
_
the superflous inner braces here.
> + * Return: 0 or -ERRNO with one of the following status codes:
Maybe say something like:
* Returns 0 on success or one of the following error codes:
Otherwise this looks good:
Reviewed-by: Christoph Hellwig
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Tue, Apr 21, 2020 at 09:21:45PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
> because of a special page vs any other error case.
Looks good,
Reviewed-by: Chris
On Tue, Apr 21, 2020 at 09:21:46PM -0300, Jason Gunthorpe wrote:
> +void nouveau_hmm_convert_pfn(struct nouveau_drm *drm, struct hmm_range
> *range,
> + u64 *ioctl_addr)
> {
> unsigned long i, npages;
>
> + /*
> + * The ioctl_addr prepared here is pass
On Wed, Apr 22, 2020 at 09:39:11AM -0300, Jason Gunthorpe wrote:
> > Nice callchain from hell.. Unfortunately such "code listings" tend to
> > get out of date very quickly, so I'm not sure it is worth keeping in
> > the code. What would be really worthile is consolidating the two
> > different se
Looks good,
Reviewed-by: Christoph Hellwig
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
The series seems to miss a cover letter.
Also I really think this patch original patch shouldn't be in the proper
series.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Wed, Apr 25, 2018 at 11:25:11AM +0100, Russell King - ARM Linux wrote:
> > config ARM_DMA_USE_IOMMU
> > - bool
> > + def_bool y
> > select ARM_HAS_SG_CHAIN
> > select NEED_SG_DMA_LENGTH
>
> This doesn't work - as has recently been discussed with hch, we can't
> globally enable NEED
On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The dma_iommu_detach_device() API can be used by drivers to forcibly
> detach a device from an IOMMU that architecture code might have attached
> to. This is useful for drivers that need explicit control ov
> +void arch_iommu_detach_device(struct device *dev)
> +{
> +#ifdef CONFIG_ARM_DMA_USE_IOMMU
> + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> + const struct dma_map_ops *dma_ops;
> +
> + if (!mapping)
> + return;
> +
> + arm_iommu_release_mapping(mapp
}
> +#endif
Having this hidden in a helper would be nicer, but anything that
doesn't directly expose the dma_map_ops to a driver is fine with me.
So from the dma-mapping POV:
Acked-by: Christoph Hellwig
___
Nouveau mailing list
Nou
401 - 500 of 519 matches
Mail list logo
