On Wed, 12 Jun 2019 08:49:36 -0700 Micah Morton <mort...@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 _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
