Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

From	Kirti Wankhede <kwankhede@nvidia.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
Date	2017-06-20 15:40 +0200
Message-ID	<tUrxT-Mz-1@gated-at.bofh.it> (permalink)
References	(3 earlier) <tSFvk-4D9-17@gated-at.bofh.it> <tSJIC-7cs-25@gated-at.bofh.it> <tSZDH-Ds-7@gated-at.bofh.it> <tTYvT-7uN-1@gated-at.bofh.it> <tU6jM-3YD-19@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw


On 6/19/2017 8:25 PM, Alex Williamson wrote:
> On Mon, 19 Jun 2017 08:38:32 +0200
> Gerd Hoffmann <kraxel@redhat.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,
> 

Looks good. And vendor driver should take care of rounding up the value
when it reaches its max limit.

Thanks,
Kirti


> Alex
>

Back to linux.kernel | Previous | Next | Find similar | Unroll thread

Thread

Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations Kirti Wankhede <kwankhede@nvidia.com> - 2017-06-20 15:40 +0200

csiph-web