From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751813AbdFTIe4 (ORCPT ); Tue, 20 Jun 2017 04:34:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60284 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750965AbdFTIey (ORCPT ); Tue, 20 Jun 2017 04:34:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B980E4ACD0 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 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 To: Alex Williamson Cc: Kirti Wankhede , Xiaoguang Chen , 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> <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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 20 Jun 2017 08:34:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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