[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170619085530.1f5e46dc@w520.home>
Date: Mon, 19 Jun 2017 08:55:30 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Gerd Hoffmann <kraxel@...hat.com>
Cc: Kirti Wankhede <kwankhede@...dia.com>,
Xiaoguang Chen <xiaoguang.chen@...el.com>,
chris@...is-wilson.co.uk, intel-gfx@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, zhenyuw@...ux.intel.com,
zhiyuan.lv@...el.com, intel-gvt-dev@...ts.freedesktop.org,
zhi.a.wang@...el.com, kevin.tian@...el.com
Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
On Mon, 19 Jun 2017 08:38:32 +0200
Gerd Hoffmann <kraxel@...hat.com> wrote:
> Hi,
>
> > My suggestion was to use vfio device fd for this ioctl and have
> > dmabuf
> > mgr fd as member in above query_plane structure, for region type it
> > would be set to 0.
>
> Region type should be DRM_PLANE_TYPE_PRIMARY
>
> > Can't mmap that page to get surface information. There is no way to
> > synchronize between QEMU reading this mmapped region and vendor
> > driver
> > writing it. There could be race condition in these two operations.
> > Read
> > on this page should be trapped and blocking, so that surface in that
> > region is only updated when its asked for.
>
> Does it make sense to have a "generation" field in the plane_info
> struct (which gets increased each time the struct changes) ?
It seems less cumbersome than checking each field to see if it has
changed. Thanks,
Alex
Powered by blists - more mailing lists