On Wed, Jan 17, 2018 at 12:39 AM, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Tue, Jan 16, 2018 at 04:35:59PM -0800, Gurchetan Singh wrote: > > This is required to use buffers allocated by vgem on AMD and ARM devices. > > We're experiencing a case where eviction of the cache races with > userspace > > writes. To fix this, flush the cache after retrieving a page. > > > > Signed-off-by: Gurchetan Singh <gurchetansi...@chromium.org> > > --- > > drivers/gpu/drm/vgem/vgem_drv.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c > b/drivers/gpu/drm/vgem/vgem_drv.c > > index 35bfdfb746a7..fb263969f02d 100644 > > --- a/drivers/gpu/drm/vgem/vgem_drv.c > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > > @@ -112,6 +112,7 @@ static int vgem_gem_fault(struct vm_fault *vmf) > > break; > > } > > > > + drm_flush_pages(obj->base.dev->dev, &page, 1); > > Uh ... what exactly are you doing? > > Asking because the entire "who's responsible for coherency" story is > entirely undefined still when doing buffer sharing :-/ What is clear is > that currently vgem entirely ignores this (there's not > begin/end_cpu_access callback), mostly because the shared dma-buf support > in drm_prime.c also entirely ignores this. This patch isn't trying to address the case of a dma-buf imported into vgem. It's trying to address the case when a buffer is created by vgem_gem_dumb_create, mapped by vgem_gem_dumb_map and then accessed by user space. Since the page retrieved by shmem_read_mapping_page during the page fault may still be in the cache, we're experiencing incorrect data in buffer. Here's the test case we're running: https://chromium.googlesource.com/chromiumos/platform/drm-tests/+/master/vgem_test.c It fails on line 210 on AMD and ARM devices (not Intel though). And doing a one-time only > flushing in your fault handler is definitely not going to fix this (at > least not if you do anything else than one-shot uploads). > There used to be a be vgem_gem_get_pages function, but that's been removed. I don't know where else to flush in this situation. > -Daniel > > > } > > return ret; > > } > > -- > > 2.13.5 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch >
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
