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

[Micah Morton]

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?

>
> > The Intel device I’m working with normally doesn’t initialize the GPU
> > at all until the kernel is running, at which point the i915 driver
> > does the initialization. So there is never actually any VGA rom
> > anywhere on the system at any time for me to grab. I suppose I maybe
> > could get one for this hardware from Intel or the web somewhere, but
> > seems like if the device can normally initialize the GPU hardware from
> > the kernel driver then it wouldn’t be too unreasonable to pass through
> > the GPU and let the guest (with the same i915 driver) initialize the
> > GPU without using a VGA rom. Do you think it would be reasonable for
> > me to find a way to patch qemu/vfio/SeaBIOS to allow for this
> > scenario?
>
> I'm still not sure what you're missing versus the options we provide
> otherwise.  If your dependency is actually on stolen memory, then
> trying to re-enable the hack for legacy mode is likely not to work for
> the OS driver.  The fix for that would mean having the host dictate to
> the VM an address space hole such that stolen memory could be identity
> mapped into the VM (plus safety things like clearing that memory
> between users to avoid leaking data).  Thanks,
>
> Alex