On Fri, 12 May 2017 02:12:10 +0000 "Chen, Xiaoguang" <xiaoguang.c...@intel.com> wrote:
> Hi Alex and Gerd, > > >-----Original Message----- > >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > >Behalf Of Alex Williamson > >Sent: Thursday, May 11, 2017 11:45 PM > >To: Gerd Hoffmann <kra...@redhat.com> > >Cc: Tian, Kevin <kevin.t...@intel.com>; intel-...@lists.freedesktop.org; > >linux- > >ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan > ><zhiyuan...@intel.com>; Chen, Xiaoguang <xiaoguang.c...@intel.com>; intel- > >gvt-...@lists.freedesktop.org; Wang, Zhi A <zhi.a.w...@intel.com> > >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 <kra...@redhat.com> 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
