On Fri, 24 May 2019 14:10:03 -0700 Micah Morton <mort...@chromium.org> wrote:
> On Fri, May 24, 2019 at 12:50 PM Alex Williamson > <alex.william...@redhat.com> wrote: > > > > On Fri, 24 May 2019 11:12:41 -0700 > > Micah Morton <mort...@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 _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
