Message-ID: <1448368735.27648.110.camel@redhat.com>
Date:	Tue, 24 Nov 2015 13:38:55 +0100
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	Alex Williamson <alex.williamson@...hat.com>,
	"igvt-g@...1.01.org" <igvt-g@...1.01.org>,
	"Li, Susie" <susie.li@...el.com>,
	"White, Michael L" <michael.l.white@...el.com>,
	"Dong, Eddie" <eddie.dong@...el.com>,
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
	"Reddy, Raghuveer" <raghuveer.reddy@...el.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	qemu-devel <qemu-devel@...gnu.org>,
	"Zhou, Chao" <chao.zhou@...el.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	"Zhu, Libo" <libo.zhu@...el.com>,
	"Wang, Hongbo" <hongbo.wang@...el.com>
Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a
 Mediated Graphics Passthrough Solution from Intel

  Hi,

> > Yes, vGPU may have additional features, like a framebuffer area, that
> > aren't present or optional for direct assignment.  Obviously we support
> > direct assignment of GPUs for some vendors already without this feature.
> 
> For exposing framebuffers for spice/vnc I highly recommend against
> anything that looks like a bar/fixed mmio range mapping. First this means
> the kernel driver needs to internally fake remapping, which isn't fun.

Sure.  I don't think we should remap here.  More below.

> My recoomendation is to build the actual memory access for underlying
> framebuffers on top of dma-buf, so that it can be vacuumed up by e.g. the
> host gpu driver again for rendering.

We want that too ;)

Some more background:

OpenGL support in qemu is still young and emerging, and we are actually
building on dma-bufs here.  There are a bunch of different ways how
guest display output is handled.  At the end of the day it boils down to
only two fundamental cases though:

  (a) Where qemu doesn't need access to the guest framebuffer
      - qemu directly renders via opengl (works today with virtio-gpu
        and will be in the qemu 2.5 release)
      - qemu passed on the dma-buf to spice client for local display
        (experimental code exists).
      - qemu feeds the guest display into gpu-assisted video encoder
        to send a stream over the network (no code yet).

  (b) Where qemu must read the guest framebuffer.
      - qemu's builtin vnc server.
      - qemu writing screenshots to file.
      - (non-opengl legacy code paths for local display, will
         hopefully disappear long-term though ...)

So, the question is how to support (b) best.  Even with OpenGL support
in qemu improving over time I don't expect this going away completely
anytime soon.

I think it makes sense to have a special vfio region for that.  I don't
think remapping makes sense there.  It doesn't need to be "live", it
doesn't need support high refresh rates.  Placing a copy of the guest
framebuffer there on request (and convert from tiled to linear while
being at it) is perfectly fine.  qemu has a adaptive update rate and
will stop doing frequent update requests when the vnc client
disconnects, so there will be nothing to do if nobody wants actually see
the guest display.

Possible alternative approach would be to import a dma-buf, then use
glReadPixels().  I suspect when doing the copy in the kernel the driver
could ask just the gpu to blit the guest framebuffer.  Don't know gfx
hardware good enough to be sure though, comments are welcome.

cheers,
  Gerd


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists