[vfio-users] Question about integrated GPU passthrough and initialization

[Alex Williamson]

On Fri, 24 May 2019 14:10:03 -0700
Micah Morton <mortonm at chromium.org> wrote:

> On Fri, May 24, 2019 at 12:50 PM Alex Williamson
> <alex.williamson at redhat.com> wrote:
> >
> > On Fri, 24 May 2019 11:12:41 -0700
> > Micah Morton <mortonm at chromium.org> wrote:
> >  
> > > I’ve been working with an Intel Chrome OS device to see if integrated
> > > GPU passthrough works. The device is a 7th Generation (Kaby Lake)
> > > Intel Core i5-7Y57 with HD Graphics 615. So no discrete GPU. I think
> > > iGPU passthrough should work on this device.
> > >
> > > Initializing the graphics hardware has proven to be the trickiest part
> > > in all of this, and I have a question I thought someone on this list
> > > might be able to answer:
> > >
> > > Why does vfio enforce that I _need_ a VGA rom to be available in order
> > > to boot the guest in legacy passthrough mode
> > > (https://github.com/qemu/qemu/blob/master/hw/vfio/pci-quirks.c#L1616)?  
> >
> > "Legacy" mode is largely about setting up components to make the VGA
> > ROM work.  Some of the components of legacy mode are faking stolen
> > memory (which really only works for the ROM, not the OS driver), adding
> > the LPC bridge (not sure of the OS driver dependency on this, but I
> > think it can be manually added if needed), and adding the OpRegion
> > (which can also be manually added).  If you only care about OS level
> > graphics initialization then you probably only need the OpRegion
> > support, which Intel vGPU also needs but Intel can't provide a
> > consistent story about how it should work.  So why do you think you
> > need legacy assignment mode?  Granted UPT mode is just about a
> > forgotten ideal at Intel, but legacy mode doesn't really solve the
> > stolen memory dependencies for anyone but the VGA ROM.  
> 
> Ah ok. Yeah I have no reason to think I need "legacy" mode apart from
> the fact that I wanted the GPU to be the "primary and exclusive
> graphics device in the VM". Is the only alternative UPT mode, which
> "does not support direct video output"
> (https://android.googlesource.com/platform/external/qemu/+/emu-master-dev/docs/igd-assign.txt#14)?
> So I can definitely pass through the device to the guest and get the
> i915 driver in the guest to attach to it on some level:
> 
> ~ # lspci -nnk (in the guest)
> ...
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Device
> [8086:591e] (rev 02)
> Subsystem: Intel Corporation Device [8086:2212]
> Kernel driver in use: i915
> 
> I guess the question for me now is whether I need OpRegion support in
> the guest (or anything else) for the guest driver to successfully use
> the GPU (I just see a black screen right now and haven't yet enabled
> much in the way of meaningful logs for i915). Do you have any pointers
> to resources on how the OpRegion can be added? Or am I better off
> contacting Intel engineers?

If you're using QEMU by command line, just add x-igd-opregion=on to the
set of device parameters for the vfio-pci device.  libvirt does not
provide a supported way to add this (the 'x-' prefix indicates an
experimental option and is used here because it's rather a hack), but
you can use <qemu:arg> elements to pass it, such as documented here:
http://vfio.blogspot.com/2016/09/passing-qemu-command-line-options.html
It's entirely possible that this alone will be enough to light up the
display.  Thanks,

Alex