Re: [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap

From: Daniel Vetter <daniel@ffwll.ch>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
Date: Fri, 15 Nov 2019 16:31:18 +0100	[thread overview]
Message-ID: <CAKMK7uHNOF5pAWCbQ1-eFWcxEOZmOoKOYL450ZJd7TOeVhMvjw@mail.gmail.com> (raw)
In-Reply-To: <20191115105601.i7ahtapysv4j7mn7@sirius.home.kraxel.org>

On Fri, Nov 15, 2019 at 11:56 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Fri, Nov 15, 2019 at 11:18:28AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 15, 2019 at 10:37 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >
> > > > You need memory pressure, to force ttm to unmap the bo, not userspace. So
> > > > roughly
> > > > 1. create bo
> > > > 2. mmap it through drm fd, write some stuff
> > > > 3. export to dma-buf, mmap it, verify stuff is there
> > > > 4. create a pile more bo, mmap them write to them
> > > > 5. once you've thrashed all of vram enough, recheck your original bo. If
> > > > I'm right you should get the following:
> > > >    - drm fd mmap still show right content
> > > >    - dma-buf fd mmap shows random crap that you've written into other
> > > >      buffers
> > > >
> > > > Ofc you need to make sure that an mmap actually forces the buffer into
> > > > vram. So might need a combo of modeset+mmap, to make that happen. Plain
> > > > mmap might just give you ptes that point into system memory, which is not
> > > > managed by ttm like vram.
> > >
> > > Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM
> > > work too?  That'll be easier because all I need to do is map the buffer
> > > to a crtc to force pinning to vram, then check if the mappings are
> > > intact still ...
> >
> > I think that should work too.
>
> Seems to work ok for ttm/vram.
>
> Test code:
>   https://git.kraxel.org/cgit/drminfo/commit/?id=a9eb96504dc17376e07b5c6edf5296b41a48bbfe

I think that's not nasty enough. If the mappings aren't updated, then
you'll still see the the same old pages with the right contents. You
need to change them somehow after they migrated (with vram eviction
that happens automatically since there'll b another object in the same
spot, for system memory I think you need the shrinker to kick in and
free the pages first). Easiest probably to wait for a key press so you
can appreciate the color, then write a different color (full screen)
when the buffer is in vram.

> > Just make sure you actually write
> > through SYSTEM first (maybe with some printk or whatever).
>
> That works fine.  Sprinkled ...
>
>         system("cat /sys/kernel/debug/dri/0/vram-mm");
>
> ... into the test code, and drmModeSetCrtc() indeed makes the gem object show
> up there.

You'd need to check the ptes themselves. Which I think not even proc
shows by default (only the file that's supposed to be mapped). But
good to confirm that the buffer moved at least.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel