This is helpful, thanks for the info! On Wed, Jun 12, 2019 at 9:41 AM Alex Williamson <alex.william...@redhat.com> wrote: > > 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
