[Intel-gfx] About the iGVT-g's requirement to pin guest contexts in VM

[Daniel Vetter]

On Tue, Aug 25, 2015 at 08:17:05AM +0800, Zhiyuan Lv wrote:
> 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!

It doesn't matter at all - if the guest unpins the ctx and puts something
else in there before the host tells it that the ctx is completed, that's a
bug in the guest. Same with real hw, we guarantee that the context stays
around for long enough.

Also you obviously have to complete the copying from shadow->guest ctx
before you send the irq to the guest to signal ctx completion. Which means
there's really no overall problem here from a design pov, the only thing
you have to do is fix up bugs in the host code (probably you should just
write through the ggtt).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch