From: Alex Williamson <alex.williamson@redhat.com>
To: "Chen, Xiaoguang" <xiaoguang.chen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"zhenyuw@linux.intel.com" <zhenyuw@linux.intel.com>,
"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
"intel-gvt-dev@lists.freedesktop.org"
<intel-gvt-dev@lists.freedesktop.org>,
"Wang, Zhi A" <zhi.a.wang@intel.com>
Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
Date: Mon, 15 May 2017 11:44:09 -0600 [thread overview]
Message-ID: <20170515114409.414d1fdb@w520.home> (raw)
In-Reply-To: <DD379D741F77464281CE7ED1CD7C12DE706592D6@SHSMSX101.ccr.corp.intel.com>
On Mon, 15 May 2017 03:36:50 +0000
"Chen, Xiaoguang" <xiaoguang.chen@intel.com> wrote:
> Hi Alex and Gerd,
>
> >-----Original Message-----
> >From: Alex Williamson [mailto:alex.williamson@redhat.com]
> >Sent: Saturday, May 13, 2017 12:38 AM
> >To: Gerd Hoffmann <kraxel@redhat.com>
> >Cc: Chen, Xiaoguang <xiaoguang.chen@intel.com>; Tian, Kevin
> ><kevin.tian@intel.com>; intel-gfx@lists.freedesktop.org; linux-
> >kernel@vger.kernel.org; zhenyuw@linux.intel.com; Lv, Zhiyuan
> ><zhiyuan.lv@intel.com>; intel-gvt-dev@lists.freedesktop.org; Wang, Zhi A
> ><zhi.a.wang@intel.com>
> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
> >
> >On Fri, 12 May 2017 11:12:05 +0200
> >Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> >> Hi,
> >>
> >> > 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.
> >>
> >> Ok, some background:
> >>
> >> The drm subsystem has the concept of planes. The most important plane
> >> is the primary framebuffer (i.e. what gets scanned out to the physical
> >> display). The cursor is a plane too, and there can be additional
> >> overlay planes for stuff like video playback.
> >>
> >> Typically there are multiple planes in a system and only one of them
> >> gets scanned out to the crtc, i.e. the fbdev emulation creates one
> >> plane for the framebuffer console. The X-Server creates a plane too,
> >> and when you switch between X-Server and framebuffer console via
> >> ctrl-alt-fn the intel driver just reprograms the encoder to scan out
> >> the one or the other plane to the crtc.
> >>
> >> The dma-buf handed out by gvt is a reference to a plane. I think on
> >> the host side gvt can see only the active plane (from encoder/crtc
> >> register
> >> programming) not the inactive ones.
> >>
> >> The dma-buf can be imported as opengl texture and then be used to
> >> render the guest display to a host window. I think it is even
> >> possible to use the dma-buf as plane in the host drm driver and scan
> >> it out directly to a physical display. The actual framebuffer content
> >> stays in gpu memory all the time, the cpu never has to touch it.
> >>
> >> It is possible to cache the dma-buf handles, i.e. when the guest boots
> >> you'll get the first for the fbcon plane, when the x-server starts the
> >> second for the x-server framebuffer, and when the user switches to the
> >> text console via ctrl-alt-fn you can re-use the fbcon dma-buf you
> >> already have.
> >>
> >> The caching becomes more important for good performance when the guest
> >> uses pageflipping (wayland does): define two planes, render into one
> >> while displaying the other, then flip the two for a atomic display
> >> update.
> >>
> >> The caching also makes it a bit difficult to create a good interface.
> >> So, the current patch set creates:
> >>
> >> (a) A way to query the active planes (ioctl
> >> INTEL_VGPU_QUERY_DMABUF added by patch 5/6 of this series).
> >> (b) A way to create a dma-buf for the active plane (ioctl
> >> INTEL_VGPU_GENERATE_DMABUF).
> >>
> >> Typical userspace workflow is to first query the plane, then check if
> >> it already has a dma-buf for it, and if not create one.
> >
> >Thank you! This is immensely helpful!
> >
> >> > 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?
> >>
> >> dma-bufs don't support that, they are really just a handle to a piece
> >> of memory, all metadata (format, size) most be communicated by other means.
> >>
> >> > Otherwise are you imagining that the user polls the vfio region?
> >>
> >> Hmm, notification support would probably a good reason to have a
> >> separate file handle to manage the dma-bufs (instead of using
> >> driver-specific ioctls on the vfio fd), because the driver could also
> >> use the management fd for notifications then.
> >
> >I like this idea of a separate control fd for dmabufs, it provides not only a central
> >management point, but also a nice abstraction for the vfio device specific
> >interface. We potentially only need a single
> >VFIO_DEVICE_GET_DMABUF_MGR_FD() ioctl to get a dmabuf management fd
> >(perhaps with a type parameter, ex. GFX) where maybe we could have vfio-core
> >incorporate this reference into the group lifecycle, so the vendor driver only
> >needs to fdget/put this manager fd for the various plane dmabuf fds spawned in
> >order to get core-level reference counting.
> Following is my understanding of the management fd idea:
> 1) QEMU will call VFIO_DEVICE_GET_DMABUF_MGR_FD() ioctl to create a fd and saved the fd in vfio group while initializing the vfio.
Ideally there'd be kernel work here too if we want vfio-core to
incorporate lifecycle of this fd into the device/group/container
lifecycle. Maybe we even want to generalize it further to something
like VFIO_DEVICE_GET_FD which takes a parameter of what type of FD to
get, GFX_DMABUF_MGR_FD in this case. vfio-core would probably allocate
the fd, tap into the release hook for reference counting and pass it to
the vfio_device_ops (mdev vendor driver in this case) to attach further.
> 2) vendor driver use fdget to add reference count of the fd.
> 3) vendor driver use ioctl to the fd to query plane information or create dma-buf fd.
> 4) vendor driver use fdput when finished using this fd.
>
> Is my understanding right?
With the above addition, which maybe you were already considering, seems
right.
> Both QEMU and kernel vfio-core will have changes based on this proposal except the vendor part changes.
> Who will make these changes?
/me points to the folks trying to enable this functionality...
Thanks,
Alex
next prev parent reply other threads:[~2017-05-15 17:44 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-28 9:35 [RFC PATCH 0/6] drm/i915/gvt: dma-buf support for GVT-g Xiaoguang Chen
2017-04-28 9:35 ` [RFC PATCH 1/6] drm/i915/gvt: extend the GVT-g architecture to support vfio device region Xiaoguang Chen
2017-04-28 9:35 ` [RFC PATCH 2/6] drm/i915/gvt: OpRegion support for GVT-g Xiaoguang Chen
2017-04-28 9:35 ` [RFC PATCH 3/6] drm/i915/gvt: framebuffer decoder " Xiaoguang Chen
2017-04-28 9:35 ` [RFC PATCH 4/6] drm/i915: export i915 dmabuf_ops Xiaoguang Chen
2017-04-28 9:35 ` [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g Xiaoguang Chen
2017-04-28 10:08 ` [Intel-gfx] " Chris Wilson
2017-05-02 7:40 ` Chen, Xiaoguang
2017-05-04 3:12 ` Chen, Xiaoguang
2017-05-02 9:37 ` Gerd Hoffmann
2017-04-28 9:35 ` [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Xiaoguang Chen
2017-05-02 9:50 ` Gerd Hoffmann
2017-05-03 1:39 ` Chen, Xiaoguang
2017-05-04 3:09 ` Chen, Xiaoguang
2017-05-04 16:08 ` Alex Williamson
2017-05-05 6:55 ` Gerd Hoffmann
2017-05-05 15:11 ` Alex Williamson
2017-05-11 8:45 ` Chen, Xiaoguang
2017-05-11 13:27 ` Gerd Hoffmann
2017-05-11 15:45 ` Alex Williamson
2017-05-12 2:12 ` Chen, Xiaoguang
2017-05-12 2:58 ` Alex Williamson
2017-05-12 3:52 ` Chen, Xiaoguang
2017-05-12 9:12 ` Gerd Hoffmann
2017-05-12 16:38 ` Alex Williamson
2017-05-15 3:36 ` Chen, Xiaoguang
2017-05-15 17:44 ` Alex Williamson [this message]
2017-05-16 10:16 ` Chen, Xiaoguang
2017-05-17 21:43 ` Alex Williamson
2017-05-18 1:51 ` Chen, Xiaoguang
2017-05-18 14:56 ` Alex Williamson
2017-05-19 6:23 ` Chen, Xiaoguang
2017-05-19 8:04 ` Gerd Hoffmann
2017-05-19 8:17 ` Chen, Xiaoguang
2017-05-19 8:57 ` Gerd Hoffmann
2017-05-19 9:14 ` Chen, Xiaoguang
2017-05-19 10:51 ` Gerd Hoffmann
2017-05-18 6:22 ` Gerd Hoffmann
2017-05-12 6:56 ` Chen, Xiaoguang
2017-05-12 17:04 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170515114409.414d1fdb@w520.home \
--to=alex.williamson@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xiaoguang.chen@intel.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.a.wang@intel.com \
--cc=zhiyuan.lv@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).