Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts with the default view of hw state.
v2: Unmap our default state from the GTT after stealing it from the
context. This should stop us from accidentally overwriting it via the
GTT (and frees up some precious GTT space).
Testcase: igt/gem_ctx_isolation
Signed-off-by: Chris Wilson <email address hidden>
Cc: Ville Syrjälä <email address hidden>
Cc: Joonas Lahtinen <email address hidden>
Reviewed-by: Joonas Lahtinen <email address hidden>
Link: https://patchwork<email address hidden>
CVE-2020-8832
(backported from commit d2b4b97933f5adacfba42dc3b9200d0e21fbe2c4)
[tyhicks: Backport to 4.15:
- The HAS_LOGICAL_RING_PREEMPTION() macro does not exist because we
don't have commit a4598d17551a ("drm/i915: Rename helpers used for
unwinding, use macro for can_preempt")]
Signed-off-by: Tyler Hicks <email address hidden>
In the next few patches, we will want to both copy out of the context
image and write a valid image into a new context. To be completely safe,
we should then couple in our domain tracking to ensure that we don't
have any issues with stale data remaining in unwanted cachelines.
Historically, we omitted the .write=true from the call to set-gtt-domain
in i915_switch_context() in order to avoid a stall between every request
as we would want to wait for the previous context write from the gpu.
Since then, we limit the set-gtt-domain to only occur when we first bind
the vma, so once in use we will never stall, and we are sure to flush
the context following a load from swap.
Equally we never applied the lessons learnt from ringbuffer submission
to execlists; so time to apply the flush of the lrc after load as well.
Signed-off-by: Chris Wilson <email address hidden>
Cc: Joonas Lahtinen <email address hidden>
Acked-by: Joonas Lahtinen <email address hidden>
Reviewed-by: Mika Kuoppala <email address hidden>
Link: https://patchwork<email address hidden>
intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: Chris Wilson <email address hidden>
Reviewed-by: Joonas Lahtinen <email address hidden>
Reviewed-by: Mika Kuoppala <email address hidden>
Link: https://patchwork<email address hidden>
Despite its name intel_init_clock_gating applies both display clock gating
workarounds; GT mmio workarounds and the occasional GT power context
workaround. Worse, sometimes it includes a context register workaround
which we need to apply before we record the default HW state for all
contexts.
Signed-off-by: Chris Wilson <email address hidden>
Cc: Ville Syrjälä <email address hidden>
Cc: Joonas Lahtinen <email address hidden>
Reviewed-by: Ville Syrjälä <email address hidden>
Link: https://patchwork<email address hidden>
GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: Chris Wilson <email address hidden>
Cc: Ville Syrjälä <email address hidden>
Reviewed-by: Joonas Lahtinen <email address hidden>
Link: https://patchwork<email address hidden>
In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For an extra-layer of finesse, we can check the last
unretired context on the engine; as well as the last retired context
when idle.
v2: verbose verbosity
v3: Always force the switch, even when the engine is idle, and update
the assert that this happens before suspend.
Signed-off-by: Chris Wilson <email address hidden>
Cc: Joonas Lahtinen <email address hidden>
Reviewed-by: Joonas Lahtinen <email address hidden> #v1
Reviewed-by: Mika Kuoppala <email address hidden>
Link: https://patchwork<email address hidden>
We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
engines and internally map onto the hw.
v2: Remove MAX from the uABI; keep it internal if we need it, but don't
let userspace make the mistake of using it themselves.
v3: s/OTHER/INVALID/
The use of OTHER is ill-defined, so remove it from the uABI as any
future new type of engine can define a class to suit it. But keep a
reserved value for an invalid class, so that we can always
unambiguously express when something doesn't belong to the
classification.
During evict, we wish to idle the GPU if we see that the GGTT is full.
However, our test for idle in i915_gem_evict_something() and in
i915_gem_switch_to_kernel_context() do not match leading to
disappointment - we never believe that we are idle and keep trying to
flush the GGTT ad infinitum.
