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

[Micah Morton]

This is helpful, thanks for the info!

On Wed, Jun 12, 2019 at 9:41 AM Alex Williamson
<alex.williamson at redhat.com> wrote:
>
> On Wed, 12 Jun 2019 08:49:36 -0700
> Micah Morton <mortonm at chromium.org> wrote:
>
> > Hi Alex,
> >
> > Thanks for the help on this earlier, I was able to get IGD passthrough
> > working on my device (In case you're interested, crbug.com/970820 has
> > further details on the changes we needed to make to the kernel/i915
> > driver to get things working).
> >
> > I have a couple follow up questions that hopefully you can get to when
> > you get a chance:
> >
> > 1) I see in https://patchwork.kernel.org/patch/9115161/ that you wrote
> > a patch for SeaBIOS to reserve stolen memory for the IGD device. It
> > seems that it is hard-coded to reserve 8MB of stolen memory. I wanted
> > to reserve 64MB, but wasn't able to locate the "etc/igd-bdsm-size"
> > file that should be able to configure this. Where does this file live?
> > Its easy enough for me to hard-code SeaBIOS to 64MB, but I was curious
> > if there's a cleaner way to set this.
>
> There's a QEMU vfio-pci device option x-igd-gms= which (according to
> the commit log[1], because I've forgotten how this works 3yrs later)
> specifies the number of 32MB chunks of additional stolen memory
> allocated.  So theoretically you could just add x-igd-gms=2 for 64MB.
>
>
> > 2) Even when SeaBIOS reserves a region for stolen memory, the VM
> > kernel has a hard time realizing the region is there and available. So
> > far I just hard-coded the kernel/i915 driver since I know the
> > address/range of the memory region that SeaBIOS will reserve for
> > stolen memory in my case. It requires some hard-coding both in the
> > kernel (https://elixir.bootlin.com/linux/v4.14.114/source/arch/x86/kernel/early-quirks.c#L436)
> > and in the driver
> > (https://elixir.bootlin.com/linux/v4.14.114/source/drivers/gpu/drm/i915/i915_gem_stolen.c#L404).
> > Are you aware of any discussions around this problem? I wanted to see
> > if it has already been discussed before looking at proposing some kind
> > of patch to the kernel/driver.
>
> The fact that there are genX versions of those sorts of sizing and init
> routines is exactly part of the problem with assigning IGD.  There's
> no standard and the hardware folks change things as they please.  Maybe
> the QEMU code doesn't do quite the right thing for your hardware
> generation.  IIRC I developed the QEMU quirks on Broadwell and older
> hardware and I don't have the time or hardware access to tweak it for
> every new chip.  Intel also can't seem to maintain a consistent story
> about whether they're reducing or increasing their dependencies on
> external components like chipset registers, stolen memory, and firmware
> tables.  I expect the best hope for reliable IGD in a VM with physical
> display output might come through GVT-g (ie. vGPU), but the physical
> display part of that isn't supported yet and I don't see a strong
> commitment to enable GVT-g across the product line.  Thanks,
>
> Alex
>
> [1]https://git.qemu.org/?p=qemu.git;a=commit;h=c4c45e943e519f5ac220f7af1afb2a0025d03c54