On Tue, Mar 11, 2025 at 01:12:14PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 7 Mar 2025 12:29:54 +1100 Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the drm-xe tree got a conflict in:
> >
> > mm/memory.c
> >
> > between commit:
> >
> > 089b22f60
On Thu, Mar 06, 2025 at 03:42:29PM +1100, Balbir Singh wrote:
> Add routines to support allocation of large order zone device folios
> and helper functions for zone device folios, to check if a folio is
> device private and helpers for setting zone device data.
>
> When large folios are used, the
On Thu, Mar 06, 2025 at 03:42:35PM +1100, Balbir Singh wrote:
> When a zone device page is split (via huge pmd folio split). The
> driver callback for folio_split is invoked to let the device driver
> know that the folio size has been split into a smaller order.
>
> The HMM test driver has been up
On Wed, Mar 05, 2025 at 05:26:57PM -0800, Matthew Brost wrote:
> Add documentation for agree upon GPU SVM design principles, current
> status, and future plans.
One minor nit and a comment below, but feel free to add:
Acked-by: Alistair Popple
> v4:
> - Address Thomas's feed
On Thu, Feb 27, 2025 at 08:36:35PM -0800, Matthew Brost wrote:
> On Fri, Feb 28, 2025 at 01:34:42PM +1100, Alistair Popple wrote:
> > On Mon, Feb 24, 2025 at 08:43:11PM -0800, Matthew Brost wrote:
> > > Add documentation for agree upon GPU SVM design principles, current
> &
On Mon, Feb 24, 2025 at 08:43:11PM -0800, Matthew Brost wrote:
> Add documentation for agree upon GPU SVM design principles, current
> status, and future plans.
Thanks for writing this up. In general I didn't see anything too controversial
but added a couple of comments below.
>
> v4:
> - Addre
On Tue, Feb 18, 2025 at 10:08:31PM -0800, Matthew Brost wrote:
> On Wed, Feb 19, 2025 at 04:36:54PM +1100, Alistair Popple wrote:
> > On Wed, Feb 12, 2025 at 06:10:43PM -0800, Matthew Brost wrote:
> > > Avoid multiple CPU page faults to the same device page racing by trying
>
could occur in Xe's (Intel GPU
> DRM driver) SVM implementation if enough threads faulted the same device
> page.
>
> v3:
> - Put page after unlocking page (Alistair)
> - Warn on spliting a TPH which is fault page (Alistair)
> - Warn on dst page == fault page (Alista
On Tue, Feb 11, 2025 at 09:33:54AM +0100, David Hildenbrand wrote:
> On 11.02.25 06:00, Andrew Morton wrote:
> > On Mon, 10 Feb 2025 20:37:45 +0100 David Hildenbrand
> > wrote:
> >
> > > The single "real" user in the tree of make_device_exclusive_range() always
> > > requests making only a singl
On Thu, Feb 13, 2025 at 12:15:58PM +0100, David Hildenbrand wrote:
> On 13.02.25 12:03, Alistair Popple wrote:
> > On Mon, Feb 10, 2025 at 08:37:42PM +0100, David Hildenbrand wrote:
> > > Against mm-hotfixes-stable for now.
> > >
> > > Discussing the PageTail()
mp;cmd);
> if (ret) {
> perror("ioctl failed\n");
> exit(1);
> }
> }
> pause();
> return 0;
> }
>
>
> [1] https://lkml.kernel.org/r/25e02685-4f1d-47fa-be5b-01ff
On Thu, Feb 13, 2025 at 12:33:21AM +, Benno Lossin wrote:
> On 13.02.25 00:27, Alistair Popple wrote:
> > On Sun, Feb 09, 2025 at 06:30:25PM +0100, Danilo Krummrich wrote:
> >
> > [...]
> >
> >> +FromPrimitive API
> >> +-
> &
On Sun, Feb 09, 2025 at 06:30:25PM +0100, Danilo Krummrich wrote:
[...]
> +FromPrimitive API
> +-
> +
> +Sometimes the need arises to convert a number to a value of an enum or a
> +structure.
> +
> +A good example from nova-core would be the ``Chipset`` enum type, which
> defines
On Fri, Jan 24, 2025 at 07:15:24PM +0100, David Hildenbrand wrote:
> ret will be modified immediately afterwards.
Yep. Thanks for fixing.
Reviewed-by: Alistair Popple
> Signed-off-by: David Hildenbrand
> ---
> drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
> 1 file changed, 1
d the change looks good so
please add:
Reviewed-by: Alistair Popple
Tested-by: Alistair Popple
> Fixes: 8f187163eb89 ("nouveau/svm: implement atomic SVM access")
> Signed-off-by: David Hildenbrand
> ---
> drivers/gpu/drm/nouveau/nouveau_svm.c | 9 +++--
> 1 f
date commit message with why this is required (Alistar)
Thanks! Looks good to me now so:
Reviewed-by: Alistair Popple
> Cc: Andrew Morton
> Signed-off-by: Matthew Brost
> ---
> include/linux/migrate.h | 1 +
> mm/migrate_device.c | 52 +
On Thu, Jan 30, 2025 at 04:57:39PM +1100, Alistair Popple wrote:
> On Wed, Jan 29, 2025 at 12:54:01PM +0100, David Hildenbrand wrote:
[...]
> > -int make_device_exclusive_range(struct mm_struct *mm, unsigned long start,
> > - unsigned long end, stru
On Thu, Jan 30, 2025 at 11:43:25AM +0100, Simona Vetter wrote:
> On Thu, Jan 30, 2025 at 11:27:37AM +1100, Alistair Popple wrote:
> > On Wed, Jan 29, 2025 at 12:58:02PM +0100, David Hildenbrand wrote:
> > > Let's document how this function is to be used, and why the requirem
On Thu, Jan 30, 2025 at 04:29:33PM +0100, David Hildenbrand wrote:
> On 30.01.25 14:31, Simona Vetter wrote:
> > On Thu, Jan 30, 2025 at 10:37:06AM +0100, David Hildenbrand wrote:
> > > On 30.01.25 01:27, Alistair Popple wrote:
> > > > On Wed, Jan 29, 2025 at 12:58
viously went too
far. So thanks for fixing:
Reviewed-by: Alistair Popple
> Likely we'll never really trigger that case in practice, because
> migration (including folio split) of a folio that has device-private
> entries is never started, as we would detect "additional re
if (pte_swp_soft_dirty(oldpte))
> - newpte = pte_swp_mksoft_dirty(newpte);
> - if (pte_swp_uffd_wp(oldpte))
> - newpte = pte_swp_mkuffd_wp(newpte);
So just to check my understanding the idea
On Thu, Jan 30, 2025 at 02:03:42PM +0100, Simona Vetter wrote:
> On Thu, Jan 30, 2025 at 10:58:51AM +0100, David Hildenbrand wrote:
> > On 30.01.25 10:51, Simona Vetter wrote:
> > > On Wed, Jan 29, 2025 at 12:54:03PM +0100, David Hildenbrand wrote:
> > > > Let's do it just like mprotect write-upgra
On Thu, Jan 30, 2025 at 10:24:37AM +0100, David Hildenbrand wrote:
> On 30.01.25 10:01, David Hildenbrand wrote:
> > On 30.01.25 07:11, Alistair Popple wrote:
> > > On Wed, Jan 29, 2025 at 12:54:02PM +0100, David Hildenbrand wrote:
> > > > We require a writable PTE an
On Wed, Jan 29, 2025 at 12:54:02PM +0100, David Hildenbrand wrote:
> We require a writable PTE and only support anonymous folio: we can only
> have exactly one PTE pointing at that page, which we can just lookup
> using a folio walk, avoiding the rmap walk and the anon VMA lock.
>
> So let's stop
mmap_read_unlock(mm);
> mmput(mm);
>
> + if (ret)
> + return -EBUSY;
> +
> /* Return the migrated data for verification. */
> ret = dmirror_bounce_init(&bounce, start, size);
> if (ret)
> diff --git a/mm/rmap.c b/mm/rmap.c
>
clusive_one() is
> not really prepared for handling them at all. So let's spell that out.
Agreed, thanks for fixing.
Reviewed-by: Alistair Popple
> Fixes: b756a3b5e7ea ("mm: device exclusive memory access")
> Cc:
> Signed-off-by: David Hildenbrand
> ---
> mm/rmap.
called on a hugetlb vma there either.
Reviewed-by: Alistair Popple
> [ 207.017134][T14945] [ cut here ]
> [ 207.018614][T14945] kernel BUG at mm/page_table_check.c:87!
> [ 207.019716][T14945] Oops: invalid opcode: [#1] PREEMPT SMP KASAN NO
>
> While at it, just avoid the "swp_entry_t entry" variable in
> try_restore_exclusive_pte() and add a folio-locked check to
> restore_exclusive_pte().
Seems reasonable.
Reviewed-by: Alistair Popple
> Signed-off-by: David Hildenbrand
> ---
> mm/memory.c | 29
On Wed, Jan 29, 2025 at 12:58:00PM +0100, David Hildenbrand wrote:
> We no longer get a MMU_NOTIFY_EXCLUSIVE on conversion with the owner set
> that one has to filter out: if there already *is* a device-exclusive
> entry (e.g., other device, we don't have that information), GUP will
> convert it ba
On Wed, Jan 29, 2025 at 12:57:59PM +0100, David Hildenbrand wrote:
> The caller now always passes a single page; let's simplify, and return
> "0" on success.
Thanks for cleaning that up.
Reviewed-by: Alistair Popple
> Signed-off-by: David Hildenbrand
>
On Wed, Jan 29, 2025 at 12:58:02PM +0100, David Hildenbrand wrote:
> Let's document how this function is to be used, and why the requirement
> for the folio lock might maybe be dropped in the future.
Sorry, only just catching up on your other thread. The folio lock was to ensure
the GPU got a chan
NTNEED on the PTE we just converted might be able
> to trigger it.
I have this setup so will certainly test it and see if I can trigger the bug
as well. Thanks for the fixes.
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: Danilo Krummrich
> Cc: David Airlie
> Cc: Simona Vet
On Fri, Jan 24, 2025 at 06:54:02PM +0100, David Hildenbrand wrote:
> > > > On integrated the gpu is tied into the coherency
> > > > fabric, so there it's not needed.
> > > >
> > > > I think the more fundamental question with both this function here and
> > > > with forced migration to device memor
Matthew Brost writes:
[...]
> + * 3) Invalidation driver vfunc.
> + *
> + * void driver_invalidation(struct drm_gpusvm *gpusvm,
> + *struct drm_gpusvm_notifier *notifier,
> + *const struct mmu_notifier_range *mmu_range)
> + * {
> + *
Matthew Brost writes:
> Avoid multiple CPU page faults to the same device page racing by trying
> to lock the page in do_swap_page before taking an extra reference to the
> page. This prevents scenarios where multiple CPU page faults each take
> an extra reference to a device page, which could
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 12:51:08PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Wed, Oct 16, 2024 at 03:00:08PM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> &
Matthew Brost writes:
> On Fri, Oct 18, 2024 at 04:59:05PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Fri, Oct 18, 2024 at 08:58:02AM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> &g
Matthew Brost writes:
> On Fri, Oct 18, 2024 at 08:58:02AM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> &g
Mika Penttilä writes:
> Hi,
>
> On 10/18/24 00:58, Alistair Popple wrote:
>> Matthew Brost writes:
>>
>>> On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
>>>> Matthew Brost writes:
>>>>
>>>>> On Thu, Oc
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 04:49:11PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> &g
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> &
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew Brost wrote:
>> >> On Wed, Oct 16, 2024
Jason Gunthorpe writes:
> On Wed, Oct 16, 2024 at 04:10:53PM +1100, Alistair Popple wrote:
>> On that note how is the refcounting of the returned p2pdma page expected
>> to work? We don't want the driver calling hmm_range_fault() to be able
>> to pin the page w
Matthew Brost writes:
> On Wed, Oct 16, 2024 at 03:00:08PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > Avoid multiple CPU page faults to the same device page racing by trying
>> > to lock the page in do_swap_page before taking an
Matthew Brost writes:
> On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew Brost wrote:
>> On Wed, Oct 16, 2024 at 03:04:06PM +1100, Alistair Popple wrote:
[...]
>> > > +{
>> > > +unsigned long i;
>> > > +
>> > > +for
Yonatan Maman writes:
> On 16/10/2024 7:23, Christoph Hellwig wrote:
>> On Tue, Oct 15, 2024 at 06:23:44PM +0300, Yonatan Maman wrote:
>>> From: Yonatan Maman
>>>
>>> This patch series aims to enable Peer-to-Peer (P2P) DMA access in
>>> GPU-centric applications that utilize RDMA and private de
Yonatan Maman writes:
> From: Yonatan Maman
>
> Enabling Peer-to-Peer DMA (P2P DMA) access in GPU-centric applications
> is crucial for minimizing data transfer overhead (e.g., for RDMA use-
> case).
>
> This change aims to enable that capability for Nouveau over HMM device
> private pages. P2
Yonatan Maman writes:
> From: Yonatan Maman
>
> hmm_range_fault() natively triggers a page fault on device private
> pages, migrating them to RAM. In some cases, such as with RDMA devices,
> the migration overhead between the device (e.g., GPU) and the CPU, and
> vice-versa, significantly dama
Thomas Hellström writes:
> On Tue, 2024-10-15 at 10:02 -0300, Jason Gunthorpe wrote:
>> On Tue, Oct 15, 2024 at 02:41:24PM +0200, Thomas Hellström wrote:
>> > > It has nothing to do with kernel P2P, you are just allowing more
>> > > selective filtering of dev_private_owner. You should focus on
Matthew Brost writes:
> Add migrate_device_prepoluated_range which prepares an array of
> pre-populated device pages for migration.
It would be nice if the commit message could also include an explanation
of why the existing migrate_device_range() is inadequate for your needs.
> v2:
> - s/mi
Matthew Brost writes:
> Avoid multiple CPU page faults to the same device page racing by trying
> to lock the page in do_swap_page before taking an extra reference to the
> page. This prevents scenarios where multiple CPU page faults each take
> an extra reference to a device page, which could
1PM +, Matthew Brost wrote:
>> > > > On Fri, Sep 20, 2024 at 05:50:10PM -0400, Felix Kuehling wrote:
>> > > > >
>> > > > > On 2024-09-20 17:23, Matthew Brost wrote:
>> > > > > > On Fri, Sep 20, 2024 at 04:26:50PM -0400, Fel
Matthew Brost writes:
> On Wed, Sep 11, 2024 at 02:53:31PM +1000, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> I haven't seen the same in the NVIDIA UVM driver (out-of-tree, I know)
>
> Still a driver.
Indeed, and I'm happy to an
Matthew Brost writes:
> Avoid multiple CPU page faults to the same device page racing by locking
> the page in do_swap_page before taking an additional reference to the
> page. This prevents scenarios where multiple CPU page faults each take
> an extra reference to a device page, which could ab
"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
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
"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
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
"Kasireddy, Vivek" writes:
> Hi Alistair,
>
>> >> > > > No, adding HMM_PFN_REQ_WRITE still doesn't help in fixing the
>> issue.
>> >> > > > Although, I do not have THP enabled (or built-in), shmem does not
>> evict
>> >> > > > the pages after hole punch as noted in the comment in
>> >> shmem_fa
"Kasireddy, Vivek" writes:
> Hi Jason,
>
>> > >
>> > > > No, adding HMM_PFN_REQ_WRITE still doesn't help in fixing the issue.
>> > > > Although, I do not have THP enabled (or built-in), shmem does not evict
>> > > > the pages after hole punch as noted in the comment in
>> shmem_fallocate():
>>
David Hildenbrand writes:
> On 03.08.23 14:14, Jason Gunthorpe wrote:
>> On Thu, Aug 03, 2023 at 07:35:51AM +, Kasireddy, Vivek wrote:
>>> Hi Jason,
>>>
>> Right, the "the zero pages are changed into writable pages" in your
>> above comment just might not apply, because there won't
"Kasireddy, Vivek" writes:
> Hi Alistair,
Hi Vivek,
>> I wonder if we actually need the flag? IIUC it is already used for more
>> than just KSM. For example it can be called as part of fault handling by
>> set_pte_at_notify() in in wp_page_copy().
> Yes, I noticed that but what I really meant
Jason Gunthorpe writes:
> On Mon, Jul 24, 2023 at 07:54:38AM +, Kasireddy, Vivek wrote:
>> And replace mmu_notifier_update_mapping(vma->vm_mm, address, pte_pfn(*ptep))
>> in the current patch with
>> mmu_notifier_change_pte(vma->vm_mm, address, ptep, false));
>
> It isn't very useful becau
"Kasireddy, Vivek" writes:
> Hi Alistair,
>
>>
>>
>> "Kasireddy, Vivek" writes:
>>
>> Yes, although obviously as I think you point out below you wouldn't be
>> able to take any sleeping locks in mmu_notifier_update_mapping().
> Yes, I understand that, but I am not sure how we can prevent any
"Kasireddy, Vivek" writes:
> Hi Alistair,
>
>>
>> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> > index 64a3239b6407..1f2f0209101a 100644
>> > --- a/mm/hugetlb.c
>> > +++ b/mm/hugetlb.c
>> > @@ -6096,8 +6096,12 @@ vm_fault_t hugetlb_fault(struct mm_struct
>> *mm, struct vm_area_struct *vma,
>>
Vivek Kasireddy writes:
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 64a3239b6407..1f2f0209101a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6096,8 +6096,12 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
>* hugetlb_no_page will d
1/10/22 16:51, Alistair Popple wrote:
>> migrate_vma->cpages originally contained a count of the number of
>> pages migrating including non-present pages which can be poluated
>
> "populated"
>
>> directly on the target.
>>
>> Co
t variable, restoring the previous behaviour on
migrate_to_ram() failure.
Fixes: 16ce101db85d ("mm/memory.c: fix race when faulting a device private
page")
Signed-off-by: Alistair Popple
Cc: Ralph Campbell
Cc: John Hubbard
Cc: Alex Sierra
Cc: Ben Skeggs
Cc: Felix Kuehling
Cc: Lyude Paul
: refactor migrate_vma and
migrate_deivce_coherent_page()")
Signed-off-by: Alistair Popple
Reported-by: Ralph Campbell
Cc: John Hubbard
Cc: Alex Sierra
Cc: Ben Skeggs
Cc: Felix Kuehling
Cc: Lyude Paul
Cc: Jason Gunthorpe
Cc: Michael Ellerman
---
Hi Andrew, hoping you can merge this small fix which Ralph report
"Vlastimil Babka (SUSE)" writes:
> On 9/28/22 14:01, Alistair Popple wrote:
>> This series aims to fix a number of page reference counting issues in
>> drivers dealing with device private ZONE_DEVICE pages. These result in
>> use-after-free type bugs, either fro
and switch to using
>>>> gen_pool_alloc() to track which offsets of a pgmap are allocated.
That's an interesting idea. I might take a look at converting hmm-tests
to do this (and probably by extension Nouveau as the allocator is
basically the same).
Feel free to also add:
Reviewed-
Felix Kuehling writes:
> On 2022-09-28 08:01, Alistair Popple wrote:
>> When the CPU tries to access a device private page the migrate_to_ram()
>> callback associated with the pgmap for the page is called. However no
>> reference is taken on the faulting page. T
Dan Williams writes:
> Alistair Popple wrote:
>>
>> Jason Gunthorpe writes:
>>
>> > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
>> >> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
>> >>
Andrew Morton writes:
> On Wed, 28 Sep 2022 22:01:22 +1000 Alistair Popple wrote:
>
>> @@ -1401,22 +1494,7 @@ static int dmirror_device_init(struct dmirror_device
>> *mdevice, int id)
>>
>> static void dmirror_device_remove(struct dmirror_device *mdevice
Michael Ellerman writes:
> Alistair Popple writes:
>> When the CPU tries to access a device private page the migrate_to_ram()
>> callback associated with the pgmap for the page is called. However no
>> reference is taken on the faulting page. Therefore a concurrent
>&
Signed-off-by: Alistair Popple
Cc: Jason Gunthorpe
Cc: Ralph Campbell
Cc: John Hubbard
Cc: Alex Sierra
Cc: Felix Kuehling
---
lib/test_hmm.c | 120 +-
lib/test_hmm_uapi.h| 1 +-
tools/testing/selftests/vm/hmm-tests.c
device pages have been freed which may never happen.
Fix this by migrating device mappings back to normal CPU memory prior to
freeing the GPU memory chunks and associated device private pages.
Signed-off-by: Alistair Popple
Cc: Lyude Paul
Cc: Ben Skeggs
Cc: Ralph Campbell
Cc: John Hubbard
.
Refactor out the core functionality so that it is not specific to fault
handling.
Signed-off-by: Alistair Popple
Reviewed-by: Lyude Paul
Cc: Ben Skeggs
Cc: Ralph Campbell
Cc: John Hubbard
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 58 +--
1 file changed, 28 insertions
n
free up device memory.
To allow that this patch introduces the migrate_device family of
functions which are functionally similar to migrate_vma but which skips
the initial lookup based on mapping.
Signed-off-by: Alistair Popple
Cc: "Huang, Ying"
Cc: Zi Yan
Cc: Matthew Wilcox
Cc:
this
isn't true for device private memory, and a future change requires
similar functionality for device private memory. So refactor the code
into something more sensible for migrating device memory without a vma.
Signed-off-by: Alistair Popple
Cc: "Huang, Ying"
Cc: Zi Yan
Cc: Mat
ns such as
get_page_unless_zero().
Signed-off-by: Alistair Popple
Cc: Jason Gunthorpe
Cc: Michael Ellerman
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: Christian König
Cc: Ben Skeggs
Cc: Lyude Paul
Cc: Ralph Campbell
Cc: Alex Sierra
Cc: John Hubbard
Cc: Dan Williams
---
This will conflict with Dan'
o see
if it's expected or not.
Signed-off-by: Alistair Popple
Cc: Jason Gunthorpe
Cc: John Hubbard
Cc: Ralph Campbell
Cc: Michael Ellerman
Cc: Felix Kuehling
Cc: Lyude Paul
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 15 ++-
drivers/gpu/drm/amd/amdkfd/kfd_migr
ough pages are still mapped by the kernel which can
lead to kernel crashes, particularly if a driver frees the pagemap.
To fix this drivers should take a pagemap reference when allocating the
page. This reference can then be returned when the page is freed.
Signed-off-by: Alistair Popple
Fixes: 27
-...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Alistair Popple (8):
mm/memory.c: Fix race when faulting a device private page
mm: Free device private pages have zero refcount
mm/memremap.c: Take a pgmap reference on page allocation
mm
Lyude Paul writes:
> On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
>> nouveau_dmem_fault_copy_one() is used during handling of CPU faults via
>> the migrate_to_ram() callback and is used to copy data from GPU to CPU
>> memory. It is currently specific to faul
Jason Gunthorpe writes:
> On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
>> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
>> refcount") device private pages have no longer had an extra reference
>> count when the page is in u
Felix Kuehling writes:
> On 2022-09-26 17:35, Lyude Paul wrote:
>> On Mon, 2022-09-26 at 16:03 +1000, Alistair Popple wrote:
>>> When the module is unloaded or a GPU is unbound from the module it is
>>> possible for device private pages to be left mapped in curr
John Hubbard writes:
> On 9/26/22 14:35, Lyude Paul wrote:
>>> + for (i = 0; i < npages; i++) {
>>> + if (src_pfns[i] & MIGRATE_PFN_MIGRATE) {
>>> + struct page *dpage;
>>> +
>>> + /*
>>> +* _GFP_NOFAIL because the GPU is going
callbacks have all been freed.
Fix this by migrating any mappings back to normal CPU memory prior to
freeing the GPU memory chunks and associated device private pages.
Signed-off-by: Alistair Popple
---
I assume the AMD driver might have a similar issue. However I can't see
where device privat
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 119 +-
lib/test_hmm_uapi.h| 1 +-
tools/testing/selftests/vm/hmm-tests.c | 49 +++-
3 files changed, 148 insertions(+), 21 deletions(-)
diff --git a/lib/test_hmm.c
.
Refactor out the core functionality so that it is not specific to fault
handling.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 59 +--
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b
n
free up device memory.
To allow that this patch introduces the migrate_device family of
functions which are functionally similar to migrate_vma but which skips
the initial lookup based on mapping.
Signed-off-by: Alistair Popple
---
include/linux/migrate.h | 7 +++-
mm/migrate_device.c
this
isn't true for device private memory, and a future change requires
similar functionality for device private memory. So refactor the code
into something more sensible for migrating device memory without a vma.
Signed-off-by: Alistair Popple
---
mm/migrate_device.c
ns such as
get_page_unless_zero().
Signed-off-by: Alistair Popple
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 1 +
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
lib/test_hmm.c | 1 +
mm/memremap.c| 5
o see
if it's expected or not.
Signed-off-by: Alistair Popple
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 15 ++-
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 17 +++--
drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 11 +--
. Unfortunately I lack the
hardware to test on either of these so would appreciate it if someone with
access could test those.
Alistair Popple (7):
mm/memory.c: Fix race when faulting a device private page
mm: Free device private pages have zero refcount
mm/migrate_device.c: Refactor
Commit b05a79d4377f ("mm/gup: migrate device coherent pages when pinning
instead of failing") added a badly formatted if statement. Fix it.
Signed-off-by: Alistair Popple
Reported-by: David Hildenbrand
---
Apologies Andrew for missing this. Hopefully this fixes things.
mm/gup.c |
Commit b05a79d4377f ("mm/gup: migrate device coherent pages when pinning
instead of failing") added a badly formatted if statement. Fix it.
Signed-off-by: Alistair Popple
Reported-by: David Hildenbrand
---
Apologies Andrew for missing this. Hopefully this fixes things.
mm/gup.c |
SG_MAX_SINGLE_ALLOC. However a typo in updating the
starting address means that only the first chunk will get migrated.
Fix the calculation so that the entire range will get migrated if
possible.
Signed-off-by: Alistair Popple
Fixes: e3d8b0890469 ("drm/nouveau/svm: map pages after migr
: Alistair Popple
Acked-by: Felix Kuehling
Signed-off-by: Christoph Hellwig
---
This patch hopefully addresses all of David's comments. It replaces both my "mm:
remove the vma check in migrate_vma_setup()" and "mm/gup: migrate device
coherent pages when pinning instead of failing&qu
1 - 100 of 342 matches
Mail list logo
