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

[Alex Williamson]

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