Re: About the iGVT-g's requirement to pin guest contexts in VM

[Zhiyuan Lv <zhiyuan.lv@intel.com>]

Hi Chris,

On Mon, Aug 24, 2015 at 11:23:13AM +0100, Chris Wilson wrote:
> On Mon, Aug 24, 2015 at 06:04:28PM +0800, Zhiyuan Lv wrote:
> > Hi Chris,
> > 
> > On Thu, Aug 20, 2015 at 09:36:00AM +0100, Chris Wilson wrote:
> > > On Thu, Aug 20, 2015 at 03:45:21PM +0800, Zhiyuan Lv wrote:
> > > > Intel GVT-g will perform EXECLIST context shadowing and ring buffer
> > > > shadowing. The shadow copy is created when guest creates a context.
> > > > If a context changes its LRCA address, the hypervisor is hard to know
> > > > whether it is a new context or not. We always pin context objects to
> > > > global GTT to make life easier.
> > > 
> > > Nak. Please explain why we need to workaround a bug in the host. We
> > > cannot pin the context as that breaks userspace (e.g. synmark) who can
> > > and will try to use more contexts than we have room.
> > 
> > Could you have a look at below reasons and kindly give us your inputs?
> > 
> > 1, Due to the GGTT partitioning, the global graphics memory available
> > inside virtual machines is much smaller than native case. We cannot
> > support some graphics memory intensive workloads anyway. So it looks
> > affordable to just pin contexts which do not take much GGTT.
> 
> Wrong. It exposes the guest to a trivial denial-of-service attack. A

Inside a VM, indeed.

> smaller GGTT does not actually limit clients (there is greater aperture
> pressure and some paths are less likely but an individual client will
> function just fine).
>  
> > 2, Our hypervisor needs to change i915 guest context in the shadow
> > context implementation. That part will be tricky if the context is not
> > always pinned. One scenario is that when a context finishes running,
> > we need to copy shadow context, which has been updated by hardware, to
> > guest context. The hypervisor knows context finishing by context
> > interrupt, but that time shrinker may have unpin the context and its
> > backing storage may have been swap-out. Such copy may fail. 
> 
> That is just a bug in your code. Firstly allowing swapout on an object
> you still are using, secondly not being able to swapin.

As Zhi replied in another email, we do not have the knowledge of guest
driver's swap operations. If we cannot pin context, we may have to ask
guest driver not to swap out context pages. Do you think that would be
the right way to go? Thanks!

Regards,
-Zhiyuan

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx