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

[Zhenyu Wang]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20201019/eedb0149/attachment-0001.sig>