All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Matthew Auld" <matthew.auld@intel.com>,
	intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: Re: [PATCH] drm: increase 64-bit mmap_range size to 8TB
Date: Fri, 13 Nov 2026 07:09:09 -0800	[thread overview]
Message-ID: <avcoFV3ugyumPTnn@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <007c58e6-9af5-4d42-b307-0827df55fbb4@amd.com>

On Thu, Nov 12, 2026 at 01:58:22PM +0100, Christian König wrote:
> On 11/12/26 13:20, Matthew Auld wrote:
> > Every GEM/TTM buffer object, including imported dma-bufs, allocates a
> > fake mmap offset from the per-device drm_vma_offset_manager. On multi-GPU
> > systems with large VRAM, peer-to-peer dma-buf imports across devices and
> > processes can exhaust the current 1 TiB 64-bit range and fail BO creation
> > or PRIME import with -ENOSPC. Skipping mmap offset allocation for
> > imported sg buffers is not straightforward without risking userspace
> > regressions, as existing userspace (such as Intel compute-runtime) still
> > queries mmap_offset on imported host dma-bufs even when mapping the
> > dma-buf fd directly.
> 
> I was just about to ask why the heck we grab mmap offsets for imported DMA-bufs :)
> 
> > Increase DRM_FILE_PAGE_OFFSET_SIZE on 64-bit kernels so the fake offset
> > range spans up to 8 TiB (SZ_8T). This stays strictly below panthor's
> > DRM_PANTHOR_USER_MMIO_OFFSET_32BIT (1ULL << 43) carveout and within
> > 32-bit compat mmap2's pgoff limit (16 TiB with 4K pages).
> > 
> > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > Cc: Christian König <christian.koenig@amd.com>
> > Cc: Matthew Brost <matthew.brost@intel.com>

Reviewed-by: Matthew Brost <matthew.brost@intel.com>

> 
> Acked-by: Christian König <christian.koenig@amd.com>
> 
> > ---
> >  include/drm/drm_vma_manager.h | 13 ++++++++++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
> > index 6c2a2f21dbf0..2c3233f9dec4 100644
> > --- a/include/drm/drm_vma_manager.h
> > +++ b/include/drm/drm_vma_manager.h
> > @@ -26,16 +26,23 @@
> >  #include <drm/drm_mm.h>
> >  #include <linux/mm.h>
> >  #include <linux/rbtree.h>
> > +#include <linux/sizes.h>
> >  #include <linux/spinlock.h>
> >  #include <linux/types.h>
> >  
> > -/* We make up offsets for buffer objects so we can recognize them at
> > +/*
> > + * We make up offsets for buffer objects so we can recognize them at
> >   * mmap time. pgoff in mmap is an unsigned long, so we need to make sure
> > - * that the faked up offset will fit
> > + * that the faked up offset will fit.
> > + *
> > + * On 64-bit, cap the range at 8 TiB (SZ_8T) so offsets remain below both
> > + * panthor's DRM_PANTHOR_USER_MMIO_OFFSET_32BIT (1ULL << 43) and 32-bit
> > + * compat mmap2's pgoff ceiling (16 TiB with 4K pages).
> >   */
> >  #if BITS_PER_LONG == 64
> >  #define DRM_FILE_PAGE_OFFSET_START ((0xFFFFFFFFUL >> PAGE_SHIFT) + 1)
> > -#define DRM_FILE_PAGE_OFFSET_SIZE ((0xFFFFFFFFUL >> PAGE_SHIFT) * 256)
> > +#define DRM_FILE_PAGE_OFFSET_SIZE ((SZ_8T >> PAGE_SHIFT) - \
> > +				   DRM_FILE_PAGE_OFFSET_START)
> >  #else
> >  #define DRM_FILE_PAGE_OFFSET_START ((0xFFFFFFFUL >> PAGE_SHIFT) + 1)
> >  #define DRM_FILE_PAGE_OFFSET_SIZE ((0xFFFFFFFUL >> PAGE_SHIFT) * 16)
> 

  reply	other threads:[~2026-11-13 15:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 12:20 [PATCH] drm: increase 64-bit mmap_range size to 8TB Matthew Auld
2026-11-12 12:58 ` Christian König
2026-11-13 15:09   ` Matthew Brost [this message]
2026-11-12 12:59 ` ✓ CI.KUnit: success for " Patchwork
2026-11-12 13:33 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-12 20:45 ` ✓ Xe.CI.FULL: " 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=avcoFV3ugyumPTnn@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --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.