Hi Alex and Gerd, >-----Original Message----- >From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@xxxxxxxxxxxxxxxxxxxxx] On >Behalf Of Alex Williamson >Sent: Thursday, May 11, 2017 11:45 PM >To: Gerd Hoffmann <kraxel@xxxxxxxxxx> >Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; linux- >kernel@xxxxxxxxxxxxxxx; zhenyuw@xxxxxxxxxxxxxxx; Lv, Zhiyuan ><zhiyuan.lv@xxxxxxxxx>; Chen, Xiaoguang <xiaoguang.chen@xxxxxxxxx>; intel- >gvt-dev@xxxxxxxxxxxxxxxxxxxxx; Wang, Zhi A <zhi.a.wang@xxxxxxxxx> >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 <kraxel@xxxxxxxxxx> 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. 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). Chenxg. >Thanks, > >Alex >_______________________________________________ >intel-gvt-dev mailing list >intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx >https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
