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

[Micah Morton]

Ah ok thanks!

The qemu command line i was using is here: `qemu-system-x86_64
-chardev stdio,id=seabios -device
isa-debugcon,iobase=0x402,chardev=seabios -m 2G -smp 2 -M pc -vga none
-usbdevice tablet -cpu host,-invpcid,-tsc-deadline,check -drive
'file=/path/to/image.bin,index=0,media=disk,cache=unsafe,format=raw'
-enable-kvm -device
vfio-pci,x-igd-opregion=on,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2,rombar=0
-device 'virtio-net,netdev=eth0' -netdev
'user,id=eth0,net=10.0.2.0/27,hostfwd=tcp:127.0.0.1:9222-:22'`

It didn't work, but now at least I know why:
[    0.316117] i915 0000:00:02.0: No more image in the PCI ROM
[    0.316261] [drm] Failed to find VBIOS tables (VBT)

If I can expose the VBT to the VM maybe it will work :)

On Fri, May 24, 2019 at 2:19 PM Alex Williamson
<alex.williamson at redhat.com> wrote:
>
> 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