On Tue, 20 Feb 2018 11:28:14 +0100
Gerd Hoffmann <kra...@redhat.com> wrote:
> On Mon, Feb 19, 2018 at 03:16:49PM -0700, Alex Williamson wrote:
> > On Mon, 19 Feb 2018 12:14:51 +0100
> > Gerd Hoffmann <kra...@redhat.com> wrote:
> > > This series adds support for a vgpu display to the qemu vfio code.
> > > For now only regions are supported, dmabufs will follow later.
> > >
> > > This version adds a patch to allow devices disable hotplugging, which
> > > will be used by vfio display support. Also fixed issues Alex found in
> > > review.
> > Looks ok to me, if this is to go through my tree I'll need a qdev ack
> > for 4/7. If you want to go a different route, for 5-7:
> > Acked-by: Alex Williamson <alex.william...@redhat.com>
> > I'm still a bit confused though, what's preventing us from adding
> > dmabuf support now? It's strange to provide the implementation for the
> > proprietary, unavailable vendor driver implementation first. Is GVT-g
> > broken, lagging? Thanks,
> A bit more complicated because it depends on user interface changes ...
> Sneak preview at https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu
> Note: branch is a moving target ;)
> vfio: Working, needs some cleanups though (drop debug logging, ...).
> gtk: Working, needs some minor cleanups too.
> spice: Partly working (no mouse ptr yet).
> sdl: Not working. Need to figure how I get a egl context (instead
> of glx). Possibly requires SDL 2.2. Tina looked at this a
> while back, need to look at some old mails ...
> Current plan:
> (1) fix/complete spice support.
> (2) cleanup patches, send them out.
> (3) look at the SDL issues.
It's a little bit concerning that the only way we can test the
region-based display support is with proprietary drivers that nobody
but NVIDIA has at this point. Have you considered adding region-based
display support to the mdev sample tty driver? I know it sounds
ridiculous for a serial device to have a display, but the vfio display
region support isn't really tied to the functionality of the base mdev
device. We could have it simply display a static test pattern, just so
we can test the end to end code path without a dependency on a closed
vendor driver. Thanks,