[Intel-gfx] drm/i915: Detecting Vt-d when running as guest os

[Chris Wilson]

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...
-Chris