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. > > For detecting a hypervisor, following on from the KVM_CPUID_SIGNATURE > hint, we find arch/x86 does detect_hypervisor_platform() at load which > populates EXPORT_SYMBOL(x86_hyper_type) > > So something like, > > #include <asm/hypervisor.h> > @@ -1764,7 +1766,7 @@ static inline bool intel_vtd_active(void) > if (intel_iommu_gfx_mapped) > return true; > #endif > - return false; > + return x86_hyper_type != X86_HYPER_NATIVE; > } > > should work. > -Chris -- $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
