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 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. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx