DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B980E4ACD0
Message-ID: <1497947703.16795.4.camel@redhat.com>
Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
From: Gerd Hoffmann <kraxel@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>,
        Xiaoguang Chen <xiaoguang.chen@intel.com>, chris@chris-wilson.co.uk,
        intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        zhenyuw@linux.intel.com, zhiyuan.lv@intel.com,
        intel-gvt-dev@lists.freedesktop.org, zhi.a.wang@intel.com,
        kevin.tian@intel.com
Date: Tue, 20 Jun 2017 10:35:03 +0200
In-Reply-To: <20170619085409.26f5c14c@w520.home>
References: <1497513611-2814-1-git-send-email-xiaoguang.chen@intel.com>
         <1497513611-2814-6-git-send-email-xiaoguang.chen@intel.com>
         <f19da207-a7f5-d3d3-4577-b071e7d75cf7@nvidia.com>
         <1497542438.29252.1.camel@redhat.com> <20170615143833.7526351b@w520.home>
         <24c4880b-24f5-ea07-834c-c77d3e895c78@nvidia.com>
         <20170616103959.3b6f1681@t450s.home> <1497854053.4207.2.camel@redhat.com>
         <20170619085409.26f5c14c@w520.home>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1881
Lines: 55

  Hi,

> > Hmm, plane isn't really an ID, it is a type, with type being either
> > DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think
> > the
> > flage above make sense.
> 
> The intention was that ..._REGION_ID and ...PLANE_ID are describing
> what the vfio_device_query_gfx_plane.id field represents, either a
> region index or a plane identifier.  The type of plane would be
> represented within the vfio_device_gfx_plane_info struct.

The planes don't really have an id, we should rename that to
plane_type, or maybe drm_plane_type (simliar to the drm_format_*
fields), to avoid that confusion.

plane_type is set by userspace to specify what kind of plane it asks
for.

> > Also I think it would be useful to have some way to figure the
> > device
> > capabilities as the userspace workflow will look quite different
> > for
> > the two cases.
> 
> In the region case, VFIO_DEVICE_GET_REGION_INFO would include a
> device
> specific region with a hopefully common identifier to identify it as
> a
> graphics framebuffer.

Ok, that should work to figure whenever the mdev supports a plane
region or not.

> In the dmabuf case,VFIO_DEVICE_QUERY_GFX_PLANE would indicate the
> plane as a "plane ID" and some sort of
> VFIO_DEVICE_GET_GFX_PLANE(VFIO_GFX_TYPE_DMABUF) ioctl would be
> necessary to get a file descriptor to that plane.
> 
> What else are you thinking we need?  Thanks,

I need to know whenever the mdev supports dmabufs or not, at device
initialization time (because dmabufs require opengl support), when
VFIO_DEVICE_QUERY_GFX_PLANE doesn't work due to the guest not having
the device initialized yet.

Maybe we should have a error field in the ioctl struct, or we need to
clearly define error codes so the kernel doesn't just throw EINVAL in
all cases.

Or just a VFIO_DEVICE_GFX_CAPS ioctl which returns NONE, REGION or
DMABUF.

cheers,
  Gerd