On Fri, Feb 27, 2015 at 01:40:18PM +0000, Michel Thierry wrote: > From: Ben Widawsky <benjamin.widawsky@xxxxxxxxx> > > The problem is we're going to switch to a new context, which could be > the default context. The plan was to use restore inhibit, which would be > fine, except if we are using dynamic page tables (which we will). If we > use dynamic page tables and we don't load new page tables, the previous > page tables might go away, and future operations will fault. > > CTXA runs. > switch to default, restore inhibit > CTXA dies and has its address space taken away. > Run CTXB, tries to save using the context A's address space - this > fails. > > The general solution is to make sure every context has it's own state, > and its own address space. For cases when we must restore inhibit, first > thing we do is load a valid address space. I thought this would be > enough, but apparently there are references within the context itself > which will refer to the old address space - therefore, we also must > reinitialize. > > It was tricky to track this down as we don't have much insight into what > happens in a context save. > > This is required for the next patch which enables dynamic page tables. This sneaks in a major change that is not mentioned at all above. Namely: > @@ -744,7 +747,7 @@ static int do_switch(struct intel_engine_cs *ring, > i915_gem_context_unreference(from); > } > > - uninitialized = !to->legacy_hw_ctx.initialized && from == NULL; > + uninitialized = !to->legacy_hw_ctx.initialized; > to->legacy_hw_ctx.initialized = true; That has nothing to do with VM spaces, but with w/a that need to be applied to the context image. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
