From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932439AbdELC6d (ORCPT ); Thu, 11 May 2017 22:58:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60300 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752130AbdELC6c (ORCPT ); Thu, 11 May 2017 22:58:32 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BD65773056 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=alex.williamson@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BD65773056 Date: Thu, 11 May 2017 20:58:29 -0600 From: Alex Williamson To: "Chen, Xiaoguang" Cc: Gerd Hoffmann , "Tian, Kevin" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "zhenyuw@linux.intel.com" , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" , "Wang, Zhi A" Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Message-ID: <20170511205829.672854c3@t450s.home> In-Reply-To: References: <1493372130-27727-1-git-send-email-xiaoguang.chen@intel.com> <1493372130-27727-7-git-send-email-xiaoguang.chen@intel.com> <1493718658.8581.82.camel@redhat.com> <20170504100833.199bc8ba@t450s.home> <1493967331.371.53.camel@redhat.com> <20170505091115.7a680636@t450s.home> <1494509273.17970.12.camel@redhat.com> <20170511094526.164985ee@w520.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 12 May 2017 02:58:32 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 12 May 2017 02:12:10 +0000 "Chen, Xiaoguang" wrote: > Hi Alex and Gerd, > > >-----Original Message----- > >From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On > >Behalf Of Alex Williamson > >Sent: Thursday, May 11, 2017 11:45 PM > >To: Gerd Hoffmann > >Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux- > >kernel@vger.kernel.org; zhenyuw@linux.intel.com; Lv, Zhiyuan > >; Chen, Xiaoguang ; intel- > >gvt-dev@lists.freedesktop.org; Wang, Zhi A > >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf > > > >On Thu, 11 May 2017 15:27:53 +0200 > >Gerd Hoffmann wrote: > > > >> Hi, > >> > >> > While read the framebuffer region we have to tell the vendor driver which > >framebuffer we want to read? There are two framebuffers now in KVMGT that is > >primary and cursor. > >> > There are two methods to implement this: > >> > 1) write the plane id first and then read the framebuffer. > >> > 2) create 2 vfio regions one for primary and one for cursor. > >> > >> (3) Place information for both planes into one vfio region. > >> Which allows to fetch both with a single read() syscall. > >> > >> The question is how you'll get the file descriptor then. If the ioctl > >> returns the dma-buf fd only you have a racy interface: Things can > >> change between read(vfio-region) and ioctl(need-dmabuf-fd). > >> > >> ioctl(need-dma-buf) could return both dmabuf fd and plane info to fix > >> the race, but then it is easier to go with ioctl only interface > >> (simliar to the orginal one from dec last year) I think. > > > >If the dmabuf fd is provided by a separate mdev vendor driver specific ioctl, I > >don't see how vfio regions should be involved. Selecting which framebuffer > >should be an ioctl parameter. > Based on your last mail. I think the implementation looks like this: > 1) user query the framebuffer information by reading the vfio region. > 2) if the framebuffer changed(such as framebuffer's graphics address changed, size changed etc) we will need to create a new dmabuf fd. > 3) create a new dmabuf fd using vfio device specific ioctl. > > >What sort of information needs to be conveyed > >about each plane? > Only plane id is needed. > > >Is it static information or something that needs to be read > >repeatedly? > It is static information. For our case plane id 1 represent primary plane and 3 for cursor plane. 2 means sprite plane which will not be used in our case. > > >Do we need it before we get the dmabuf fd or can it be an ioctl on > >the dmabuf fd? > We need it while query the framebuffer. In kernel we need the plane id to decide which plane we should decode. > Below is my current implementation: > 1) user first query the framebuffer(primary or cursor) and kernel decode the framebuffer and return the framebuffer information to user and also save a copy in kernel. > 2) user compared the framebuffer and if the framebuffer changed creating a new dmabuf fd. If the contents of the framebuffer change or if the parameters of the framebuffer change? I can't image that creating a new dmabuf fd for every visual change within the framebuffer would be efficient, but I don't have any concept of what a dmabuf actually does. > 3) kernel create a new dmabuf fd based on saved framebuffer information. > > So we need plane id in step 1. > In step 3 we create a dmabuf fd only using saved framebuffer information(no other information is needed). What changes to the framebuffer require a new dmabuf fd? Shouldn't the user query the parameters of the framebuffer through a dmabuf fd and shouldn't the dmabuf fd have some signaling mechanism to the user (eventfd perhaps) to notify the user to re-evaluate the parameters? Otherwise are you imagining that the user polls the vfio region? Why can a dmabuf fd not persist across changes to the framebuffer? Can someone explain what a dmabuf is and how it works in terms that a non-graphics person can understand? Thanks, Alex