From: Jason Gunthorpe <jgg@nvidia.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org,
Matthew Brost <matthew.brost@intel.com>,
Simona Vetter <simona.vetter@ffwll.ch>,
DRI-devel <dri-devel@lists.freedesktop.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm/hmm, mm/migrate_device: Allow p2p access and p2p migration
Date: Tue, 15 Oct 2024 09:17:59 -0300 [thread overview]
Message-ID: <20241015121759.GG3394334@nvidia.com> (raw)
In-Reply-To: <20241015111322.97514-1-thomas.hellstrom@linux.intel.com>
On Tue, Oct 15, 2024 at 01:13:22PM +0200, Thomas Hellström wrote:
> Introduce a way for hmm_range_fault() and migrate_vma_setup() to identify
> foreign devices with fast interconnect and thereby allow
> both direct access over the interconnect and p2p migration.
>
> The need for a callback arises because without it, the p2p ability would
> need to be static and determined at dev_pagemap creation time. With
> a callback it can be determined dynamically, and in the migrate case
> the callback could separate out local device pages.
> +static bool hmm_allow_devmem(struct hmm_range *range, struct page *page)
> +{
> + if (likely(page->pgmap->owner == range->dev_private_owner))
> + return true;
> + if (likely(!range->p2p))
> + return false;
> + return range->p2p->ops->p2p_allow(range->p2p, page);
> +}
> +
> static int hmm_vma_handle_pte(struct mm_walk *walk, unsigned long addr,
> unsigned long end, pmd_t *pmdp, pte_t *ptep,
> unsigned long *hmm_pfn)
> @@ -248,8 +258,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, unsigned long addr,
> * just report the PFN.
> */
> if (is_device_private_entry(entry) &&
> - pfn_swap_entry_to_page(entry)->pgmap->owner ==
> - range->dev_private_owner) {
> + hmm_allow_devmem(range, pfn_swap_entry_to_page(entry))) {
> cpu_flags = HMM_PFN_VALID;
> if (is_writable_device_private_entry(entry))
> cpu_flags |= HMM_PFN_WRITE;
This is really misnamed and took me a while to get it.
It has nothing to do with kernel P2P, you are just allowing more
selective filtering of dev_private_owner. You should focus on that in
the naming, not p2p. ie allow_dev_private()
P2P is stuff that is dealing with MEMORY_DEVICE_PCI_P2PDMA.
This is just allowing more instances of the same driver to co-ordinate
their device private memory handle, for whatever purpose.
Otherwise I don't see a particular problem, though we have talked
about widening the matching for device_private more broadly using some
kind of grouping tag or something like that instead of a callback. You
may consider that as an alternative
I would also probably try to have less indirection, you can embedd the
hmm_range struct inside a caller private data struct and use that
instead if inventing a whole new struct and pointer.
Jason
next prev parent reply other threads:[~2024-10-15 12:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-15 11:13 [RFC PATCH] mm/hmm, mm/migrate_device: Allow p2p access and p2p migration Thomas Hellström
2024-10-15 11:21 ` Thomas Hellström
2024-10-15 12:17 ` Jason Gunthorpe [this message]
2024-10-15 12:41 ` Thomas Hellström
2024-10-15 13:02 ` Jason Gunthorpe
2024-10-15 13:17 ` Thomas Hellström
2024-10-16 4:46 ` Alistair Popple
2024-10-15 13:34 ` ✓ CI.Patch_applied: success for " Patchwork
2024-10-15 13:35 ` ✓ CI.checkpatch: " Patchwork
2024-10-15 13:36 ` ✓ CI.KUnit: " Patchwork
2024-10-15 13:47 ` ✓ CI.Build: " Patchwork
2024-10-15 13:50 ` ✓ CI.Hooks: " Patchwork
2024-10-15 13:51 ` ✓ CI.checksparse: " Patchwork
2024-10-15 22:06 ` ✗ CI.FULL: failure " Patchwork
2024-10-16 6:20 ` ✓ CI.Patch_applied: success for mm/hmm, mm/migrate_device: Allow p2p access and p2p migration (rev2) Patchwork
2024-10-16 6:20 ` ✓ CI.checkpatch: " Patchwork
2024-10-16 6:21 ` ✓ CI.KUnit: " Patchwork
2024-10-16 6:33 ` ✓ CI.Build: " Patchwork
2024-10-16 6:35 ` ✓ CI.Hooks: " Patchwork
2024-10-16 6:37 ` ✓ CI.checksparse: " Patchwork
2024-10-16 7:00 ` ✓ CI.BAT: " Patchwork
2024-10-16 14:48 ` ✗ CI.FULL: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241015121759.GG3394334@nvidia.com \
--to=jgg@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=simona.vetter@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.