Message-ID: <20170512103828.4a1378a1@t450s.home>
Date:   Fri, 12 May 2017 10:38:28 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Gerd Hoffmann <kraxel@...hat.com>
Cc:     "Chen, Xiaoguang" <xiaoguang.chen@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>,
        "Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "Wang, Zhi A" <zhi.a.wang@...el.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@...hat.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.

The dmabuf manager fd can be separately versioned from vfio or make use
of some vendor magic if there are portions that are vendor specific
(the above examples for query/get ioctls really don't seem vendor
specific).
 
> I'm not sure how useful notification support actually is though.
> Notifications when another plane gets mapped to the crtc should be easy.
> But I'm not sure it is possible to get notifications when the plane
> content changes, especially in case the guest does software rendering so
> the display is updated without gvt seeing guest activity on the
> rendering pipeline.  Without the later qemu needs a timer for display
> updates _anyway_ ...

Seems like it has benefits even if we don't have an initial use for
notification mechanisms.  Thanks,

Alex

Powered by blists - more mailing lists