1. 10 1月, 2020 1 次提交
  2. 09 1月, 2020 1 次提交
  3. 05 1月, 2020 1 次提交
  4. 01 1月, 2020 3 次提交
  5. 24 12月, 2019 2 次提交
  6. 22 12月, 2019 1 次提交
  7. 12 12月, 2019 2 次提交
  8. 09 12月, 2019 7 次提交
  9. 05 12月, 2019 1 次提交
  10. 04 12月, 2019 1 次提交
  11. 27 11月, 2019 1 次提交
  12. 20 11月, 2019 2 次提交
  13. 18 11月, 2019 1 次提交
  14. 16 11月, 2019 3 次提交
  15. 14 11月, 2019 1 次提交
    • I
      drm/i915/gen8+: Add RC6 CTX corruption WA · 2248a283
      Imre Deak 提交于
      In some circumstances the RC6 context can get corrupted. We can detect
      this and take the required action, that is disable RC6 and runtime PM.
      The HW recovers from the corrupted state after a system suspend/resume
      cycle, so detect the recovery and re-enable RC6 and runtime PM.
      
      v2: rebase (Mika)
      v3:
      - Move intel_suspend_gt_powersave() to the end of the GEM suspend
        sequence.
      - Add commit message.
      v4:
      - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API
        change.
      v5:
      - Rebased on latest upstream gt_pm refactoring.
      v6:
      - s/i915_rc6_/intel_rc6_/
      - Don't return a value from i915_rc6_ctx_wa_check().
      v7:
      - Rebased on latest gt rc6 refactoring.
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      [airlied: pull this later version of this patch into drm-next
      to make resolving the conflict mess easier.]
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      2248a283
  16. 12 11月, 2019 3 次提交
  17. 06 11月, 2019 5 次提交
    • I
      drm/i915/gen8+: Add RC6 CTX corruption WA · 7e34f4e4
      Imre Deak 提交于
      In some circumstances the RC6 context can get corrupted. We can detect
      this and take the required action, that is disable RC6 and runtime PM.
      The HW recovers from the corrupted state after a system suspend/resume
      cycle, so detect the recovery and re-enable RC6 and runtime PM.
      
      v2: rebase (Mika)
      v3:
      - Move intel_suspend_gt_powersave() to the end of the GEM suspend
        sequence.
      - Add commit message.
      v4:
      - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API
        change.
      v5: rebased on gem/gt split (Mika)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      7e34f4e4
    • J
      drm/i915/cmdparser: Add support for backward jumps · f8c08d8f
      Jon Bloomfield 提交于
      To keep things manageable, the pre-gen9 cmdparser does not
      attempt to track any form of nested BB_START's. This did not
      prevent usermode from using nested starts, or even chained
      batches because the cmdparser is not strictly enforced pre gen9.
      
      Instead, the existence of a nested BB_START would cause the batch
      to be emitted in insecure mode, and any privileged capabilities
      would not be available.
      
      For Gen9, the cmdparser becomes mandatory (for BCS at least), and
      so not providing any form of nested BB_START support becomes
      overly restrictive. Any such batch will simply not run.
      
      We make heavy use of backward jumps in igt, and it is much easier
      to add support for this restricted subset of nested jumps, than to
      rewrite the whole of our test suite to avoid them.
      
      Add the required logic to support limited backward jumps, to
      instructions that have already been validated by the parser.
      
      Note that it's not sufficient to simply approve any BB_START
      that jumps backwards in the buffer because this would allow an
      attacker to embed a rogue instruction sequence within the
      operand words of a harmless instruction (say LRI) and jump to
      that.
      
      We introduce a bit array to track every instr offset successfully
      validated, and test the target of BB_START against this. If the
      target offset hits, it is re-written to the same offset in the
      shadow buffer and the BB_START cmd is allowed.
      
      Note: This patch deliberately ignores checkpatch issues in the
      cmdtables, in order to match the style of the surrounding code.
      We'll correct the entire file in one go in a later patch.
      
      v2: set dispatch secure late (Mika)
      v3: rebase (Mika)
      v4: Clear whitelist on each parse
          Minor review updates (Chris)
      v5: Correct backward jump batching
      v6: fix compilation error due to struct eb shuffle (Mika)
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Signed-off-by: NJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris.p.wilson@intel.com>
      f8c08d8f
    • J
      drm/i915: Support ro ppgtt mapped cmdparser shadow buffers · 4f7af194
      Jon Bloomfield 提交于
      For Gen7, the original cmdparser motive was to permit limited
      use of register read/write instructions in unprivileged BB's.
      This worked by copying the user supplied bb to a kmd owned
      bb, and running it in secure mode, from the ggtt, only if
      the scanner finds no unsafe commands or registers.
      
      For Gen8+ we can't use this same technique because running bb's
      from the ggtt also disables access to ppgtt space. But we also
      do not actually require 'secure' execution since we are only
      trying to reduce the available command/register set. Instead we
      will copy the user buffer to a kmd owned read-only bb in ppgtt,
      and run in the usual non-secure mode.
      
      Note that ro pages are only supported by ppgtt (not ggtt), but
      luckily that's exactly what we need.
      
      Add the required paths to map the shadow buffer to ppgtt ro for Gen8+
      
      v2: IS_GEN7/IS_GEN (Mika)
      v3: rebase
      v4: rebase
      v5: rebase
      Signed-off-by: NJon Bloomfield <jon.bloomfield@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris.p.wilson@intel.com>
      4f7af194
    • J
      drm/i915: Remove Master tables from cmdparser · 66d8aba1
      Jon Bloomfield 提交于
      The previous patch has killed support for secure batches
      on gen6+, and hence the cmdparsers master tables are
      now dead code. Remove them.
      Signed-off-by: NJon Bloomfield <jon.bloomfield@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Reviewed-by: NChris Wilson <chris.p.wilson@intel.com>
      66d8aba1
    • J
      drm/i915: Disable Secure Batches for gen6+ · 44157641
      Jon Bloomfield 提交于
      Retroactively stop reporting support for secure batches
      through the api for gen6+ so that older binaries trigger
      the fallback path instead.
      
      Older binaries use secure batches pre gen6 to access resources
      that are not available to normal usermode processes. However,
      all known userspace explicitly checks for HAS_SECURE_BATCHES
      before relying on the secure batch feature.
      
      Since there are no known binaries relying on this for newer gens
      we can kill secure batches from gen6, via I915_PARAM_HAS_SECURE_BATCHES.
      
      v2: rebase (Mika)
      v3: rebase (Mika)
      Signed-off-by: NJon Bloomfield <jon.bloomfield@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris.p.wilson@intel.com>
      44157641
  18. 05 11月, 2019 1 次提交
  19. 01 11月, 2019 3 次提交