From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
himal.prasad.ghimiray@intel.com, apopple@nvidia.com,
airlied@gmail.com, simona.vetter@ffwll.ch,
felix.kuehling@amd.com, dakr@kernel.org
Subject: Re: [PATCH v4 04/33] drm/pagemap: Add DRM pagemap
Date: Tue, 11 Feb 2025 17:03:10 +0100 [thread overview]
Message-ID: <7842182aeb75205fccde42ca4e0700a7c52bbebf.camel@linux.intel.com> (raw)
In-Reply-To: <Z6pIY16rfPNDS0Xr@lstrano-desk.jf.intel.com>
On Mon, 2025-02-10 at 10:41 -0800, Matthew Brost wrote:
> On Fri, Feb 07, 2025 at 09:34:00AM +0100, Thomas Hellström wrote:
> > On Wed, 2025-01-29 at 11:51 -0800, Matthew Brost wrote:
> > > From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > >
> > > Introduce drm_pagemap ops to map and unmap dma to VRAM resources.
> > > In
> > > the
> > > local memory case it's a matter of merely providing an offset
> > > into
> > > the
> > > device's physical address. For future p2p the map and unmap
> > > functions
> > > may
> > > encode as needed.
> > >
> > > Similar to how dma-buf works, let the memory provider
> > > (drm_pagemap)
> > > provide
> > > the mapping functionality.
> >
>
> Trying to parse all of this.
>
> > It should be noted that the long term idea for dma mapping is to
> > have
> > that done by the client instead of by the memory provider, which
> > Jason
>
> - Client here is the device mapping the memory.
> - Memory provider is the device where the memory is located?
>
> Did I get this correct?
>
> > reminded me of in a discussion on dri-devel. The dma-mapping here
> > is
> > modeled after how it's done for dma-buf, where the exporter maps
> > dma.
> >
> > So following that, it might be that we should move these dma-
> > mapping
> > ops to the drm_gpusvm().
> >
>
> So we move ops to the local client (gpusvm) rather than remote
> device,
> right?
>
> > The situation I can think of, where this might be a problem is that
> > if
> > the device-private struct page to dma address mapping is not known
> > to
> > the client.
> >
>
> I'm not following this but I agree if dma mapping at the client we
> need
> the remote device structure given how the dma mapping API works.
>
> So to wrap it up - what, if anything, do you think we need to do to
> this
> individual patch as part of this series?
I've been thinking a bit more about this, and I think a change we can
do is to rename these methods to something along device_map() and
device_unmap(). The purpose would be to emphasize that the resulting
addresses are typically not meaningful outside of the driver, and not
to be confused with standard dma-mapping.
/Thomas
>
> Matt
>
> > /Thomas
> >
> >
> >
> >
> >
> > >
> > > v3:
> > > - Move to drm level include
> > > v4:
> > > - Fix kernel doc (G.G.)
> > >
> > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > Signed-off-by: Thomas Hellström
> > > <thomas.hellstrom@linux.intel.com>
> > > ---
> > > include/drm/drm_pagemap.h | 105
> > > ++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 105 insertions(+)
> > > create mode 100644 include/drm/drm_pagemap.h
> > >
> > > diff --git a/include/drm/drm_pagemap.h
> > > b/include/drm/drm_pagemap.h
> > > new file mode 100644
> > > index 000000000000..2b610ccf7e30
> > > --- /dev/null
> > > +++ b/include/drm/drm_pagemap.h
> > > @@ -0,0 +1,105 @@
> > > +/* SPDX-License-Identifier: MIT */
> > > +#ifndef _DRM_PAGEMAP_H_
> > > +#define _DRM_PAGEMAP_H_
> > > +
> > > +#include <linux/dma-direction.h>
> > > +#include <linux/hmm.h>
> > > +#include <linux/types.h>
> > > +
> > > +struct drm_pagemap;
> > > +struct device;
> > > +
> > > +/**
> > > + * enum drm_interconnect_protocol - Used to identify an
> > > interconnect
> > > protocol.
> > > + */
> > > +enum drm_interconnect_protocol {
> > > + DRM_INTERCONNECT_SYSTEM, /* DMA map is system pages.
> > > */
> > > + DRM_INTERCONNECT_PCIE_P2P, /* DMA map is PCIE P2P */
> > > + DRM_INTERCONNECT_DRIVER, /* DMA map is driver defined
> > > */
> > > + /* A driver can add private values beyond
> > > DRM_INTERCONNECT_DRIVER */
> > > +};
> > > +
> > > +/**
> > > + * struct drm_pagemap_dma_addr - DMA address representation.
> > > + * @addr: The dma address or driver-defined address for driver
> > > private interconnects.
> > > + * @proto: The interconnect protocol.
> > > + * @order: The page order of the dma mapping. (Size is PAGE_SIZE
> > > <<
> > > order).
> > > + * @dir: The DMA direction.
> > > + *
> > > + * Note: There is room for improvement here. We should be able
> > > to
> > > pack into
> > > + * 64 bits.
> > > + */
> > > +struct drm_pagemap_dma_addr {
> > > + dma_addr_t addr;
> > > + u64 proto : 54;
> > > + u64 order : 8;
> > > + u64 dir : 2;
> > > +};
> > > +
> > > +/**
> > > + * drm_pagemap_dma_addr_encode() - Encode a dma address with
> > > metadata
> > > + * @addr: The dma address or driver-defined address for driver
> > > private interconnects.
> > > + * @proto: The interconnect protocol.
> > > + * @order: The page order of the dma mapping. (Size is PAGE_SIZE
> > > <<
> > > order).
> > > + * @dir: The DMA direction.
> > > + *
> > > + * Return: A struct drm_pagemap_dma_addr encoding the above
> > > information.
> > > + */
> > > +static inline struct drm_pagemap_dma_addr
> > > +drm_pagemap_dma_addr_encode(dma_addr_t addr,
> > > + enum drm_interconnect_protocol
> > > proto,
> > > + unsigned int order,
> > > + enum dma_data_direction dir)
> > > +{
> > > + return (struct drm_pagemap_dma_addr) {
> > > + .addr = addr,
> > > + .proto = proto,
> > > + .order = order,
> > > + .dir = dir,
> > > + };
> > > +}
> > > +
> > > +/**
> > > + * struct drm_pagemap_ops: Ops for a drm-pagemap.
> > > + */
> > > +struct drm_pagemap_ops {
> > > + /**
> > > + * @map_dma: Map for dma access or provide a virtual
> > > address
> > > suitable for
> > > + *
> > > + * @dpagemap: The struct drm_pagemap for the page.
> > > + * @dev: The dma mapper.
> > > + * @page: The page to map.
> > > + * @order: The page order of the dma mapping. (Size is
> > > PAGE_SIZE << order).
> > > + * @dir: The transfer direction.
> > > + */
> > > + struct drm_pagemap_dma_addr (*map_dma)(struct
> > > drm_pagemap
> > > *dpagemap,
> > > + struct device
> > > *dev,
> > > + struct page
> > > *page,
> > > + unsigned int
> > > order,
> > > + enum
> > > dma_data_direction dir);
> > > +
> > > + /**
> > > + * @unmap_dma: Unmap a dma address previously obtained
> > > using
> > > @map_dma.
> > > + *
> > > + * @dpagemap: The struct drm_pagemap for the mapping.
> > > + * @dev: The dma unmapper.
> > > + * @addr: The dma address obtained when mapping.
> > > + */
> > > + void (*unmap_dma)(struct drm_pagemap *dpagemap,
> > > + struct device *dev,
> > > + struct drm_pagemap_dma_addr addr);
> > > +
> > > +};
> > > +
> > > +/**
> > > + * struct drm_pagemap: Additional information for a struct
> > > dev_pagemap
> > > + * used for device p2p handshaking.
> > > + * @ops: The struct drm_pagemap_ops.
> > > + * @dev: The struct drevice owning the device-private memory.
> > > + */
> > > +struct drm_pagemap {
> > > + const struct drm_pagemap_ops *ops;
> > > + struct device *dev;
> > > +};
> > > +
> > > +#endif
> >
next prev parent reply other threads:[~2025-02-11 16:03 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 19:51 [PATCH v4 00/33] Introduce GPU SVM and Xe SVM implementation Matthew Brost
2025-01-29 19:51 ` [PATCH v4 01/33] drm/xe: Retry BO allocation Matthew Brost
2025-01-29 19:51 ` [PATCH v4 02/33] mm/migrate: Add migrate_device_pfns Matthew Brost
2025-01-31 5:24 ` Alistair Popple
2025-01-31 7:47 ` Gwan-gyeong Mun
2025-02-04 22:17 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 03/33] mm/migrate: Trylock device page in do_swap_page Matthew Brost
2025-01-29 19:51 ` [PATCH v4 04/33] drm/pagemap: Add DRM pagemap Matthew Brost
2025-02-07 8:34 ` Thomas Hellström
2025-02-10 18:41 ` Matthew Brost
2025-02-11 16:03 ` Thomas Hellström [this message]
2025-02-11 18:17 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 05/33] drm/xe/bo: Introduce xe_bo_put_async Matthew Brost
2025-01-30 8:49 ` Thomas Hellström
2025-01-30 16:26 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 06/33] drm/gpusvm: Add support for GPU Shared Virtual Memory Matthew Brost
2025-01-30 9:13 ` Thomas Hellström
2025-01-30 11:17 ` Matthew Auld
2025-01-30 13:13 ` Gwan-gyeong Mun
2025-01-30 16:42 ` Matthew Brost
2025-02-07 9:06 ` Thomas Hellström
2025-02-10 17:31 ` Matthew Brost
2025-02-11 15:17 ` Thomas Hellström
2025-02-11 18:05 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 07/33] drm/xe: Select DRM_GPUSVM Kconfig Matthew Brost
2025-02-07 3:18 ` Ghimiray, Himal Prasad
2025-02-07 9:30 ` Thomas Hellström
2025-01-29 19:51 ` [PATCH v4 08/33] drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR flag Matthew Brost
2025-02-07 9:37 ` Thomas Hellström
2025-02-07 12:11 ` Ghimiray, Himal Prasad
2025-02-07 13:47 ` Upadhyay, Tejas
2025-02-10 19:08 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 09/33] drm/xe: Add SVM init / close / fini to faulting VMs Matthew Brost
2025-02-07 3:24 ` Ghimiray, Himal Prasad
2025-02-07 9:43 ` Thomas Hellström
2025-01-29 19:51 ` [PATCH v4 10/33] drm/xe: Add dma_addr res cursor Matthew Brost
2025-02-10 19:11 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 11/33] drm/xe: Nuke VM's mapping upon close Matthew Brost
2025-01-30 10:50 ` Matthew Auld
2025-01-30 16:28 ` Matthew Brost
2025-02-07 10:15 ` Thomas Hellström
2025-02-10 19:16 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 12/33] drm/xe: Add SVM range invalidation and page fault handler Matthew Brost
2025-02-07 10:32 ` Thomas Hellström
2025-01-29 19:51 ` [PATCH v4 13/33] drm/gpuvm: Add DRM_GPUVA_OP_DRIVER Matthew Brost
2025-02-07 10:36 ` Thomas Hellström
2025-01-29 19:51 ` [PATCH v4 14/33] drm/xe: Add (re)bind to SVM page fault handler Matthew Brost
2025-01-29 19:51 ` [PATCH v4 15/33] drm/xe: Add SVM garbage collector Matthew Brost
2025-02-07 12:42 ` Thomas Hellström
2025-01-29 19:51 ` [PATCH v4 16/33] drm/xe: Add unbind to " Matthew Brost
2025-02-07 12:55 ` Thomas Hellström
2025-02-10 21:17 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 17/33] drm/xe: Do not allow CPU address mirror VMA unbind if the GPU has bindings Matthew Brost
2025-02-07 13:01 ` Thomas Hellström
2025-01-29 19:51 ` [PATCH v4 18/33] drm/xe: Enable CPU address mirror uAPI Matthew Brost
2025-02-07 13:02 ` Thomas Hellström
2025-01-29 19:51 ` [PATCH v4 19/33] drm/xe/uapi: Add DRM_XE_QUERY_CONFIG_FLAG_HAS_CPU_ADDR_MIRROR Matthew Brost
2025-02-07 11:35 ` Ghimiray, Himal Prasad
2025-02-07 11:35 ` Ghimiray, Himal Prasad
2025-02-07 13:04 ` Thomas Hellström
2025-02-07 13:43 ` Upadhyay, Tejas
2025-02-10 19:15 ` Matthew Brost
2025-01-29 19:51 ` [PATCH v4 20/33] drm/xe: Add migrate layer functions for SVM support Matthew Brost
2025-02-07 13:07 ` Thomas Hellström
2025-01-29 19:52 ` [PATCH v4 21/33] drm/xe: Add SVM device memory mirroring Matthew Brost
2025-02-07 13:29 ` Thomas Hellström
2025-01-29 19:52 ` [PATCH v4 22/33] drm/xe: Add drm_gpusvm_devmem to xe_bo Matthew Brost
2025-01-29 19:52 ` [PATCH v4 23/33] drm/xe: Add drm_pagemap ops to SVM Matthew Brost
2025-01-30 10:54 ` Matthew Auld
2025-01-30 13:24 ` Gwan-gyeong Mun
2025-01-30 16:24 ` Matthew Brost
2025-01-29 19:52 ` [PATCH v4 24/33] drm/xe: Add GPUSVM device memory copy vfunc functions Matthew Brost
2025-02-07 13:32 ` Thomas Hellström
2025-01-29 19:52 ` [PATCH v4 25/33] drm/xe: Add Xe SVM populate_devmem_pfn GPU SVM vfunc Matthew Brost
2025-01-29 19:52 ` [PATCH v4 26/33] drm/xe: Add Xe SVM devmem_release " Matthew Brost
2025-01-29 19:52 ` [PATCH v4 27/33] drm/xe: Add BO flags required for SVM Matthew Brost
2025-02-07 13:54 ` Thomas Hellström
2025-02-11 19:19 ` Matthew Brost
2025-02-11 19:36 ` Thomas Hellström
2025-01-29 19:52 ` [PATCH v4 28/33] drm/xe: Add SVM VRAM migration Matthew Brost
2025-01-30 14:22 ` Matthew Auld
2025-01-30 16:32 ` Matthew Brost
2025-01-30 16:41 ` Thomas Hellström
2025-01-30 16:56 ` Matthew Auld
2025-01-30 17:31 ` Matthew Brost
2025-01-30 18:51 ` Thomas Hellström
2025-01-31 17:30 ` Matthew Brost
2025-02-07 13:57 ` Thomas Hellström
2025-01-29 19:52 ` [PATCH v4 29/33] drm/xe: Basic SVM BO eviction Matthew Brost
2025-02-07 14:45 ` Thomas Hellström
2025-02-11 19:21 ` Matthew Brost
2025-01-29 19:52 ` [PATCH v4 30/33] drm/xe: Add SVM debug Matthew Brost
2025-02-07 14:46 ` Thomas Hellström
2025-01-29 19:52 ` [PATCH v4 31/33] drm/xe: Add modparam for SVM notifier size Matthew Brost
2025-02-07 14:48 ` Thomas Hellström
2025-01-29 19:52 ` [PATCH v4 32/33] drm/xe: Add always_migrate_to_vram modparam Matthew Brost
2025-02-07 14:50 ` Thomas Hellström
2025-01-29 19:52 ` [PATCH v4 33/33] drm/doc: gpusvm: Add GPU SVM documentation Matthew Brost
2025-02-07 14:54 ` Thomas Hellström
2025-01-29 21:04 ` ✓ CI.Patch_applied: success for Introduce GPU SVM and Xe SVM implementation (rev4) Patchwork
2025-01-29 21:05 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-29 21:06 ` ✗ CI.KUnit: failure " Patchwork
2025-01-30 13:52 ` [PATCH v4 00/33] Introduce GPU SVM and Xe SVM implementation Gwan-gyeong Mun
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=7842182aeb75205fccde42ca4e0700a7c52bbebf.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=airlied@gmail.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=simona.vetter@ffwll.ch \
/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.