On 2020.10.19 11:20:40 +0100, Chris Wilson wrote: > Quoting Zhenyu Wang (2020-10-19 10:51:44) > > On 2020.10.19 10:57:38 +0100, Chris Wilson wrote: > > > Quoting Zhenyu Wang (2020-10-19 10:19:09) > > > > On 2020.10.16 17:19:19 +0200, Stefan Fritsch wrote: > > > > > Hi, > > > > > > > > > > if Linux is running as a guest and the host is doing igd-pass-thorugh with > > > > > VT-d enabled, the i915 driver does not work all that great. The most > > > > > obvious problem is that there are dozens of 'Fault errors on pipe A' > > > > > errrors logged per second, but depending on the hardware there can be > > > > > other issues, too. I will send a patch to rate-limit that message in a > > > > > separate mail. > > > > > > > > > > The i915 has various quirks for VT-d and these should be enabled even if > > > > > Linux is running as a guest and does itself have iommu enabled. I have > > > > > checked that making intel_vtd_active() form i915_drv.h return true makes > > > > > the error messages go away. How could Linux detect this situation? Maybe > > > > > simply check the Hypervisor cpuid bit? Or would you prefer a module > > > > > parameter, or a combination of both? Or is there another way to detect > > > > > that VT-d is enabled for the igd device? > > > > > > > > > > > > > I think that's right, although I haven't tried to force intel_vtd_active() > > > > for guest, but I did see those fault errors on some machine. You can use > > > > hypervisor cpuid bit, and need to seperate case for GVT which is detected by > > > > intel_vgpu_active(), but I'm not sure if this should be taken in nested case, > > > > suppose those quirks should still work? > > > > > > Do we need it for gvt since the guest has no access to HW, so the host > > > should be doing all the vt'd w/a. (In particular, the scanout overfetch > > > causing the problems here.) E.g. in gvt, the guest framebuffer is > > > transported via magics to the host, and the host creates a GGTT entry > > > for it. > > > > GVT doesn't require vt-d at all. Current gvt display is fully virtualized, > > so if by any way that map guest framebuffer directly on host display, it > > should still be handled by i915 with possible vt-d workaround for alignment. > > And looks some other vt-d w/a just brings unnecessary actions for gvt guest. > > So I think we should stick with real vt-d case. > > It's not too bad; we should only be applying the vtd workaround on > interacting with the HW. So for gvt running under a kvm hypervisor, > setting intel_vtd_active() should not impact us at all... Current quick view seems that gen8_ggtt_clear_range is unnecessary, but maybe not a big deal. Others seem ok... -- $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
