On Thu, 2021-08-26 at 14:04 +0100, Tvrtko Ursulin wrote:
On 26/08/2021 11:45, Thomas Hellström wrote:
Pinned contexts, like the migrate contexts need reset after resume since their context image may have been lost. Also the GuC needs to register pinned contexts.
So kernel context can get corrupt because we park the GPU with it active. Blitter context for a different reason - which is that it is used to copy itself over to smem, no?
If that is correct, then why bother copying the blitter context in the first place and not just always re-create it on resume?
That would be along the lines of marking the backing store as "dontneed" (however the exact mechanics of that look these days) so suspend can skip them.
I think that is marking the object with I915_BO_ALLOC_VOLATILE. However I assume this follows the rule of the internal backend objects: Contents are valid while pinned (or locked), and these images are indeed pinned on suspend so we need to come up with something else. Perhaps I915_BO_ALLOC_PM_NOSAVE for the context images (and engine status pages?) I915_BO_ALLOC_PM_MEMCPY for the migrate vm pagetables only. The latter will come in handy also for supporting small apertures where we need to pin these in the mappable area.
Add a list to struct intel_engine_cs where we add all pinned contexts on creation, and traverse that list at resume time to reset the pinned contexts.
This fixes the kms_pipe_crc_basic@suspend-read-crc-pipe-a selftest for now, but proper LMEM backup / restore is needed for full suspend functionality. However, note that even with full LMEM backup / restore it may be desirable to keep the reset since backing up the migrate context images must happen using memcpy() after the migrate context has become inactive, and for performance- and other reasons we want to avoid memcpy() from LMEM.
Hm I guess this talks about the issue - so are these images migrated at all today or not?
My current WIP backs them up. But with something like the above flags, that's easily changed. Suggestions welcome.
/Thomas