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 ;) > > State: > 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. Hi Gerd, 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, Alex
