[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dpt: Use shmem for dpt objects (rev2)

2023-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915/dpt: Use shmem for dpt objects (rev2)
URL   : https://patchwork.freedesktop.org/series/120885/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13394_full -> Patchwork_120885v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_120885v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_120885v2_full, please notify your bug team to allow 
them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120885v2_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-snb:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-snb7/igt@gem_exec_whis...@basic-contexts-forked-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb7/igt@gem_exec_whis...@basic-contexts-forked-all.html

  * igt@kms_flip@blocking-wf_vblank@b-vga1:
- shard-snb:  NOTRUN -> [ABORT][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb7/igt@kms_flip@blocking-wf_vbl...@b-vga1.html

  
New tests
-

  New tests have been introduced between CI_DRM_13394_full and 
Patchwork_120885v2_full:

### New IGT tests (106) ###

  * igt@api_intel_bb@blit-noreloc-keep-cache:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@blit-noreloc-purge-cache:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@blit-reloc-keep-cache:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@blit-reloc-purge-cache:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@full-batch:
- Statuses : 7 pass(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@intel-bb-blit-none:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@intel-bb-blit-x:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@intel-bb-blit-y:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@offset-control:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@simple-bb:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@api_intel_bb@simple-bb-ctx:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_param@invalid-get-engines:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_param@invalid-get-no-zeromap:
- Statuses : 7 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_param@invalid-get-ringsize:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_param@invalid-set-no-zeromap:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_param@invalid-set-ringsize:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@gem_pread@bench:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0] s

  * igt@i915_selftest@live@gem_migrate:
- Statuses : 8 pass(s)
- Exec time: [0.0] s

  * igt@kms_async_flips@test-cursor@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_async_flips@test-cursor@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_async_flips@test-cursor@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_async_flips@test-cursor@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_concurrent@pipe-c@hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_cursor_crc@cursor-alpha-opaque@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_cursor_crc@cursor-alpha-opaque@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_dither@fb-8bpc-vs-panel-8bpc:
- Statuses : 3 skip(s)
- Exec time: [0.0] s

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@plain-flip-ts-check@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@plain-flip-ts-check@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec 

[Intel-gfx] ✗ Fi.CI.IGT: failure for Reduce MTL-specific platform checks

2023-07-18 Thread Patchwork
== Series Details ==

Series: Reduce MTL-specific platform checks
URL   : https://patchwork.freedesktop.org/series/120943/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13394_full -> Patchwork_120943v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_120943v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_120943v1_full, please notify your bug team to allow 
them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120943v1_full:

### IGT changes ###

 Possible regressions 

  * 
igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-2:
- shard-rkl:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-1/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0...@pipe-a-hdmi-a-2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-rkl-1/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0...@pipe-a-hdmi-a-2.html

  
Known issues


  Here are the changes found in Patchwork_120943v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@idempotent:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-snb5/igt@gem_ctx_persiste...@idempotent.html

  * igt@gem_exec_capture@pi@ccs0:
- shard-mtlp: [PASS][4] -> [FAIL][5] ([i915#7765])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-2/igt@gem_exec_capture@p...@ccs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-mtlp-3/igt@gem_exec_capture@p...@ccs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-rkl:  [PASS][6] -> [FAIL][7] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-6/igt@gem_exec_f...@basic-deadline.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-rkl-2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-rkl:  NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-rkl-7/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-rkl-6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-rkl:  NOTRUN -> [SKIP][11] ([fdo#112283])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-rkl-7/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_exec_reloc@basic-gtt-read:
- shard-rkl:  NOTRUN -> [SKIP][12] ([i915#3281]) +2 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-rkl-7/igt@gem_exec_re...@basic-gtt-read.html

  * igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [PASS][13] -> [ABORT][14] ([i915#8131])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-1/igt@gem_exec_whis...@basic-contexts-forked-all.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-mtlp-1/igt@gem_exec_whis...@basic-contexts-forked-all.html

  * igt@gem_lmem_swapping@basic:
- shard-rkl:  NOTRUN -> [SKIP][15] ([i915#4613])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-rkl-7/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-apl6/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@smem-oom@lmem0:
- shard-dg2:  [PASS][17] -> [TIMEOUT][18] ([i915#5493])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-10/igt@gem_lmem_swapping@smem-...@lmem0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-dg2-10/igt@gem_lmem_swapping@smem-...@lmem0.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/shard-apl6/igt@gem_pwr...@basic-exhaustion.html

  * 

[Intel-gfx] ✓ Fi.CI.IGT: success for Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()

2023-07-18 Thread Patchwork
== Series Details ==

Series: Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()
URL   : https://patchwork.freedesktop.org/series/120940/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13394_full -> Patchwork_120940v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/index.html

Participating hosts (10 -> 9)
--

  Missing(1): pig-kbl-iris 

Known issues


  Here are the changes found in Patchwork_120940v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-apl:  NOTRUN -> [ABORT][1] ([i915#7461] / [i915#8211] / 
[i915#8234])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-apl1/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_create@create-ext-set-pat:
- shard-snb:  NOTRUN -> [FAIL][2] ([i915#8621])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-snb1/igt@gem_cre...@create-ext-set-pat.html

  * igt@gem_ctx_persistence@idempotent:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-snb5/igt@gem_ctx_persiste...@idempotent.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-apl:  [PASS][4] -> [TIMEOUT][5] ([i915#3063])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-apl3/igt@gem_...@in-flight-contexts-1us.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-apl4/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_exec_fair@basic-deadline:
- shard-rkl:  [PASS][6] -> [FAIL][7] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-6/igt@gem_exec_f...@basic-deadline.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-rkl-6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-rkl:  NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-rkl-7/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@bcs0:
- shard-rkl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +3 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-7/igt@gem_exec_fair@basic-n...@bcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-rkl-7/igt@gem_exec_fair@basic-n...@bcs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-rkl:  NOTRUN -> [SKIP][11] ([fdo#112283])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-rkl-7/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_exec_reloc@basic-gtt-read:
- shard-rkl:  NOTRUN -> [SKIP][12] ([i915#3281]) +2 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-rkl-7/igt@gem_exec_re...@basic-gtt-read.html

  * igt@gem_exec_reloc@basic-wc-gtt-active:
- shard-mtlp: NOTRUN -> [SKIP][13] ([i915#3281])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-mtlp-2/igt@gem_exec_re...@basic-wc-gtt-active.html

  * igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [PASS][14] -> [ABORT][15] ([i915#8131])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-1/igt@gem_exec_whis...@basic-contexts-forked-all.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-mtlp-5/igt@gem_exec_whis...@basic-contexts-forked-all.html

  * igt@gem_lmem_swapping@basic:
- shard-rkl:  NOTRUN -> [SKIP][16] ([i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-rkl-7/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-apl1/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@smem-oom@lmem0:
- shard-dg2:  [PASS][18] -> [DMESG-WARN][19] ([i915#4936] / 
[i915#5493])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-10/igt@gem_lmem_swapping@smem-...@lmem0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-dg2-2/igt@gem_lmem_swapping@smem-...@lmem0.html

  * igt@gem_pxp@reject-modify-context-protection-off-2:
- shard-mtlp: NOTRUN -> [SKIP][20] ([i915#4270])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/shard-mtlp-2/igt@gem_...@reject-modify-context-protection-off-2.html

  * igt@gem_render_copy@y-tiled-ccs-to-y-tiled-mc-ccs:
- shard-mtlp: NOTRUN -> [SKIP][21] ([i915#8428]) +1 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dpt: Use shmem for dpt objects (rev2)

2023-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915/dpt: Use shmem for dpt objects (rev2)
URL   : https://patchwork.freedesktop.org/series/120885/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13394 -> Patchwork_120885v2


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/index.html

Participating hosts (44 -> 42)
--

  Missing(2): fi-kbl-soraka fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120885v2:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@debugfs_test@read_all_entries:
- {bat-dg2-13}:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-13/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-dg2-13/igt@debugfs_test@read_all_entries.html

  
Known issues


  Here are the changes found in Patchwork_120885v2 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- bat-adlp-11:NOTRUN -> [ABORT][3] ([i915#4423] / [i915#6868])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-adlp-11/igt@debugfs_test@read_all_entries.html

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u:   [PASS][4] -> [FAIL][5] ([i915#7940])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
- fi-kbl-7567u:   [PASS][6] -> [FAIL][7] ([i915#7940])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-8: [PASS][8] -> [DMESG-FAIL][9] ([i915#7059])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
- bat-mtlp-6: [PASS][10] -> [DMESG-FAIL][11] ([i915#7059])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@requests:
- bat-rpls-2: [PASS][12] -> [ABORT][13] ([i915#4983] / [i915#7913])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-rpls-2/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-n3050:   NOTRUN -> [SKIP][14] ([fdo#109271])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_psr@primary_page_flip:
- bat-rplp-1: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-rplp-1/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [ABORT][16] ([i915#8260] / [i915#8668])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_module_load@load:
- bat-adlp-11:[ABORT][17] ([i915#4423]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-adlp-11/igt@i915_module_l...@load.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-adlp-11/igt@i915_module_l...@load.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-x1275:   [SKIP][19] ([fdo#109271]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-guc: [FAIL][21] ([i915#7940]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-guc/igt@i915_pm_...@basic-rte.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-cfl-guc/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [ABORT][23] ([i915#7911] / [i915#7913]) -> [PASS][24]
   [23]: 

Re: [Intel-gfx] [PATCH 11/11] drm/i915/perf: Wa_14017512683: Disable OAM if media C6 is enabled in BIOS

2023-07-18 Thread Dixit, Ashutosh
On Tue, 18 Jul 2023 12:49:47 -0700, Matt Roper wrote:
>

Hi Matt,

> On Thu, Mar 23, 2023 at 03:59:01PM -0700, Umesh Nerlige Ramappa wrote:
> > OAM does not work with media C6 enabled on some steppings of MTL.
>
> I just stumbled across this while looking at something else, but
> 14017512683 isn't a valid workaround number; that's just a per-platform
> identifier associated with Wa_18023884638.  The actual Wa_18023884638
> applies not only to MTL, but also to DG2 which it looks like we're not
> handling below.

Thanks for letting us know about this. You're right, all our (our team's)
WA numbers are a complete horror show, we'll need to do something about it.

Ashutosh


[Intel-gfx] ✓ Fi.CI.BAT: success for Reduce MTL-specific platform checks

2023-07-18 Thread Patchwork
== Series Details ==

Series: Reduce MTL-specific platform checks
URL   : https://patchwork.freedesktop.org/series/120943/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13394 -> Patchwork_120943v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/index.html

Participating hosts (44 -> 43)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120943v1:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@debugfs_test@read_all_entries:
- {bat-dg2-13}:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-13/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/bat-dg2-13/igt@debugfs_test@read_all_entries.html

  
Known issues


  Here are the changes found in Patchwork_120943v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u:   [PASS][3] -> [FAIL][4] ([i915#7940])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@requests:
- bat-dg2-11: [PASS][5] -> [ABORT][6] ([i915#7913])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-11/igt@i915_selftest@l...@requests.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/bat-dg2-11/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-mtlp-6: [PASS][7] -> [DMESG-WARN][8] ([i915#6367])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/bat-mtlp-6/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-kbl-7567u:   [PASS][9] -> [INCOMPLETE][10] ([i915#4817])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-7567u/igt@i915_susp...@basic-s3-without-i915.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/fi-kbl-7567u/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][11] ([i915#7828])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- fi-bsw-n3050:   NOTRUN -> [SKIP][12] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][13] ([i915#1845])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-8700k:   [FAIL][14] ([i915#7940]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html
- fi-skl-guc: [FAIL][16] ([i915#7940]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-x1275:   [SKIP][18] ([fdo#109271]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-tgl-1115g4:  [FAIL][20] ([i915#7940]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [ABORT][22] ([i915#7911] / [i915#7913]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120943v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Reduce MTL-specific platform checks

2023-07-18 Thread Patchwork
== Series Details ==

Series: Reduce MTL-specific platform checks
URL   : https://patchwork.freedesktop.org/series/120943/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Reduce MTL-specific platform checks

2023-07-18 Thread Patchwork
== Series Details ==

Series: Reduce MTL-specific platform checks
URL   : https://patchwork.freedesktop.org/series/120943/
State : warning

== Summary ==

Error: dim checkpatch failed
c3afd0a4c654 drm/i915: Consolidate condition for Wa_22011802037
448c3a48c6f6 drm/i915/xelpg: Call Xe_LPG workaround functions based on IP 
version
-:154: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt' - possible side-effects?
#154: FILE: drivers/gpu/drm/i915/i915_drv.h:434:
+#define GT_GRAPHICS_RANGE(gt, from, until) \
+   (BUILD_BUG_ON_ZERO(from < IP_VER(2, 0)) + \
+((gt)->type != GT_MEDIA && \
+ (GRAPHICS_VER_FULL((gt)->i915) >= (from) && 
GRAPHICS_VER_FULL((gt)->i915) <= (until

-:154: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'from' - possible 
side-effects?
#154: FILE: drivers/gpu/drm/i915/i915_drv.h:434:
+#define GT_GRAPHICS_RANGE(gt, from, until) \
+   (BUILD_BUG_ON_ZERO(from < IP_VER(2, 0)) + \
+((gt)->type != GT_MEDIA && \
+ (GRAPHICS_VER_FULL((gt)->i915) >= (from) && 
GRAPHICS_VER_FULL((gt)->i915) <= (until

-:154: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'from' may be better as 
'(from)' to avoid precedence issues
#154: FILE: drivers/gpu/drm/i915/i915_drv.h:434:
+#define GT_GRAPHICS_RANGE(gt, from, until) \
+   (BUILD_BUG_ON_ZERO(from < IP_VER(2, 0)) + \
+((gt)->type != GT_MEDIA && \
+ (GRAPHICS_VER_FULL((gt)->i915) >= (from) && 
GRAPHICS_VER_FULL((gt)->i915) <= (until

total: 0 errors, 0 warnings, 3 checks, 116 lines checked
e99db64725a5 drm/i915: Eliminate IS_MTL_GRAPHICS_STEP
-:292: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__gt' - possible 
side-effects?
#292: FILE: drivers/gpu/drm/i915/i915_drv.h:695:
+#define IS_GFX_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(2, 0)) + \
+(__gt->type != GT_MEDIA && \
+ GRAPHICS_VER_FULL(__gt->i915) == ipver && \
+ IS_GRAPHICS_STEP(__gt->i915, since, until)))

-:292: CHECK:MACRO_ARG_PRECEDENCE: Macro argument '__gt' may be better as 
'(__gt)' to avoid precedence issues
#292: FILE: drivers/gpu/drm/i915/i915_drv.h:695:
+#define IS_GFX_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(2, 0)) + \
+(__gt->type != GT_MEDIA && \
+ GRAPHICS_VER_FULL(__gt->i915) == ipver && \
+ IS_GRAPHICS_STEP(__gt->i915, since, until)))

-:292: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ipver' - possible 
side-effects?
#292: FILE: drivers/gpu/drm/i915/i915_drv.h:695:
+#define IS_GFX_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(2, 0)) + \
+(__gt->type != GT_MEDIA && \
+ GRAPHICS_VER_FULL(__gt->i915) == ipver && \
+ IS_GRAPHICS_STEP(__gt->i915, since, until)))

-:292: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'ipver' may be better as 
'(ipver)' to avoid precedence issues
#292: FILE: drivers/gpu/drm/i915/i915_drv.h:695:
+#define IS_GFX_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(2, 0)) + \
+(__gt->type != GT_MEDIA && \
+ GRAPHICS_VER_FULL(__gt->i915) == ipver && \
+ IS_GRAPHICS_STEP(__gt->i915, since, until)))

total: 0 errors, 0 warnings, 4 checks, 227 lines checked
57e068abc2d6 drm/i915: Eliminate IS_MTL_MEDIA_STEP
-:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__gt' - possible 
side-effects?
#46: FILE: drivers/gpu/drm/i915/i915_drv.h:701:
+#define IS_MEDIA_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(13, 0)) + \
+(__gt && __gt->type == GT_MEDIA && \
+ MEDIA_VER_FULL(__gt->i915) == ipver && \
+ IS_MEDIA_STEP(__gt->i915, since, until)))

-:46: CHECK:MACRO_ARG_PRECEDENCE: Macro argument '__gt' may be better as 
'(__gt)' to avoid precedence issues
#46: FILE: drivers/gpu/drm/i915/i915_drv.h:701:
+#define IS_MEDIA_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(13, 0)) + \
+(__gt && __gt->type == GT_MEDIA && \
+ MEDIA_VER_FULL(__gt->i915) == ipver && \
+ IS_MEDIA_STEP(__gt->i915, since, until)))

-:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ipver' - possible 
side-effects?
#46: FILE: drivers/gpu/drm/i915/i915_drv.h:701:
+#define IS_MEDIA_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(13, 0)) + \
+(__gt && __gt->type == GT_MEDIA && \
+ MEDIA_VER_FULL(__gt->i915) == ipver && \
+ IS_MEDIA_STEP(__gt->i915, since, until)))

-:46: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'ipver' may be better as 
'(ipver)' to avoid precedence issues
#46: FILE: drivers/gpu/drm/i915/i915_drv.h:701:
+#define IS_MEDIA_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(13, 0)) + \
+(__gt && __gt->type == GT_MEDIA && \
+ MEDIA_VER_FULL(__gt->i915) == ipver && \
+ IS_MEDIA_STEP(__gt->i915, since, until)))

total: 0 errors, 0 warnings, 4 checks, 56 lines checked
5fbebe56cfed 

[Intel-gfx] ✓ Fi.CI.BAT: success for Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()

2023-07-18 Thread Patchwork
== Series Details ==

Series: Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()
URL   : https://patchwork.freedesktop.org/series/120940/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13394 -> Patchwork_120940v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/index.html

Participating hosts (44 -> 43)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120940v1:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@debugfs_test@read_all_entries:
- {bat-dg2-13}:   [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-13/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-dg2-13/igt@debugfs_test@read_all_entries.html

  
Known issues


  Here are the changes found in Patchwork_120940v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#7456])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_tiled_pread_basic:
- bat-adlp-11:NOTRUN -> [SKIP][4] ([i915#3282])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-adlp-11/igt@gem_tiled_pread_basic.html

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-8: [PASS][5] -> [DMESG-FAIL][6] ([i915#7059])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#4983] / [i915#7911] / 
[i915#7920])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][9] ([i915#6367])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@i915_selftest@live@workarounds:
- bat-mtlp-6: [PASS][10] -> [DMESG-FAIL][11] ([i915#6763])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-6/igt@i915_selftest@l...@workarounds.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-mtlp-6/igt@i915_selftest@l...@workarounds.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][12] ([i915#6687] / [i915#7978] / 
[i915#8668])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- bat-adlp-11:NOTRUN -> [SKIP][13] ([i915#7828]) +7 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-adlp-11/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-n3050:   NOTRUN -> [SKIP][14] ([fdo#109271])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-11:NOTRUN -> [SKIP][15] ([i915#4103]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-11:NOTRUN -> [SKIP][16] ([i915#4093]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_frontbuffer_tracking@basic:
- bat-adlp-11:NOTRUN -> [ABORT][17] ([i915#4423])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-adlp-11/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_psr@primary_page_flip:
- bat-rplp-1: NOTRUN -> [ABORT][18] ([i915#8860])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120940v1/bat-rplp-1/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_module_load@load:
- bat-adlp-11:[ABORT][19] ([i915#4423]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-adlp-11/igt@i915_module_l...@load.html
   [20]: 

[Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects

2023-07-18 Thread Radhakrishna Sripada
Dpt objects that are created from internal get evicted when there is
memory pressure and do not get restored when pinned during scanout. The
pinned page table entries look corrupted and programming the display
engine with the incorrect pte's result in DE throwing pipe faults.

Create DPT objects from shmem and mark the object as dirty when pinning so
that the object is restored when shrinker evicts an unpinned buffer object.

v2: Unconditionally mark the dpt objects dirty during pinning(Chris).

Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
Cc:  # v6.0+
Cc: Ville Syrjälä 
Cc: Tvrtko Ursulin 
Suggested-by: Chris Wilson 
Signed-off-by: Fei Yang 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 7c5fddb203ba..fbfd8f959f17 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
i915_vma_get(vma);
}
 
+   dpt->obj->mm.dirty = true;
+
atomic_dec(>gpu_error.pending_fb_pin);
intel_runtime_pm_put(>runtime_pm, wakeref);
 
@@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
dpt_obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
drm_dbg_kms(>drm, "Allocating dpt from smem\n");
-   dpt_obj = i915_gem_object_create_internal(i915, size);
+   dpt_obj = i915_gem_object_create_shmem(i915, size);
}
if (IS_ERR(dpt_obj))
return ERR_CAST(dpt_obj);
-- 
2.34.1



[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume

2023-07-18 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Avoid endless HPD poll detect loop 
via runtime suspend/resume
URL   : https://patchwork.freedesktop.org/series/120931/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13394_full -> Patchwork_120931v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_120931v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_120931v1_full, please notify your bug team to allow 
them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (10 -> 9)
--

  Missing(1): pig-kbl-iris 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120931v1_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@system-suspend-devices:
- shard-mtlp: [PASS][1] -> [ABORT][2] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-2/igt@i915_pm_...@system-suspend-devices.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-mtlp-8/igt@i915_pm_...@system-suspend-devices.html

  * igt@i915_pm_rpm@system-suspend-modeset:
- shard-dg2:  [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-8/igt@i915_pm_...@system-suspend-modeset.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-dg2-7/igt@i915_pm_...@system-suspend-modeset.html
- shard-tglu: [PASS][5] -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-9/igt@i915_pm_...@system-suspend-modeset.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-tglu-7/igt@i915_pm_...@system-suspend-modeset.html

  
Known issues


  Here are the changes found in Patchwork_120931v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-ext-set-pat:
- shard-snb:  NOTRUN -> [FAIL][7] ([i915#8621])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-snb4/igt@gem_cre...@create-ext-set-pat.html

  * igt@gem_ctx_persistence@idempotent:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-snb2/igt@gem_ctx_persiste...@idempotent.html

  * igt@gem_exec_fair@basic-deadline:
- shard-rkl:  [PASS][9] -> [FAIL][10] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-6/igt@gem_exec_f...@basic-deadline.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-rkl-6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-rkl:  NOTRUN -> [FAIL][11] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-rkl-7/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-rkl:  NOTRUN -> [SKIP][14] ([fdo#112283])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-rkl-7/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_exec_reloc@basic-gtt-read:
- shard-rkl:  NOTRUN -> [SKIP][15] ([i915#3281]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-rkl-7/igt@gem_exec_re...@basic-gtt-read.html

  * igt@gem_exec_reloc@basic-wc-gtt-active:
- shard-mtlp: NOTRUN -> [SKIP][16] ([i915#3281])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-mtlp-2/igt@gem_exec_re...@basic-wc-gtt-active.html

  * igt@gem_lmem_swapping@basic:
- shard-rkl:  NOTRUN -> [SKIP][17] ([i915#4613])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-rkl-7/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-apl1/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/shard-apl1/igt@gem_pwr...@basic-exhaustion.html

  * 

[Intel-gfx] [PATCH 2/8] drm/i915/xelpg: Call Xe_LPG workaround functions based on IP version

2023-07-18 Thread Matt Roper
Although some of our Xe_LPG workarounds were already being applied based
on IP version correctly, others were matching on MTL as a base platform,
which is incorrect.  Although MTL is the only platform right now that
uses Xe_LPG IP, this may not always be the case.  If a future platform
re-uses this graphics IP, the same workarounds should be applied, even
if it isn't a "MTL" platform.

We were also incorrectly applying Xe_LPG workarounds/tuning to the
Xe_LPM+ media IP in one or two places; we should make sure that we don't
try to apply graphics workarounds to the media GT and vice versa where
they don't belong.  A new helper macro GT_GRAPHICS_RANGE() is added to
help ensure this is handled properly -- it checks both the graphics
version range and that the code isn't operating on a media GT.

Note that many of the stepping-based workarounds are still incorrectly
checking for a MTL base platform; that will be remedied in a later
patch.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 40 +++--
 drivers/gpu/drm/i915/i915_drv.h |  5 +++
 2 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index b177c588698b..2a5bf50962ad 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -805,8 +805,8 @@ static void dg2_ctx_workarounds_init(struct intel_engine_cs 
*engine,
wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE);
 }
 
-static void mtl_ctx_gt_tuning_init(struct intel_engine_cs *engine,
-  struct i915_wa_list *wal)
+static void xelpg_ctx_gt_tuning_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
 {
struct drm_i915_private *i915 = engine->i915;
 
@@ -817,12 +817,12 @@ static void mtl_ctx_gt_tuning_init(struct intel_engine_cs 
*engine,
wa_add(wal, DRAW_WATERMARK, VERT_WM_VAL, 0x3FF, 0, false);
 }
 
-static void mtl_ctx_workarounds_init(struct intel_engine_cs *engine,
-struct i915_wa_list *wal)
+static void xelpg_ctx_workarounds_init(struct intel_engine_cs *engine,
+  struct i915_wa_list *wal)
 {
struct drm_i915_private *i915 = engine->i915;
 
-   mtl_ctx_gt_tuning_init(engine, wal);
+   xelpg_ctx_gt_tuning_init(engine, wal);
 
if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
@@ -931,8 +931,8 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
if (engine->class != RENDER_CLASS)
goto done;
 
-   if (IS_METEORLAKE(i915))
-   mtl_ctx_workarounds_init(engine, wal);
+   if (GT_GRAPHICS_RANGE(engine->gt, IP_VER(12, 70), IP_VER(12, 71)))
+   xelpg_ctx_workarounds_init(engine, wal);
else if (IS_PONTEVECCHIO(i915))
; /* noop; none at this time */
else if (IS_DG2(i915))
@@ -1790,10 +1790,8 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt, struct 
i915_wa_list *wal)
  */
 static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list *wal)
 {
-   if (IS_METEORLAKE(gt->i915)) {
-   if (gt->type != GT_MEDIA)
-   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
BLEND_FILL_CACHING_OPT_DIS);
-
+   if (GT_GRAPHICS_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71))) {
+   wa_mcr_write_or(wal, XEHP_L3SCQREG7, 
BLEND_FILL_CACHING_OPT_DIS);
wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
}
 
@@ -1817,7 +1815,7 @@ gt_init_workarounds(struct intel_gt *gt, struct 
i915_wa_list *wal)
gt_tuning_settings(gt, wal);
 
if (gt->type == GT_MEDIA) {
-   if (MEDIA_VER(i915) >= 13)
+   if (MEDIA_VER(i915) == 13)
xelpmp_gt_workarounds_init(gt, wal);
else
MISSING_CASE(MEDIA_VER(i915));
@@ -1825,7 +1823,7 @@ gt_init_workarounds(struct intel_gt *gt, struct 
i915_wa_list *wal)
return;
}
 
-   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   if (GT_GRAPHICS_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)))
xelpg_gt_workarounds_init(gt, wal);
else if (IS_PONTEVECCHIO(i915))
pvc_gt_workarounds_init(gt, wal);
@@ -2293,7 +2291,7 @@ static void pvc_whitelist_build(struct intel_engine_cs 
*engine)
blacklist_trtt(engine);
 }
 
-static void mtl_whitelist_build(struct intel_engine_cs *engine)
+static void xelpg_whitelist_build(struct intel_engine_cs *engine)
 {
struct i915_wa_list *w = >whitelist;
 
@@ -2315,8 +2313,10 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
*engine)
 
wa_init_start(w, engine->gt, "whitelist", engine->name);
 
-   if (IS_METEORLAKE(i915))
-   

[Intel-gfx] [PATCH 5/8] drm/i915: Eliminate IS_MTL_DISPLAY_STEP

2023-07-18 Thread Matt Roper
Stepping-specific display behavior shouldn't be tied to MTL as a
platform, but rather specifically to the Xe_LPM+ IP.  Future non-MTL
platforms may re-use this IP and will need to follow the exact same
logic and apply the same workarounds.  IS_MTL_DISPLAY_STEP() is dropped
in favor of a new macro IS_DISPLAY_IPVER_STEP() that only checks the
display IP version.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_display_device.h |  5 +
 drivers/gpu/drm/i915/display/intel_fbc.c|  3 ++-
 drivers/gpu/drm/i915/display/intel_pmdemand.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_psr.c| 10 +-
 drivers/gpu/drm/i915/i915_drv.h |  6 ++
 5 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h 
b/drivers/gpu/drm/i915/display/intel_display_device.h
index 3324bd453ca7..d8dccf7f1b5f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.h
+++ b/drivers/gpu/drm/i915/display/intel_display_device.h
@@ -71,6 +71,11 @@ struct drm_printer;
 #define OVERLAY_NEEDS_PHYSICAL(i915)   
(DISPLAY_INFO(i915)->overlay_needs_physical)
 #define SUPPORTS_TV(i915)  (DISPLAY_INFO(i915)->supports_tv)
 
+#define IS_DISPLAY_IPVER_STEP(__i915, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(2, 0)) + \
+DISPLAY_VER_FULL(__i915) == ipver && \
+IS_DISPLAY_STEP(__i915, since, until))
+
 struct intel_display_runtime_info {
struct {
u16 ver;
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 7f8b2d7713c7..a3a42e29b766 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -49,6 +49,7 @@
 #include "i915_vgpu.h"
 #include "intel_cdclk.h"
 #include "intel_de.h"
+#include "intel_display_device.h"
 #include "intel_display_trace.h"
 #include "intel_display_types.h"
 #include "intel_fbc.h"
@@ -1093,7 +1094,7 @@ static int intel_fbc_check_plane(struct 
intel_atomic_state *state,
 
/* Wa_14016291713 */
if ((IS_DISPLAY_VER(i915, 12, 13) ||
-IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
+IS_DISPLAY_IPVER_STEP(i915, IP_VER(14, 0), STEP_A0, STEP_C0)) &&
crtc_state->has_psr) {
plane_state->no_fbc_reason = "PSR1 enabled (Wa_14016291713)";
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_pmdemand.c 
b/drivers/gpu/drm/i915/display/intel_pmdemand.c
index f7608d363634..3b37beedc95c 100644
--- a/drivers/gpu/drm/i915/display/intel_pmdemand.c
+++ b/drivers/gpu/drm/i915/display/intel_pmdemand.c
@@ -92,7 +92,7 @@ int intel_pmdemand_init(struct drm_i915_private *i915)
 _state->base,
 _pmdemand_funcs);
 
-   if (IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
+   if (IS_DISPLAY_IPVER_STEP(i915, IP_VER(14, 0), STEP_A0, STEP_C0))
/* Wa_14016740474 */
intel_de_rmw(i915, XELPD_CHICKEN_DCPR_3, 0, 
DMD_RSP_TIMEOUT_DISABLE);
 
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 04ab034a8d57..5770cbfef435 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1360,7 +1360,7 @@ static void wm_optimization_wa(struct intel_dp *intel_dp,
bool set_wa_bit = false;
 
/* Wa_14015648006 */
-   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
+   if (IS_DISPLAY_IPVER_STEP(dev_priv, IP_VER(14, 0), STEP_A0, STEP_B0) ||
IS_DISPLAY_VER(dev_priv, 11, 13))
set_wa_bit |= crtc_state->wm_level_disabled;
 
@@ -1447,7 +1447,7 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 * All supported adlp panels have 1-based X granularity, this 
may
 * cause issues if non-supported panels are used.
 */
-   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
+   if (IS_DISPLAY_IPVER_STEP(dev_priv, IP_VER(14, 0), STEP_A0, 
STEP_B0))
intel_de_rmw(dev_priv, 
MTL_CHICKEN_TRANS(cpu_transcoder), 0,
 ADLP_1_BASED_X_GRANULARITY);
else if (IS_ALDERLAKE_P(dev_priv))
@@ -1455,7 +1455,7 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 ADLP_1_BASED_X_GRANULARITY);
 
/* Wa_16012604467:adlp,mtl[a0,b0] */
-   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
+   if (IS_DISPLAY_IPVER_STEP(dev_priv, IP_VER(14, 0), STEP_A0, 
STEP_B0))
intel_de_rmw(dev_priv,
 MTL_CLKGATE_DIS_TRANS(cpu_transcoder), 0,
 MTL_CLKGATE_DIS_TRANS_DMASC_GATING_DIS);
@@ -1613,7 +1613,7 @@ static void intel_psr_disable_locked(struct 

[Intel-gfx] [PATCH 7/8] drm/i915/display: Eliminate IS_METEORLAKE checks

2023-07-18 Thread Matt Roper
Most of the IS_METEORLAKE checks in the display code shouldn't actually
be tied to MTL as a platform, but rather to the Xe_LPD+ display IP
(which is used in MTL, but may show up again in future platforms).  In
cases where we're trying to match that specific IP, use a version check
against IP_VER(14, 0).  For cases where we're just handling new behavior
introduced by this IP (but which may also be inherited by future IP as
well), use a ver >= 14 check.

The one exception here is the stolen memory workaround Wa_13010847436
(which is mislabelled as "Wa_22018444074" in the code).  That's truly a
MTL-specific issue rather than being tied to any of the IP blocks, so
leaving the condition as IS_METEORLAKE is correct there.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c   | 4 ++--
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +-
 drivers/gpu/drm/i915/display/intel_display.c | 2 +-
 drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index dcc1f6941b60..4cb1dc397b62 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1840,7 +1840,7 @@ static bool 
cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private *i91
 
 static bool pll_enable_wa_needed(struct drm_i915_private *dev_priv)
 {
-   return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv)) &&
+   return ((IS_DG2(dev_priv) || DISPLAY_VER_FULL(dev_priv) == IP_VER(14, 
0)) &&
dev_priv->display.cdclk.hw.vco > 0 &&
HAS_CDCLK_SQUASH(dev_priv));
 }
@@ -3559,7 +3559,7 @@ static const struct intel_cdclk_funcs i830_cdclk_funcs = {
  */
 void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
 {
-   if (IS_METEORLAKE(dev_priv)) {
+   if (DISPLAY_VER(dev_priv) > 14) {
dev_priv->display.funcs.cdclk = _cdclk_funcs;
dev_priv->display.cdclk.table = mtl_cdclk_table;
} else if (IS_DG2(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 1b00ef2c6185..025c80b9fece 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -31,7 +31,7 @@
 
 bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
 {
-   if (IS_METEORLAKE(i915) && (phy < PHY_C))
+   if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && (phy < PHY_C))
return true;
 
return false;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 43cba98f7753..85efd77f491b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1767,7 +1767,7 @@ bool intel_phy_is_tc(struct drm_i915_private *dev_priv, 
enum phy phy)
if (IS_DG2(dev_priv))
/* DG2's "TC1" output uses a SNPS PHY */
return false;
-   else if (IS_ALDERLAKE_P(dev_priv) || IS_METEORLAKE(dev_priv))
+   else if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER_FULL(dev_priv) == 
IP_VER(14, 0))
return phy >= PHY_F && phy <= PHY_I;
else if (IS_TIGERLAKE(dev_priv))
return phy >= PHY_D && phy <= PHY_I;
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 5f479f3828bb..1623c0c5e8a1 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -998,7 +998,7 @@ void intel_dmc_init(struct drm_i915_private *i915)
 
INIT_WORK(>work, dmc_load_work_fn);
 
-   if (IS_METEORLAKE(i915)) {
+   if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0)) {
dmc->fw_path = MTL_DMC_PATH;
dmc->max_fw_size = XELPDP_DMC_MAX_FW_SIZE;
} else if (IS_DG2(i915)) {
-- 
2.41.0



[Intel-gfx] [PATCH 6/8] drm/i915/mtl: Eliminate subplatforms

2023-07-18 Thread Matt Roper
Now that we properly match the Xe_LPG IP versions associated with
various workarounds, there's no longer any need to define separate MTL
subplatform in the driver.  Nothing in the code is conditional on MTL-M
or MTL-P base platforms.  Furthermore, I'm not sure the "M" and "P"
designations are even an accurate representation of which specific
platforms would have which IP versions; those were mostly just
placeholders from a long time ago.  The reality is that the IP version
present on a platform gets read from a fuse register at driver init; we
shouldn't be trying to guess which IP is present based on PCI ID
anymore.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 
 drivers/gpu/drm/i915/intel_device_info.c | 14 --
 drivers/gpu/drm/i915/intel_device_info.h |  4 
 include/drm/i915_pciids.h| 11 +++
 4 files changed, 3 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cf72c34bca10..67cd9914bf33 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -581,10 +581,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_PONTEVECCHIO(i915) IS_PLATFORM(i915, INTEL_PONTEVECCHIO)
 #define IS_METEORLAKE(i915) IS_PLATFORM(i915, INTEL_METEORLAKE)
 
-#define IS_METEORLAKE_M(i915) \
-   IS_SUBPLATFORM(i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_M)
-#define IS_METEORLAKE_P(i915) \
-   IS_SUBPLATFORM(i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_P)
 #define IS_DG2_G10(i915) \
IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G10)
 #define IS_DG2_G11(i915) \
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index ea0ec6174ce5..9dfa680a4c62 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -206,14 +206,6 @@ static const u16 subplatform_g12_ids[] = {
INTEL_DG2_G12_IDS(0),
 };
 
-static const u16 subplatform_m_ids[] = {
-   INTEL_MTL_M_IDS(0),
-};
-
-static const u16 subplatform_p_ids[] = {
-   INTEL_MTL_P_IDS(0),
-};
-
 static bool find_devid(u16 id, const u16 *p, unsigned int num)
 {
for (; num; num--, p++) {
@@ -275,12 +267,6 @@ static void intel_device_info_subplatform_init(struct 
drm_i915_private *i915)
} else if (find_devid(devid, subplatform_g12_ids,
  ARRAY_SIZE(subplatform_g12_ids))) {
mask = BIT(INTEL_SUBPLATFORM_G12);
-   } else if (find_devid(devid, subplatform_m_ids,
- ARRAY_SIZE(subplatform_m_ids))) {
-   mask = BIT(INTEL_SUBPLATFORM_M);
-   } else if (find_devid(devid, subplatform_p_ids,
- ARRAY_SIZE(subplatform_p_ids))) {
-   mask = BIT(INTEL_SUBPLATFORM_P);
}
 
GEM_BUG_ON(mask & ~INTEL_SUBPLATFORM_MASK);
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index dbfe6443457b..2ca54417d19b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -129,10 +129,6 @@ enum intel_platform {
 #define INTEL_SUBPLATFORM_N1
 #define INTEL_SUBPLATFORM_RPLU  2
 
-/* MTL */
-#define INTEL_SUBPLATFORM_M0
-#define INTEL_SUBPLATFORM_P1
-
 enum intel_ppgtt_type {
INTEL_PPGTT_NONE = I915_GEM_PPGTT_NONE,
INTEL_PPGTT_ALIASING = I915_GEM_PPGTT_ALIASING,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index e1e10dfbb661..38dae757d1a8 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -738,18 +738,13 @@
 #define INTEL_ATS_M_IDS(info) \
INTEL_ATS_M150_IDS(info), \
INTEL_ATS_M75_IDS(info)
+
 /* MTL */
-#define INTEL_MTL_M_IDS(info) \
+#define INTEL_MTL_IDS(info) \
INTEL_VGA_DEVICE(0x7D40, info), \
-   INTEL_VGA_DEVICE(0x7D60, info)
-
-#define INTEL_MTL_P_IDS(info) \
INTEL_VGA_DEVICE(0x7D45, info), \
INTEL_VGA_DEVICE(0x7D55, info), \
+   INTEL_VGA_DEVICE(0x7D60, info), \
INTEL_VGA_DEVICE(0x7DD5, info)
 
-#define INTEL_MTL_IDS(info) \
-   INTEL_MTL_M_IDS(info), \
-   INTEL_MTL_P_IDS(info)
-
 #endif /* _I915_PCIIDS_H */
-- 
2.41.0



[Intel-gfx] [PATCH 8/8] drm/i915: Replace several IS_METEORLAKE with proper IP version checks

2023-07-18 Thread Matt Roper
Many of the IS_METEORLAKE conditions throughout the driver are supposed
to be checks for Xe_LPG and/or Xe_LPM+ IP, not for the MTL platform
specifically.  Update those checks to ensure that the code will still
operate properly if/when these IP versions show up on future platforms.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 4 ++--
 drivers/gpu/drm/i915/gem/i915_gem_pages.c  | 4 ++--
 drivers/gpu/drm/i915/gt/intel_engine_pm.c  | 2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c| 4 ++--
 drivers/gpu/drm/i915/gt/intel_mocs.c   | 2 +-
 drivers/gpu/drm/i915/gt/intel_reset.c  | 2 +-
 drivers/gpu/drm/i915/gt/intel_rps.c| 2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 ++--
 drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
 drivers/gpu/drm/i915/i915_perf.c   | 8 +---
 10 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index d24c0ce8805c..19156ba4b9ef 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -405,8 +405,8 @@ static int ext_set_pat(struct i915_user_extension __user 
*base, void *data)
BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
 offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
 
-   /* Limiting the extension only to Meteor Lake */
-   if (!IS_METEORLAKE(i915))
+   /* Limiting the extension only to Xe_LPG and beyond */
+   if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 70))
return -ENODEV;
 
if (copy_from_user(, base, sizeof(ext)))
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 89fc8ea6bcfc..4b003925cc3e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -470,9 +470,9 @@ enum i915_map_type i915_coherent_map_type(struct 
drm_i915_private *i915,
  bool always_coherent)
 {
/*
-* Wa_22016122933: always return I915_MAP_WC for MTL
+* Wa_22016122933: always return I915_MAP_WC for Xe_LPM+
 */
-   if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
+   if (i915_gem_object_is_lmem(obj) || MEDIA_VER_FULL(i915) == IP_VER(13, 
0))
return I915_MAP_WC;
if (HAS_LLC(i915) || always_coherent)
return I915_MAP_WB;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 21af0ec52223..24060278e7a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -21,7 +21,7 @@ static void intel_gsc_idle_msg_enable(struct intel_engine_cs 
*engine)
 {
struct drm_i915_private *i915 = engine->i915;
 
-   if (IS_METEORLAKE(i915) && engine->id == GSC0) {
+   if (MEDIA_VER(i915) >= 13 && engine->id == GSC0) {
intel_uncore_write(engine->gt->uncore,
   RC_PSMI_CTRL_GSCCS,
   _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 4fefa67d285f..a125c3284bab 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1095,10 +1095,10 @@ __lrc_alloc_state(struct intel_context *ce, struct 
intel_engine_cs *engine)
if (IS_ERR(obj)) {
obj = i915_gem_object_create_shmem(engine->i915, context_size);
/*
-* Wa_22016122933: For MTL the shared memory needs to be mapped
+* Wa_22016122933: For Xe_LPM+ the shared memory needs to be 
mapped
 * as WC on CPU side and UC (PAT index 2) on GPU side
 */
-   if (IS_METEORLAKE(engine->i915))
+   if (MEDIA_VER_FULL(engine->i915) == IP_VER(13, 0))
i915_gem_object_set_cache_coherency(obj, 
I915_CACHE_NONE);
}
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 2c014407225c..830ad2c10761 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -507,7 +507,7 @@ static unsigned int get_mocs_settings(const struct 
drm_i915_private *i915,
memset(table, 0, sizeof(struct drm_i915_mocs_table));
 
table->unused_entries_index = I915_MOCS_PTE;
-   if (IS_METEORLAKE(i915)) {
+   if (GT_GRAPHICS_RANGE(>gt0, IP_VER(12, 70), IP_VER(12, 71))) {
table->size = ARRAY_SIZE(mtl_mocs_table);
table->table = mtl_mocs_table;
table->n_entries = MTL_NUM_MOCS_ENTRIES;
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 403f0d9caadf..0714584dd83d 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ 

[Intel-gfx] [PATCH 1/8] drm/i915: Consolidate condition for Wa_22011802037

2023-07-18 Thread Matt Roper
The workaround bounds for Wa_22011802037 are somewhat complex and are
replicated in several places throughout the code.  Pull the condition
out to a helper function to prevent mistakes if this condition needs to
change again in the future.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c  |  4 +---
 .../drm/i915/gt/intel_execlists_submission.c   |  4 +---
 drivers/gpu/drm/i915/gt/intel_reset.c  | 18 ++
 drivers/gpu/drm/i915/gt/intel_reset.h  |  2 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc.c |  4 +---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c  |  4 +---
 6 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 0aff5bb13c53..0d095337b350 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1616,9 +1616,7 @@ static int __intel_engine_stop_cs(struct intel_engine_cs 
*engine,
 * Wa_22011802037: Prior to doing a reset, ensure CS is
 * stopped, set ring stop bit and prefetch disable bit to halt CS
 */
-   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
-   (GRAPHICS_VER(engine->i915) >= 11 &&
-   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
+   if (intel_engine_reset_needs_wa_22011802037(engine->gt))
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
  
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index d85b5a6d981f..b9f297c546fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3001,9 +3001,7 @@ static void execlists_reset_prepare(struct 
intel_engine_cs *engine)
 * Wa_22011802037: In addition to stopping the cs, we need
 * to wait for any pending mi force wakeups
 */
-   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
-   (GRAPHICS_VER(engine->i915) >= 11 &&
-   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
+   if (intel_engine_reset_needs_wa_22011802037(engine->gt))
intel_engine_wait_for_pending_mi_fw(engine);
 
engine->execlists.reset_ccid = active_ccid(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index cc6bd21a3e51..1ff7b42521c9 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1632,6 +1632,24 @@ void __intel_fini_wedge(struct intel_wedge_me *w)
w->gt = NULL;
 }
 
+/*
+ * Wa_22011802037 requires that we (or the GuC) ensure that no command
+ * streamers are executing MI_FORCE_WAKE while an engine reset is initiated.
+ */
+bool intel_engine_reset_needs_wa_22011802037(struct intel_gt *gt)
+{
+   if (GRAPHICS_VER(gt->i915) < 11)
+   return false;
+
+   if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0))
+   return true;
+
+   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+   return false;
+
+   return true;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftest_reset.c"
 #include "selftest_hangcheck.c"
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.h 
b/drivers/gpu/drm/i915/gt/intel_reset.h
index 25c975b6e8fc..f615b30b81c5 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.h
+++ b/drivers/gpu/drm/i915/gt/intel_reset.h
@@ -78,4 +78,6 @@ void __intel_fini_wedge(struct intel_wedge_me *w);
 bool intel_has_gpu_reset(const struct intel_gt *gt);
 bool intel_has_reset_engine(const struct intel_gt *gt);
 
+bool intel_engine_reset_needs_wa_22011802037(struct intel_gt *gt);
+
 #endif /* I915_RESET_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2eb891b270ae..1e532981f74e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -292,9 +292,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
flags |= GUC_WA_DUAL_QUEUE;
 
/* Wa_22011802037: graphics version 11/12 */
-   if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
-   (GRAPHICS_VER(gt->i915) >= 11 &&
-   GRAPHICS_VER_FULL(gt->i915) < IP_VER(12, 70)))
+   if (intel_engine_reset_needs_wa_22011802037(gt))
flags |= GUC_WA_PRE_PARSER;
 
/* Wa_16011777198:dg2 */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a0e3ef1c65d2..1bd5d8f7c40b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1658,9 +1658,7 @@ static void guc_engine_reset_prepare(struct 
intel_engine_cs *engine)
 * Wa_22011802037: In addition to 

[Intel-gfx] [PATCH 3/8] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

2023-07-18 Thread Matt Roper
Several workarounds are guarded by IS_MTL_GRAPHICS_STEP.  However none
of these workarounds are actually tied to MTL as a platform; they only
relate to the Xe_LPG graphics IP, regardless of what platform it appears
in.  At the moment MTL is the only platform that uses Xe_LPG with IP
versions 12.70 and 12.71, but we can't count on this being true in the
future.  Switch these to use a new IS_GFX_IPVER_STEP() macro instead
that is purely based on IP version.  IS_GFX_IPVER_STEP() is also
GT-based rather than device-based, which will help prevent mistakes
where we accidentally try to apply Xe_LPG graphics workarounds to the
Xe_LPM+ media GT.

Signed-off-by: Matt Roper 
---
 .../drm/i915/display/skl_universal_plane.c|  4 +-
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  9 ++--
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  4 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
 drivers/gpu/drm/i915/gt/intel_reset.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 52 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|  2 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  8 +--
 9 files changed, 46 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 6b01a0b68b97..c13e64fd 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2169,8 +2169,8 @@ static bool skl_plane_has_rc_ccs(struct drm_i915_private 
*i915,
 enum pipe pipe, enum plane_id plane_id)
 {
/* Wa_14017240301 */
-   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   if (IS_GFX_IPVER_STEP(to_gt(i915), IP_VER(12, 70), STEP_A0, STEP_B0) ||
+   IS_GFX_IPVER_STEP(to_gt(i915), IP_VER(12, 71), STEP_A0, STEP_B0))
return false;
 
/* Wa_22011186057 */
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 23857cc08eca..c1af91d908e5 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -180,8 +180,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, 
const i915_reg_t inv
 static int mtl_dummy_pipe_control(struct i915_request *rq)
 {
/* Wa_14016712196 */
-   if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
+   if (IS_GFX_IPVER_STEP(rq->engine->gt, IP_VER(12, 70), STEP_A0, STEP_B0) 
||
+   IS_GFX_IPVER_STEP(rq->engine->gt, IP_VER(12, 71), STEP_A0, 
STEP_B0)) {
u32 *cs;
 
/* dummy PIPE_CONTROL + depth flush */
@@ -755,6 +755,7 @@ u32 *gen12_emit_fini_breadcrumb_xcs(struct i915_request 
*rq, u32 *cs)
 u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
 {
struct drm_i915_private *i915 = rq->engine->i915;
+   struct intel_gt *gt = rq->engine->gt;
u32 flags = (PIPE_CONTROL_CS_STALL |
 PIPE_CONTROL_TLB_INVALIDATE |
 PIPE_CONTROL_TILE_CACHE_FLUSH |
@@ -765,8 +766,8 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs)
 PIPE_CONTROL_FLUSH_ENABLE);
 
/* Wa_14016712196 */
-   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   if (IS_GFX_IPVER_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
+   IS_GFX_IPVER_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0))
/* dummy PIPE_CONTROL + depth flush */
cs = gen12_emit_pipe_control(cs, 0,
 PIPE_CONTROL_DEPTH_CACHE_FLUSH, 0);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 0b414eae1683..41140eb86051 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -166,8 +166,8 @@ void intel_gt_mcr_init(struct intel_gt *gt)
gt->steering_table[OADDRM] = xelpmp_oaddrm_steering_table;
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
/* Wa_14016747170 */
-   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   if (IS_GFX_IPVER_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
+   IS_GFX_IPVER_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0))
fuse = REG_FIELD_GET(MTL_GT_L3_EXC_MASK,
 intel_uncore_read(gt->uncore,
   
MTL_GT_ACTIVITY_FACTOR));
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c

[Intel-gfx] [PATCH 4/8] drm/i915: Eliminate IS_MTL_MEDIA_STEP

2023-07-18 Thread Matt Roper
Stepping-specific media behavior shouldn't be tied to MTL as a platform,
but rather specifically to the Xe_LPM+ IP.  Future non-MTL platforms may
re-use this IP and will need to follow the exact same logic and apply
the same workarounds.  IS_MTL_MEDIA_STEP() is dropped in favor of a new
macro IS_MEDIA_IPVER_STEP() that checks the media IP version associated
with a specific IP and also ensures that we're operating on the media
GT, not the primary GT.

This new macro will return false if the GT is NULL (so it's safe to pass
i915->media_gt as a parameter, even though that will be NULL on
platforms without standalone media).  We don't expect this macro to used
to match media versions earlier than 13 (when media became a standalone
GT), so a build error will be raised if this macro is used to match on a
pre-13 version of media.  That restriction can be adjusted in the future
if we find a use for this macro on earlier platforms.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_rc6.c |  3 +--
 drivers/gpu/drm/i915/i915_drv.h | 10 ++
 drivers/gpu/drm/i915/i915_perf.c| 15 ---
 3 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 58bb1c55294c..91c68c0ec32d 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -526,8 +526,7 @@ static bool rc6_supported(struct intel_rc6 *rc6)
return false;
}
 
-   if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0) &&
-   gt->type == GT_MEDIA) {
+   if (IS_MEDIA_IPVER_STEP(gt, IP_VER(13, 0), STEP_A0, STEP_B0)) {
drm_notice(>drm,
   "Media RC6 disabled on A step\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d03710c923c8..10741177b654 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -698,14 +698,16 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  GRAPHICS_VER_FULL(__gt->i915) == ipver && \
  IS_GRAPHICS_STEP(__gt->i915, since, until)))
 
+#define IS_MEDIA_IPVER_STEP(__gt, ipver, since, until) \
+   (BUILD_BUG_ON_ZERO(ipver < IP_VER(13, 0)) + \
+(__gt && __gt->type == GT_MEDIA && \
+ MEDIA_VER_FULL(__gt->i915) == ipver && \
+ IS_MEDIA_STEP(__gt->i915, since, until)))
+
 #define IS_MTL_DISPLAY_STEP(__i915, since, until) \
(IS_METEORLAKE(__i915) && \
 IS_DISPLAY_STEP(__i915, since, until))
 
-#define IS_MTL_MEDIA_STEP(__i915, since, until) \
-   (IS_METEORLAKE(__i915) && \
-IS_MEDIA_STEP(__i915, since, until))
-
 /*
  * DG2 hardware steppings are a bit unusual.  The hardware design was forked to
  * create three variants (G10, G11, and G12) which each have distinct
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 49c6f1ff1128..ff95f2cdf2b0 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4223,7 +4223,7 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
 * C6 disable in BIOS. Fail if Media C6 is enabled on steppings where 
OAM
 * does not work as expected.
 */
-   if (IS_MTL_MEDIA_STEP(props->engine->i915, STEP_A0, STEP_C0) &&
+   if (IS_MEDIA_IPVER_STEP(props->engine->gt, IP_VER(13, 0), STEP_A0, 
STEP_C0) &&
props->engine->oa_group->type == TYPE_OAM &&
intel_check_bios_c6_setup(>engine->gt->rc6)) {
drm_dbg(>i915->drm,
@@ -5332,16 +5332,9 @@ int i915_perf_ioctl_version(struct drm_i915_private 
*i915)
 * C6 disable in BIOS. If Media C6 is enabled in BIOS, return version 6
 * to indicate that OA media is not supported.
 */
-   if (IS_MTL_MEDIA_STEP(i915, STEP_A0, STEP_C0)) {
-   struct intel_gt *gt;
-   int i;
-
-   for_each_gt(gt, i915, i) {
-   if (gt->type == GT_MEDIA &&
-   intel_check_bios_c6_setup(>rc6))
-   return 6;
-   }
-   }
+   if (IS_MEDIA_IPVER_STEP(i915->media_gt, IP_VER(13, 0), STEP_A0, 
STEP_C0) &&
+   intel_check_bios_c6_setup(>media_gt->rc6))
+   return 6;
 
return 7;
 }
-- 
2.41.0



[Intel-gfx] [PATCH 0/8] Reduce MTL-specific platform checks

2023-07-18 Thread Matt Roper
Starting with MTL, the hardware moved to a disaggregated IP design where
graphics, media, and display are supposed to be treated independently of
the base platform that they're incorporated into.  For driver logic that
is conditional on these IPs, the code should be checking the IP versions
(as read from the GMD_ID registers) rather than trying to match on a
specific platform (e.g., MTL).  It's possible that these IPs could show
up again, without changes, on future non-MTL platforms, or that the
current MTL platform could be extended to include new IP versions in
future SKUs or refreshes; making sure our driver's conditions are
handled appropriately future-proofs for both of these cases.

Going forward, conditions like IS_METEORLAKE should be very rare in the
driver; in most places our logic will be conditional upon the IP rather
than the base platform.

Cc: Tvrtko Ursulin 
Cc: Dnyaneshwar Bhadane 

Matt Roper (8):
  drm/i915: Consolidate condition for Wa_22011802037
  drm/i915/xelpg: Call Xe_LPG workaround functions based on IP version
  drm/i915: Eliminate IS_MTL_GRAPHICS_STEP
  drm/i915: Eliminate IS_MTL_MEDIA_STEP
  drm/i915: Eliminate IS_MTL_DISPLAY_STEP
  drm/i915/mtl: Eliminate subplatforms
  drm/i915/display: Eliminate IS_METEORLAKE checks
  drm/i915: Replace several IS_METEORLAKE with proper IP version checks

 drivers/gpu/drm/i915/display/intel_cdclk.c|  4 +-
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
 .../drm/i915/display/intel_display_device.h   |  5 ++
 drivers/gpu/drm/i915/display/intel_dmc.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_fbc.c  |  3 +-
 drivers/gpu/drm/i915/display/intel_pmdemand.c |  2 +-
 drivers/gpu/drm/i915/display/intel_psr.c  | 10 +--
 .../drm/i915/display/skl_universal_plane.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_create.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  4 +-
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  9 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  4 +-
 drivers/gpu/drm/i915/gt/intel_engine_pm.c |  2 +-
 .../drm/i915/gt/intel_execlists_submission.c  |  4 +-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  4 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  8 +-
 drivers/gpu/drm/i915/gt/intel_mocs.c  |  2 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   |  3 +-
 drivers/gpu/drm/i915/gt/intel_reset.c | 21 -
 drivers/gpu/drm/i915/gt/intel_reset.h |  2 +
 drivers/gpu/drm/i915/gt/intel_rps.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 90 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 10 +--
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  6 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 31 ---
 drivers/gpu/drm/i915/i915_perf.c  | 23 ++---
 drivers/gpu/drm/i915/intel_device_info.c  | 14 ---
 drivers/gpu/drm/i915/intel_device_info.h  |  4 -
 include/drm/i915_pciids.h | 11 +--
 31 files changed, 146 insertions(+), 148 deletions(-)

-- 
2.41.0



Re: [Intel-gfx] [PATCH] drm/i915/dpt: Use shmem for dpt objects

2023-07-18 Thread Sripada, Radhakrishna
Hi Tvrtko,

> -Original Message-
> From: Tvrtko Ursulin 
> Sent: Tuesday, July 18, 2023 3:08 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dpt: Use shmem for dpt objects
> 
> 
> On 18/07/2023 06:33, Radhakrishna Sripada wrote:
> > Dpt objects that are created from internal get evicted when there is
> > memory pressure and do not get restored when pinned during scanout. The
> > pinned page table entries look corrupted and programming the display
> > engine with the incorrect pte's result in DE throwing pipe faults.
> >
> > Create DPT objects from shmem and mark the object as dirty when pinning so
> > that the object is restored when shrinker evicts an unpinned buffer object.
> >
> > Cc: Ville Syrjälä 
> 
> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
> Cc:  # v6.0+
> 
> Not sure which platforms it actually applies so just mentioning to pick the 
> right
> one.

Sure will add the above ones.
> 
> > Suggested-by: Chris Wilson 
> > Signed-off-by: Fei Yang 
> > Signed-off-by: Radhakrishna Sripada 
> > ---
> >   drivers/gpu/drm/i915/display/intel_dpt.c | 5 -
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> b/drivers/gpu/drm/i915/display/intel_dpt.c
> > index 7c5fddb203ba..a57d18550a46 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> > @@ -166,6 +166,9 @@ struct i915_vma *intel_dpt_pin(struct
> i915_address_space *vm)
> > i915_vma_get(vma);
> > }
> >
> > +   if (i915_gem_object_is_shmem(dpt->obj))
> > +   dpt->obj->cache_dirty = true;
> 
> GPU writes to this object behind the covers or what is supposed to be the
> purpose of this?
This is to make sure that pages when writing/obtained back from swap do not
loose its contents. dpt->obj->mm.dirty = true is also achieving the same result.
Without either of the above changes, we get the following corrupt pte's.

Speaking with Chris it was suggested to unconditionally mark dpt->ob->mm.dirty 
= true
so that contents of the pages do not get lost during swap out/swap in. 


[ 6991.405300] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0xf200, Pte[0]: 0x20f201
[ 6991.405803] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0x0, Pte[8696]: 0x21
[ 6991.406527] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0x1000, Pte[8697]: 0x201001
[ 6991.406816] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0x2000, Pte[8698]: 0x202001
[ 6991.407071] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0x3000, Pte[8699]: 0x203001
[ 6991.407301] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0x4000, Pte[8700]: 0x204001
[ 6991.407518] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0x5000, Pte[8701]: 0x205001
[ 6991.407727] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0x6000, Pte[8702]: 0x206001
[ 6991.407939] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[88814582b800] Addr: 0x7000, Pte[8703]: 0x207001
[ 6991.408329] i915 :00:02.0: [drm:intel_power_well_enable [i915]] enabling 
DC_off
[ 6991.409254] i915 :00:02.0: [drm:gen9_set_dc_state.part.0 [i915]] Setting 
DC state from 02 to 00
[ 6991.441831] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0xf600, Pte[0]: 0x20f601
[ 6991.442316] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0x0, Pte[8696]: 0x21
[ 6991.442561] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0x1000, Pte[8697]: 0x201001
[ 6991.442780] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0x2000, Pte[8698]: 0x202001
[ 6991.443043] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0x3000, Pte[8699]: 0x203001
[ 6991.443271] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0x4000, Pte[8700]: 0x204001
[ 6991.443480] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0x5000, Pte[8701]: 0x205001
[ 6991.443693] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0x6000, Pte[8702]: 0x206001
[ 6991.443906] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT 
OBJ[888145828800] Addr: 0x7000, Pte[8703]: 0x207001
[ 6991.478042] i915 :00:02.0: [drm:intel_power_well_disable [i915]] 
disabling DC_off
[ 6991.478545] i915 :00:02.0: [drm:skl_enable_dc6 [i915]] Enabling DC6
[ 

[Intel-gfx] [PATCH 1/2] drm/v3d: Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()

2023-07-18 Thread Nathan Chancellor
A proposed update to clang's -Wconstant-logical-operand to warn when the
left hand side is a constant shows the following instance in
nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a multiple of HZ,
such as CONFIG_HZ=300:

  In file included from drivers/gpu/drm/v3d/v3d_debugfs.c:12:
  drivers/gpu/drm/v3d/v3d_drv.h:343:24: warning: use of logical '&&' with 
constant operand [-Wconstant-logical-operand]
343 | if (NSEC_PER_SEC % HZ &&
| ~ ^
  drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: use '&' for a bitwise operation
343 | if (NSEC_PER_SEC % HZ &&
|   ^~
|   &
  drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: remove constant to silence this 
warning
  1 warning generated.

Turn this into an explicit comparison against zero to make the
expression a boolean to make it clear this should be a logical check,
not a bitwise one.

Link: https://reviews.llvm.org/D142609
Signed-off-by: Nathan Chancellor 
---
 drivers/gpu/drm/v3d/v3d_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index b74b1351bfc8..7f664a4b2a75 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -340,7 +340,7 @@ struct v3d_submit_ext {
 static inline unsigned long nsecs_to_jiffies_timeout(const u64 n)
 {
/* nsecs_to_jiffies64() does not guard against overflow */
-   if (NSEC_PER_SEC % HZ &&
+   if ((NSEC_PER_SEC % HZ) != 0 &&
div_u64(n, NSEC_PER_SEC) >= MAX_JIFFY_OFFSET / HZ)
return MAX_JIFFY_OFFSET;
 

-- 
2.41.0



[Intel-gfx] [PATCH 2/2] drm/i915: Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()

2023-07-18 Thread Nathan Chancellor
A proposed update to clang's -Wconstant-logical-operand to warn when the
left hand side is a constant shows the following instance in
nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a multiple of HZ,
such as CONFIG_HZ=300:

  drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: warning: use of logical '&&' 
with constant operand [-Wconstant-logical-operand]
189 | if (NSEC_PER_SEC % HZ &&
| ~ ^
  drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: note: use '&' for a bitwise 
operation
189 | if (NSEC_PER_SEC % HZ &&
|   ^~
|   &
  drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: note: remove constant to 
silence this warning
  1 warning generated.

Turn this into an explicit comparison against zero to make the
expression a boolean to make it clear this should be a logical check,
not a bitwise one.

Link: https://reviews.llvm.org/D142609
Signed-off-by: Nathan Chancellor 
---
 drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c 
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 4a33ad2d122b..d4b918fb11ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -186,7 +186,7 @@ i915_gem_object_wait(struct drm_i915_gem_object *obj,
 static inline unsigned long nsecs_to_jiffies_timeout(const u64 n)
 {
/* nsecs_to_jiffies64() does not guard against overflow */
-   if (NSEC_PER_SEC % HZ &&
+   if ((NSEC_PER_SEC % HZ) != 0 &&
div_u64(n, NSEC_PER_SEC) >= MAX_JIFFY_OFFSET / HZ)
return MAX_JIFFY_OFFSET;
 

-- 
2.41.0



[Intel-gfx] [PATCH 0/2] Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()

2023-07-18 Thread Nathan Chancellor
Hi all,

A proposed update to clang's -Wconstant-logical-operand [1] to warn when
the left hand side is a constant as well now triggers with the modulo
expression in nsecs_to_jiffies_timeout() when NSEC_PER_SEC is not a
multiple of HZ, such as CONFIG_HZ=300:

  drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: warning: use of logical '&&' 
with constant operand [-Wconstant-logical-operand]
189 | if (NSEC_PER_SEC % HZ &&
| ~ ^
  drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: note: use '&' for a bitwise 
operation
189 | if (NSEC_PER_SEC % HZ &&
|   ^~
|   &
  drivers/gpu/drm/i915/gem/i915_gem_wait.c:189:24: note: remove constant to 
silence this warning
  1 warning generated.

  In file included from drivers/gpu/drm/v3d/v3d_debugfs.c:12:
  drivers/gpu/drm/v3d/v3d_drv.h:343:24: warning: use of logical '&&' with 
constant operand [-Wconstant-logical-operand]
343 | if (NSEC_PER_SEC % HZ &&
| ~ ^
  drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: use '&' for a bitwise operation
343 | if (NSEC_PER_SEC % HZ &&
|   ^~
|   &
  drivers/gpu/drm/v3d/v3d_drv.h:343:24: note: remove constant to silence this 
warning
  1 warning generated.

These patches add an explicit comparison to zero to make the
expression a boolean, which clears up the warning.

The patches have no real dependency on each other but I felt like they
made send together since it is the same code.

If these could go into mainline sooner rather than later to avoid
breaking builds that can hit this with CONFIG_WERROR, that would be
nice, but I won't insist since I don't think our own CI has builds that
has those conditions, but others might.

---
Nathan Chancellor (2):
  drm/v3d: Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()
  drm/i915: Avoid -Wconstant-logical-operand in nsecs_to_jiffies_timeout()

 drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +-
 drivers/gpu/drm/v3d/v3d_drv.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c
change-id: 
20230718-nsecs_to_jiffies_timeout-constant-logical-operand-4a944690f3e9

Best regards,
-- 
Nathan Chancellor 



[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915: Move setting of rps thresholds to init (rev3)

2023-07-18 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915: Move setting of rps thresholds 
to init (rev3)
URL   : https://patchwork.freedesktop.org/series/120857/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13394_full -> Patchwork_120857v3_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_120857v3_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_120857v3_full, please notify your bug team to allow 
them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120857v3_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@flip-vs-rmfb-interruptible@a-vga1:
- shard-snb:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-snb6/igt@kms_flip@flip-vs-rmfb-interrupti...@a-vga1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-snb7/igt@kms_flip@flip-vs-rmfb-interrupti...@a-vga1.html

  
Known issues


  Here are the changes found in Patchwork_120857v3_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@device_reset@cold-reset-bound:
- shard-mtlp: NOTRUN -> [SKIP][3] ([i915#7701])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-mtlp-5/igt@device_re...@cold-reset-bound.html

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl:  [PASS][4] -> [FAIL][5] ([i915#7742])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@feature_discovery@display-2x:
- shard-mtlp: NOTRUN -> [SKIP][6] ([i915#1839])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-mtlp-5/igt@feature_discov...@display-2x.html

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-glk:  [PASS][7] -> [ABORT][8] ([i915#7461] / [i915#8211])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-glk9/igt@gem_barrier_race@remote-requ...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-glk9/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_create@create-ext-set-pat:
- shard-snb:  NOTRUN -> [FAIL][9] ([i915#8621])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-snb1/igt@gem_cre...@create-ext-set-pat.html

  * igt@gem_ctx_persistence@idempotent:
- shard-snb:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-snb5/igt@gem_ctx_persiste...@idempotent.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-rkl:  NOTRUN -> [FAIL][11] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-rkl-2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglu: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-tglu-7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl:  [PASS][14] -> [FAIL][15] ([i915#2842]) +2 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-rkl-7/igt@gem_exec_fair@basic-p...@vecs0.html
- shard-glk:  [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-glk6/igt@gem_exec_fair@basic-p...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-glk2/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-rkl:  NOTRUN -> [SKIP][18] ([fdo#112283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-rkl-2/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_exec_reloc@basic-gtt-read:
- shard-rkl:  NOTRUN -> [SKIP][19] ([i915#3281]) +2 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/shard-rkl-2/igt@gem_exec_re...@basic-gtt-read.html

  * igt@gem_exec_reloc@basic-wc-gtt-active:
- shard-mtlp: NOTRUN -> [SKIP][20] 

Re: [Intel-gfx] [v4 15/15] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform defines

2023-07-18 Thread Matt Roper
On Tue, Jul 18, 2023 at 09:59:14AM +0100, Tvrtko Ursulin wrote:
> 
> On 18/07/2023 09:11, Dnyaneshwar Bhadane wrote:
> > Follow consistent naming convention. Replace MTL with
> > METEORLAKE. Added defines that are replacing IS_MTL_GRAPHICS_STEP with
> > IS_METEORLAKE_P_GRAPHICS_STEP and IS_METEORLAKE_M_GRAPHICS_STEP.
> > Also replaced IS_METEORLAKE_MEDIA_STEP instead of IS_MTL_MEDIA_STEP and
> > IS_METEORLAKE_DISPLAY_STEP instead of IS_MTL_DISPLAY_STEP.
> > 
> > v2:
> > - Replace IS_MTL_GRAPHICS_STEP with IS_METEROLAKE_(P/M)_GRAPHICS_STEP 
> > (Tvrtko).
> > - Changed subject prefix mtl instead of MTL (Anusha)
> > 
> > v3:
> > - Updated the commit message. (Anusha)
> > 
> > v4:
> > - Unrolled wrapper IS_MTL_GRAPHICS_STEP(P/M) and Replace
> > with (IS_METEORLAKE_M || IS_METEORLAKE_P) && IS_GRAPHICS_STEP(Steping) 
> > (Jani/Tvrtko).
> > 
> > Cc: Tvrtko Ursulin 
> > Cc: Jani Nikula 
> > Cc: Anusha Srivatsa 
> > Signed-off-by: Dnyaneshwar Bhadane 
> > ---
> >   drivers/gpu/drm/i915/display/intel_fbc.c  |  2 +-
> >   drivers/gpu/drm/i915/display/intel_pmdemand.c |  2 +-
> >   drivers/gpu/drm/i915/display/intel_psr.c  | 11 +++--
> >   .../drm/i915/display/skl_universal_plane.c|  4 +-
> >   drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  8 ++--
> >   drivers/gpu/drm/i915/gt/intel_engine_cs.c |  3 +-
> >   .../drm/i915/gt/intel_execlists_submission.c  |  3 +-
> >   drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  4 +-
> >   drivers/gpu/drm/i915/gt/intel_lrc.c   |  4 +-
> >   drivers/gpu/drm/i915/gt/intel_rc6.c   |  3 +-
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c   | 47 ++-
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c|  7 ++-
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  6 ++-
> >   drivers/gpu/drm/i915/i915_drv.h   | 15 --
> >   drivers/gpu/drm/i915/i915_perf.c  |  6 ++-
> >   15 files changed, 73 insertions(+), 52 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 7f8b2d7713c7..6b3ea8f7263a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -1093,7 +1093,7 @@ static int intel_fbc_check_plane(struct 
> > intel_atomic_state *state,
> > /* Wa_14016291713 */
> > if ((IS_DISPLAY_VER(i915, 12, 13) ||
> > -IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
> > +(IS_METEORLAKE(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_C0))) 
> > &&
> > crtc_state->has_psr) {
> > plane_state->no_fbc_reason = "PSR1 enabled (Wa_14016291713)";
> > return 0;
> > diff --git a/drivers/gpu/drm/i915/display/intel_pmdemand.c 
> > b/drivers/gpu/drm/i915/display/intel_pmdemand.c
> > index f7608d363634..c68d9c68b39f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_pmdemand.c
> > +++ b/drivers/gpu/drm/i915/display/intel_pmdemand.c
> > @@ -92,7 +92,7 @@ int intel_pmdemand_init(struct drm_i915_private *i915)
> >  _state->base,
> >  _pmdemand_funcs);
> > -   if (IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
> > +   if ((IS_METEORLAKE(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_C0)))
> > /* Wa_14016740474 */
> > intel_de_rmw(i915, XELPD_CHICKEN_DCPR_3, 0, 
> > DMD_RSP_TIMEOUT_DISABLE);
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index bf80029c8a5d..a3f32b95de58 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1247,7 +1247,7 @@ static void wm_optimization_wa(struct intel_dp 
> > *intel_dp,
> > bool set_wa_bit = false;
> > /* Wa_14015648006 */
> > -   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > +   if ((IS_METEORLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, STEP_A0, 
> > STEP_B0)) ||
> > IS_DISPLAY_VER(dev_priv, 11, 13))
> > set_wa_bit |= crtc_state->wm_level_disabled;
> > @@ -1320,7 +1320,7 @@ static void intel_psr_enable_source(struct intel_dp 
> > *intel_dp,
> >  * All supported adlp panels have 1-based X granularity, this 
> > may
> >  * cause issues if non-supported panels are used.
> >  */
> > -   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> > +   if ((IS_METEORLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, 
> > STEP_A0, STEP_B0)))
> > intel_de_rmw(dev_priv, 
> > MTL_CHICKEN_TRANS(cpu_transcoder), 0,
> >  ADLP_1_BASED_X_GRANULARITY);
> > else if (IS_ALDERLAKE_P(dev_priv))
> > @@ -1328,7 +1328,7 @@ static void intel_psr_enable_source(struct intel_dp 
> > *intel_dp,
> >  ADLP_1_BASED_X_GRANULARITY);
> > /* Wa_16012604467:adlp,mtl[a0,b0] */
> > -   if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> > +   if 

Re: [Intel-gfx] [PATCH 11/11] drm/i915/perf: Wa_14017512683: Disable OAM if media C6 is enabled in BIOS

2023-07-18 Thread Matt Roper
On Thu, Mar 23, 2023 at 03:59:01PM -0700, Umesh Nerlige Ramappa wrote:
> OAM does not work with media C6 enabled on some steppings of MTL.

I just stumbled across this while looking at something else, but
14017512683 isn't a valid workaround number; that's just a per-platform
identifier associated with Wa_18023884638.  The actual Wa_18023884638
applies not only to MTL, but also to DG2 which it looks like we're not
handling below.


Matt

> Disable OAM if we detect that media C6 was enabled in bios.
> 
> v2: (Ashutosh)
> - Remove drm_notice from the driver load path
> - Log a drm_err when opening an OAM stream on affected steppings
> 
> v3:
> - Initialize the engine group even if mc6 is enabled (Ashutosh)
> - Checkpatch fix
> 
> Signed-off-by: Umesh Nerlige Ramappa 
> Reviewed-by: Ashutosh Dixit 
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 18afa76653b7..c035dbb84c9b 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -209,6 +209,7 @@
>  #include "gt/intel_gt_regs.h"
>  #include "gt/intel_lrc.h"
>  #include "gt/intel_lrc_reg.h"
> +#include "gt/intel_rc6.h"
>  #include "gt/intel_ring.h"
>  #include "gt/uc/intel_guc_slpc.h"
>  
> @@ -4223,6 +4224,19 @@ static int read_properties_unlocked(struct i915_perf 
> *perf,
>   return -EINVAL;
>   }
>  
> + /*
> +  * Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
> +  * C6 disable in BIOS. Fail if Media C6 is enabled on steppings where 
> OAM
> +  * does not work as expected.
> +  */
> + if (IS_MTL_MEDIA_STEP(props->engine->i915, STEP_A0, STEP_C0) &&
> + props->engine->oa_group->type == TYPE_OAM &&
> + intel_check_bios_c6_setup(>engine->gt->rc6)) {
> + drm_dbg(>i915->drm,
> + "OAM requires media C6 to be disabled in BIOS\n");
> + return -EINVAL;
> + }
> +
>   i = array_index_nospec(props->oa_format, I915_OA_FORMAT_MAX);
>   f = >oa_formats[i];
>   if (!engine_supports_oa_format(props->engine, f->type)) {
> @@ -5316,6 +5330,23 @@ int i915_perf_ioctl_version(struct drm_i915_private 
> *i915)
>*
>* 7: Add support for video decode and enhancement classes.
>*/
> +
> + /*
> +  * Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
> +  * C6 disable in BIOS. If Media C6 is enabled in BIOS, return version 6
> +  * to indicate that OA media is not supported.
> +  */
> + if (IS_MTL_MEDIA_STEP(i915, STEP_A0, STEP_C0)) {
> + struct intel_gt *gt;
> + int i;
> +
> + for_each_gt(gt, i915, i) {
> + if (gt->type == GT_MEDIA &&
> + intel_check_bios_c6_setup(>rc6))
> + return 6;
> + }
> + }
> +
>   return 7;
>  }
>  
> -- 
> 2.36.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/i915_pm_rps: Fix test after silent conflict harder

2023-07-18 Thread Rodrigo Vivi
On Tue, Jul 18, 2023 at 09:40:41AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Feature test also needs adjusting after sysfs helper API changes...
> 
> Signed-off-by: Tvrtko Ursulin 
> Fixes: d86ca7e17b58 ("tests/i915_pm_rps: Exercise sysfs thresholds")
> Reference: 54dc25efaf10 ("lib/igt_sysfs: add asserting helpers for read/write 
> operations")
> Reference: 1dfa7a007a8e ("tests/i915_pm_rps: Fix test after silent conflict")
> Cc: Rodrigo Vivi 
> Cc: Lukasz Laguna 
> Cc: Kamil Konieczny 
> Cc: Ashutosh Dixit 

Reviewed-by: Rodrigo Vivi 

> ---
>  tests/i915/i915_pm_rps.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> index 15c74cc703c2..3ef5842dd7f8 100644
> --- a/tests/i915/i915_pm_rps.c
> +++ b/tests/i915/i915_pm_rps.c
> @@ -1015,20 +1015,23 @@ static void sysfs_set_u32(int dir, const char *attr, 
> uint32_t set)
>  static void test_thresholds(int i915, unsigned int gt, unsigned int flags)
>  {
>   uint64_t ahnd = get_reloc_ahnd(i915, 0);
> + unsigned int def_up = 0, def_down = 0;
>   const unsigned int points = 10;
> - unsigned int def_up, def_down;
>   igt_spin_t *spin = NULL;
>   const intel_ctx_t *ctx;
>   unsigned int *ta, *tb;
>   unsigned int i;
>   int sysfs;
> + bool ret;
>  
>   sysfs = igt_sysfs_gt_open(i915, gt);
>   igt_require(sysfs >= 0);
>  
>   /* Feature test */
> - def_up = igt_sysfs_get_u32(sysfs, "rps_up_threshold_pct");
> - def_down = igt_sysfs_get_u32(sysfs, "rps_down_threshold_pct");
> + ret = __igt_sysfs_get_u32(sysfs, "rps_up_threshold_pct", _up);
> + igt_require(ret);
> + ret = __igt_sysfs_get_u32(sysfs, "rps_down_threshold_pct", _down);
> + igt_require(ret);
>   igt_require(def_up && def_down);
>  
>   /* Check invalid percentages are rejected */
> -- 
> 2.39.2
> 


Re: [Intel-gfx] [PATCH i-g-t] tests/i915_pm_rps: Fix test after silent conflict harder

2023-07-18 Thread Dixit, Ashutosh
On Tue, 18 Jul 2023 01:40:41 -0700, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin 
>
> Feature test also needs adjusting after sysfs helper API changes...
>
> Signed-off-by: Tvrtko Ursulin 
> Fixes: d86ca7e17b58 ("tests/i915_pm_rps: Exercise sysfs thresholds")
> Reference: 54dc25efaf10 ("lib/igt_sysfs: add asserting helpers for read/write 
> operations")
> Reference: 1dfa7a007a8e ("tests/i915_pm_rps: Fix test after silent conflict")
> Cc: Rodrigo Vivi 
> Cc: Lukasz Laguna 
> Cc: Kamil Konieczny 
> Cc: Ashutosh Dixit 
> ---
>  tests/i915/i915_pm_rps.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> index 15c74cc703c2..3ef5842dd7f8 100644
> --- a/tests/i915/i915_pm_rps.c
> +++ b/tests/i915/i915_pm_rps.c
> @@ -1015,20 +1015,23 @@ static void sysfs_set_u32(int dir, const char *attr, 
> uint32_t set)
>  static void test_thresholds(int i915, unsigned int gt, unsigned int flags)
>  {
>   uint64_t ahnd = get_reloc_ahnd(i915, 0);
> + unsigned int def_up = 0, def_down = 0;
>   const unsigned int points = 10;
> - unsigned int def_up, def_down;
>   igt_spin_t *spin = NULL;
>   const intel_ctx_t *ctx;
>   unsigned int *ta, *tb;
>   unsigned int i;
>   int sysfs;
> + bool ret;
>
>   sysfs = igt_sysfs_gt_open(i915, gt);
>   igt_require(sysfs >= 0);
>
>   /* Feature test */
> - def_up = igt_sysfs_get_u32(sysfs, "rps_up_threshold_pct");
> - def_down = igt_sysfs_get_u32(sysfs, "rps_down_threshold_pct");
> + ret = __igt_sysfs_get_u32(sysfs, "rps_up_threshold_pct", _up);
> + igt_require(ret);
> + ret = __igt_sysfs_get_u32(sysfs, "rps_down_threshold_pct", _down);
> + igt_require(ret);

Could also use igt_sysfs_has_attr(). Ok as is too.

Reviewed-by: Ashutosh Dixit 


>   igt_require(def_up && def_down);
>
>   /* Check invalid percentages are rejected */
> --
> 2.39.2
>


Re: [Intel-gfx] [igt-dev] [PATCH v2 i-g-t] i915_pm_freq_api: Add some debug to tests

2023-07-18 Thread Dixit, Ashutosh
On Tue, 18 Jul 2023 11:00:36 -0700, Belgaumkar, Vinay wrote:
>
>
> On 7/17/2023 9:26 PM, Dixit, Ashutosh wrote:
> > On Mon, 17 Jul 2023 21:19:13 -0700, Belgaumkar, Vinay wrote:
> >>
> >> On 7/17/2023 6:50 PM, Dixit, Ashutosh wrote:
> >>> On Mon, 17 Jul 2023 11:42:13 -0700, Vinay Belgaumkar wrote:
>  Some subtests seem to be failing in CI, use igt_assert_(lt/eq) which
>  print the values being compared and some additional debug as well.
> 
>  v2: Print GT as well (Ashutosh)
> 
>  Signed-off-by: Vinay Belgaumkar 
>  ---
> tests/i915/i915_pm_freq_api.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
> 
>  diff --git a/tests/i915/i915_pm_freq_api.c 
>  b/tests/i915/i915_pm_freq_api.c
>  index 522abee35..a7bbd4896 100644
>  --- a/tests/i915/i915_pm_freq_api.c
>  +++ b/tests/i915/i915_pm_freq_api.c
>  @@ -55,6 +55,7 @@ static void test_freq_basic_api(int dirfd, int gt)
>   rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
>   rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
>   rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
>  +igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d", gt, rpn, rpe, 
>  rp0);
> 
>   /*
>    * Negative bound tests
>  @@ -90,21 +91,18 @@ static void test_reset(int i915, int dirfd, int gt, 
>  int count)
>   int fd;
> 
>   for (int i = 0; i < count; i++) {
>  -igt_assert_f(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0,
>  - "Failed after %d good cycles\n", i);
>  -igt_assert_f(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0,
>  - "Failed after %d good cycles\n", i);
>  +igt_debug("Running cycle: %d", i);
>  +igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
>  +igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);
> >>> I am R-b'ing this but stuff like this should be using igt_assert_lt()
> >>> according to the commit message?
> >>>
> >>> This _lt stuff has to be fixed all over the file, not just this patch, if
> >>> it brings any value (again according to the commit message).
> >>>
> >>> Let me know if you want to fix this now or in a later patch. I'll wait
> >>> before merging.
> >> Yup, I will send out another version with the corrected commit message.
> > Hmm, I thought the code needs to be fixed not the commit message :)
>
> Ok, I meant this specific patch will address just the area where we check
> for the requested frequency. I will change the remaining in a separate
> patch.

Ok, merged. Thanks.


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume

2023-07-18 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Avoid endless HPD poll detect loop 
via runtime suspend/resume
URL   : https://patchwork.freedesktop.org/series/120931/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13394 -> Patchwork_120931v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/index.html

Participating hosts (44 -> 42)
--

  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_120931v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-bsw-nick:[PASS][1] -> [ABORT][2] ([i915#6687])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-bsw-nick/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/fi-bsw-nick/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@slpc:
- bat-mtlp-6: [PASS][3] -> [DMESG-WARN][4] ([i915#6367])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
- bat-rpls-2: NOTRUN -> [DMESG-WARN][5] ([i915#6367])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#7828])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][7] ([i915#1845])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [ABORT][8] ([i915#8434] / [i915#8442] / 
[i915#8668])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_psr@primary_page_flip:
- bat-rplp-1: NOTRUN -> [SKIP][9] ([i915#1072]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/bat-rplp-1/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-8700k:   [FAIL][10] ([i915#7940]) -> [PASS][11] +2 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-guc: [SKIP][12] ([fdo#109271]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-x1275:   [SKIP][14] ([fdo#109271]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-8809g:   [SKIP][16] ([fdo#109271]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-8809g/igt@i915_pm_...@basic-pci-d3-state.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/fi-kbl-8809g/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-cfl-guc: [FAIL][18] ([i915#7940]) -> [PASS][19] +2 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-guc/igt@i915_pm_...@basic-rte.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/fi-cfl-guc/igt@i915_pm_...@basic-rte.html
- fi-kbl-8809g:   [FAIL][20] ([i915#8843]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/fi-kbl-8809g/igt@i915_pm_...@basic-rte.html
- fi-tgl-1115g4:  [FAIL][22] ([i915#7940]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120931v1/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
- fi-skl-guc: [FAIL][24] ([i915#7940]) -> [PASS][25] +2 similar 
issues
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [25]: 

Re: [Intel-gfx] [igt-dev] [PATCH v2 i-g-t] i915_pm_freq_api: Add some debug to tests

2023-07-18 Thread Belgaumkar, Vinay



On 7/17/2023 9:26 PM, Dixit, Ashutosh wrote:

On Mon, 17 Jul 2023 21:19:13 -0700, Belgaumkar, Vinay wrote:


On 7/17/2023 6:50 PM, Dixit, Ashutosh wrote:

On Mon, 17 Jul 2023 11:42:13 -0700, Vinay Belgaumkar wrote:

Some subtests seem to be failing in CI, use igt_assert_(lt/eq) which
print the values being compared and some additional debug as well.

v2: Print GT as well (Ashutosh)

Signed-off-by: Vinay Belgaumkar 
---
   tests/i915/i915_pm_freq_api.c | 18 --
   1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c
index 522abee35..a7bbd4896 100644
--- a/tests/i915/i915_pm_freq_api.c
+++ b/tests/i915/i915_pm_freq_api.c
@@ -55,6 +55,7 @@ static void test_freq_basic_api(int dirfd, int gt)
rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
+   igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d", gt, rpn, rpe, rp0);

/*
 * Negative bound tests
@@ -90,21 +91,18 @@ static void test_reset(int i915, int dirfd, int gt, int 
count)
int fd;

for (int i = 0; i < count; i++) {
-   igt_assert_f(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0,
-"Failed after %d good cycles\n", i);
-   igt_assert_f(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0,
-"Failed after %d good cycles\n", i);
+   igt_debug("Running cycle: %d", i);
+   igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+   igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);

I am R-b'ing this but stuff like this should be using igt_assert_lt()
according to the commit message?

This _lt stuff has to be fixed all over the file, not just this patch, if
it brings any value (again according to the commit message).

Let me know if you want to fix this now or in a later patch. I'll wait
before merging.

Yup, I will send out another version with the corrected commit message.

Hmm, I thought the code needs to be fixed not the commit message :)


Ok, I meant this specific patch will address just the area where we 
check for the requested frequency. I will change the remaining in a 
separate patch.


Thanks,

Vinay.




Thanks,

Vinay.


Reviewed-by: Ashutosh Dixit 


usleep(ACT_FREQ_LATENCY_US);
-   igt_assert_f(get_freq(dirfd, RPS_CUR_FREQ_MHZ) == rpn,
-"Failed after %d good cycles\n", i);
+   igt_assert_eq(get_freq(dirfd, RPS_CUR_FREQ_MHZ), rpn);

/* Manually trigger a GT reset */
fd = igt_debugfs_gt_open(i915, gt, "reset", O_WRONLY);
igt_require(fd >= 0);
igt_ignore_warn(write(fd, "1\n", 2));

-   igt_assert_f(get_freq(dirfd, RPS_CUR_FREQ_MHZ) == rpn,
-"Failed after %d good cycles\n", i);
+   igt_assert_eq(get_freq(dirfd, RPS_CUR_FREQ_MHZ), rpn);
}
close(fd);
   }
@@ -116,13 +114,13 @@ static void test_suspend(int i915, int dirfd, int gt)
igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0);
usleep(ACT_FREQ_LATENCY_US);
-   igt_assert(get_freq(dirfd, RPS_CUR_FREQ_MHZ) == rpn);
+   igt_assert_eq(get_freq(dirfd, RPS_CUR_FREQ_MHZ), rpn);

/* Manually trigger a suspend */
igt_system_suspend_autoresume(SUSPEND_STATE_S3,
  SUSPEND_TEST_NONE);

-   igt_assert(get_freq(dirfd, RPS_CUR_FREQ_MHZ) == rpn);
+   igt_assert_eq(get_freq(dirfd, RPS_CUR_FREQ_MHZ), rpn);
   }

   int i915 = -1;
--
2.38.1



[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume

2023-07-18 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Avoid endless HPD poll detect loop 
via runtime suspend/resume
URL   : https://patchwork.freedesktop.org/series/120931/
State : warning

== Summary ==

Error: dim checkpatch failed
0aa33f8c1790 drm/i915: Avoid endless HPD poll detect loop via runtime 
suspend/resume
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#9: 
commit a8ddac7c9f06 ("drm/i915: Avoid HPD poll detect triggering a new detect 
cycle")

-:41: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'References:', use 
'Link:' or 'Closes:' instead
#41: 
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403

total: 0 errors, 2 warnings, 0 checks, 84 lines checked
c362e2937e34 drm: Add an HPD poll helper to reschedule the poll work
3f5f864c2c37 drm/i915: Fix HPD polling, reenabling the output poll work as 
needed




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume

2023-07-18 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Avoid endless HPD poll detect loop 
via runtime suspend/resume
URL   : https://patchwork.freedesktop.org/series/120931/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] [PATCH 1/3] drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume

2023-07-18 Thread Imre Deak
The issue fixed in

commit a8ddac7c9f06 ("drm/i915: Avoid HPD poll detect triggering a new detect 
cycle")

on VLV, CHV is still present on platforms where the display hotplug
detection functionality is available whenever the device is in D0 state
(hence these platforms switch to HPD polling only when the device is
runtime suspended).

The above commit avoids an endless i915_hpd_poll_init_work() ->
connector detect loop by making sure that by the end of
i915_hpd_poll_init_work() all display power references acquired by the
connector detect functions which can trigger a new cycle (display core
power domain) are dropped. However on platforms where HPD polling is
enabled/disabled only from the runtime suspend/resume handlers, this is
not ensured: for instance eDP VDD, TypeC port PHYs and the runtime
autosuspend delay may still keep the device runtime resumed (via a power
reference acquired during connector detection and hence result in an
endless loop like the above).

Solve the problem described in the above commit on all platforms, by
making sure that a i915_hpd_poll_init_work() -> connector detect
sequence can't take any power reference in the first place which would
trigger a new cycle, instead of relying on these power references to be
dropped by the end of the sequence.

With the default runtime autosuspend delay (10 sec) this issue didn't
happen in practice, since the device remained runtime resumed for the
whole duration of the above sequence. CI/IGT tests however set the
autospend delay to 0, which makes the problem visible, see References:
below.

Tested on GLK, CHV.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_crt.c |  6 -
 drivers/gpu/drm/i915/display/intel_dp.c  |  6 -
 drivers/gpu/drm/i915/display/intel_hdmi.c|  6 -
 drivers/gpu/drm/i915/display/intel_hotplug.c | 24 +++-
 4 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index 8090747586877..f66340b4caf0f 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -907,12 +907,6 @@ intel_crt_detect(struct drm_connector *connector,
 out:
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
 
-   /*
-* Make sure the refs for power wells enabled during detect are
-* dropped to avoid a new detect cycle triggered by HPD polling.
-*/
-   intel_display_power_flush_work(dev_priv);
-
return status;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 03675620e3ead..fd9859d98bd43 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4957,12 +4957,6 @@ intel_dp_detect(struct drm_connector *connector,
if (status != connector_status_connected && !intel_dp->is_mst)
intel_dp_unset_edid(intel_dp);
 
-   /*
-* Make sure the refs for power wells enabled during detect are
-* dropped to avoid a new detect cycle triggered by HPD polling.
-*/
-   intel_display_power_flush_work(dev_priv);
-
if (!intel_dp_is_edp(intel_dp))
drm_dp_set_subconnector_property(connector,
 status,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 8d1c8abfcffa1..14e133d192ab7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2522,12 +2522,6 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
if (status != connector_status_connected)
cec_notifier_phys_addr_invalidate(intel_hdmi->cec_notifier);
 
-   /*
-* Make sure the refs for power wells enabled during detect are
-* dropped to avoid a new detect cycle triggered by HPD polling.
-*/
-   intel_display_power_flush_work(dev_priv);
-
return status;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 0ff5ed46ae1e7..3780629bff95c 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -25,6 +25,7 @@
 
 #include "i915_drv.h"
 #include "i915_irq.h"
+#include "intel_display_power.h"
 #include "intel_display_types.h"
 #include "intel_hotplug.h"
 #include "intel_hotplug_irq.h"
@@ -638,11 +639,25 @@ static void i915_hpd_poll_init_work(struct work_struct 
*work)
 display.hotplug.poll_init_work);
struct drm_connector_list_iter conn_iter;
struct intel_connector *connector;
+   intel_wakeref_t wakeref;
bool enabled;
 
mutex_lock(_priv->drm.mode_config.mutex);
 
enabled = 

[Intel-gfx] [PATCH 3/3] drm/i915: Fix HPD polling, reenabling the output poll work as needed

2023-07-18 Thread Imre Deak
After the commit in the Fixes: line below, HPD polling stopped working
on i915, since after that change calling drm_kms_helper_poll_enable()
doesn't restart drm_mode_config::output_poll_work if the work was
stopped (no connectors needing polling) and enabling polling for a
connector (during runtime suspend or detecting an HPD IRQ storm).

After the above change calling drm_kms_helper_poll_enable() is a nop
after it's been called already and polling for some connectors was
disabled/re-enabled.

Fix this by calling drm_kms_helper_poll_reschedule() added in the
previous patch instead, which reschedules the work whenever expected.

Fixes: d33a54e3991d ("drm/probe_helper: sort out poll_running vs poll_enabled")
Cc: Dmitry Baryshkov 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 3780629bff95c..cc49040445f39 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -212,7 +212,7 @@ intel_hpd_irq_storm_switch_to_polling(struct 
drm_i915_private *dev_priv)
 
/* Enable polling and queue hotplug re-enabling. */
if (hpd_disabled) {
-   drm_kms_helper_poll_enable(_priv->drm);
+   drm_kms_helper_poll_reschedule(_priv->drm);
mod_delayed_work(dev_priv->unordered_wq,
 _priv->display.hotplug.reenable_work,
 msecs_to_jiffies(HPD_STORM_REENABLE_DELAY));
@@ -676,7 +676,7 @@ static void i915_hpd_poll_init_work(struct work_struct 
*work)
drm_connector_list_iter_end(_iter);
 
if (enabled)
-   drm_kms_helper_poll_enable(_priv->drm);
+   drm_kms_helper_poll_reschedule(_priv->drm);
 
mutex_unlock(_priv->drm.mode_config.mutex);
 
-- 
2.37.2



[Intel-gfx] [PATCH 2/3] drm: Add an HPD poll helper to reschedule the poll work

2023-07-18 Thread Imre Deak
Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was disabled for all connectors and hence
output_poll_work was not running).

This is needed by the next patch fixing HPD polling on i915.

Cc: Dmitry Baryshkov 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_probe_helper.c | 68 --
 include/drm/drm_probe_helper.h |  1 +
 2 files changed, 47 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 2fb9bf901a2cc..3f479483d7d80 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -262,6 +262,26 @@ static bool drm_kms_helper_enable_hpd(struct drm_device 
*dev)
 }
 
 #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
+static void reschedule_output_poll_work(struct drm_device *dev)
+{
+   unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
+
+   if (dev->mode_config.delayed_event)
+   /*
+* FIXME:
+*
+* Use short (1s) delay to handle the initial delayed event.
+* This delay should not be needed, but Optimus/nouveau will
+* fail in a mysterious way if the delayed event is handled as
+* soon as possible like it is done in
+* drm_helper_probe_single_connector_modes() in case the poll
+* was enabled before.
+*/
+   delay = HZ;
+
+   schedule_delayed_work(>mode_config.output_poll_work, delay);
+}
+
 /**
  * drm_kms_helper_poll_enable - re-enable output polling.
  * @dev: drm_device
@@ -279,37 +299,41 @@ static bool drm_kms_helper_enable_hpd(struct drm_device 
*dev)
  */
 void drm_kms_helper_poll_enable(struct drm_device *dev)
 {
-   bool poll = false;
-   unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
-
if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll ||
dev->mode_config.poll_running)
return;
 
-   poll = drm_kms_helper_enable_hpd(dev);
-
-   if (dev->mode_config.delayed_event) {
-   /*
-* FIXME:
-*
-* Use short (1s) delay to handle the initial delayed event.
-* This delay should not be needed, but Optimus/nouveau will
-* fail in a mysterious way if the delayed event is handled as
-* soon as possible like it is done in
-* drm_helper_probe_single_connector_modes() in case the poll
-* was enabled before.
-*/
-   poll = true;
-   delay = HZ;
-   }
-
-   if (poll)
-   schedule_delayed_work(>mode_config.output_poll_work, 
delay);
+   if (drm_kms_helper_enable_hpd(dev) ||
+   dev->mode_config.delayed_event)
+   reschedule_output_poll_work(dev);
 
dev->mode_config.poll_running = true;
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);
 
+/**
+ * drm_kms_helper_poll_reschedule - reschedule the output polling work
+ * @dev: drm_device
+ *
+ * This function reschedules the output polling work, after polling for a
+ * connector has been enabled.
+ *
+ * Drivers must call this helper after enabling polling for a connector by
+ * setting %DRM_CONNECTOR_POLL_CONNECT / %DRM_CONNECTOR_POLL_DISCONNECT flags
+ * in drm_connector::polled. Note that after disabling polling by clearing 
these
+ * flags for a connector will stop the output polling work automatically if
+ * the polling is disabled for all other connectors as well.
+ *
+ * The function can be called only after polling has been enabled by calling
+ * drm_kms_helper_poll_init() / drm_kms_helper_poll_enable().
+ */
+void drm_kms_helper_poll_reschedule(struct drm_device *dev)
+{
+   if (dev->mode_config.poll_running)
+   reschedule_output_poll_work(dev);
+}
+EXPORT_SYMBOL(drm_kms_helper_poll_reschedule);
+
 static enum drm_connector_status
 drm_helper_probe_detect_ctx(struct drm_connector *connector, bool force)
 {
diff --git a/include/drm/drm_probe_helper.h b/include/drm/drm_probe_helper.h
index 4977e0ab72dbb..fad3c4003b2b5 100644
--- a/include/drm/drm_probe_helper.h
+++ b/include/drm/drm_probe_helper.h
@@ -25,6 +25,7 @@ void drm_kms_helper_connector_hotplug_event(struct 
drm_connector *connector);
 
 void drm_kms_helper_poll_disable(struct drm_device *dev);
 void drm_kms_helper_poll_enable(struct drm_device *dev);
+void drm_kms_helper_poll_reschedule(struct drm_device *dev);
 bool drm_kms_helper_is_poll_worker(void);
 
 enum drm_mode_status drm_crtc_helper_mode_valid_fixed(struct drm_crtc *crtc,
-- 
2.37.2



Re: [Intel-gfx] [PATCH 1/2] drm/i915/perf: Subtract gtt_offset from hw_tail

2023-07-18 Thread Dixit, Ashutosh
On Tue, 18 Jul 2023 01:39:35 -0700, Lionel Landwerlin wrote:
>

Hi Lionel,

> On 18/07/2023 05:43, Ashutosh Dixit wrote:
> > The code in oa_buffer_check_unlocked() is correct only if the OA buffer is
> > 16 MB aligned (which seems to be the case today in i915). However when the
> > 16 MB alignment is dropped, when we "Subtract partial amount off the tail",
> > the "& (OA_BUFFER_SIZE - 1)" operation in OA_TAKEN() will result in an
> > incorrect hw_tail value.
> >
> > Therefore hw_tail must be brought to the same base as head and read_tail
> > prior to OA_TAKEN by subtracting gtt_offset from hw_tail.
> >
> > Signed-off-by: Ashutosh Dixit 
> > ---
> >   drivers/gpu/drm/i915/i915_perf.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index 49c6f1ff11284..f7888a44d1284 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -565,6 +565,7 @@ static bool oa_buffer_check_unlocked(struct 
> > i915_perf_stream *stream)
> > partial_report_size %= report_size;
> > /* Subtract partial amount off the tail */
> > +   hw_tail -= gtt_offset;
> > hw_tail = OA_TAKEN(hw_tail, partial_report_size);
> > /* NB: The head we observe here might effectively be a little
>
>
> You should squash this patch with the next one. Otherwise further down this
> function there is another
>
> hw_tail -= gtt_offset;

Are you looking at old code, because this line is not there in this
function any more. There have been several changes to the function lately,
aging tail etc. is gone e.g.

But otherwise you are right, Patch 2 basically writes over Patch 1, so the
two patches can be squashed. I separated out Patch 1 since it shows the bug
(incidentally the bug doesn't show up in i915 since a 16 MB BO in i915 is
16 MB aligned, I discovered the bug while porting stuff to xe).

So if you are going to R-b this series I can repost after squashing. But if
we wait for Umesh to return (he is out till the end of the month) and
review this, I'd rather leave the two patches as they are till Umesh
reviews them.

Thanks.
--
Ashutosh


Re: [Intel-gfx] [PATCH v15 00/26] Add vfio_device cdev for iommufd support

2023-07-18 Thread Jason Gunthorpe
On Tue, Jul 18, 2023 at 06:55:25AM -0700, Yi Liu wrote:
> Existing VFIO provides group-centric user APIs for userspace. Userspace
> opens the /dev/vfio/$group_id first before getting device fd and hence
> getting access to device. This is not the desired model for iommufd. Per
> the conclusion of community discussion[1], iommufd provides device-centric
> kAPIs and requires its consumer (like VFIO) to be device-centric user
> APIs. Such user APIs are used to associate device with iommufd and also
> the I/O address spaces managed by the iommufd.
> 
> This series first introduces a per device file structure to be prepared
> for further enhancement and refactors the kvm-vfio code to be prepared
> for accepting device file from userspace. After this, adds a mechanism for
> blocking device access before iommufd bind. Then refactors the vfio to be
> able to handle cdev paths (e.g. iommufd binding, no-iommufd, [de]attach ioas).
> This refactor includes making the device_open exclusive between the group
> and the cdev path, only allow single device open in cdev path; vfio-iommufd
> code is also refactored to support cdev. e.g. split the vfio_iommufd_bind()
> into two steps. Eventually, adds the cdev support for vfio device and the
> new ioctls, then makes group infrastructure optional as it is not needed
> when vfio device cdev is compiled.
> 
> This series is based on some preparation works done to vfio emulated 
> devices[2]
> and vfio pci hot reset enhancements[3]. Per discussion[4], this series does 
> not
> support cdev for physical devices that do not have IOMMU. Such devices only
> have group-centric user APIs.
> 
> This series is a prerequisite for iommu nesting for vfio device[5] [6].
> 
> The complete code can be found in below branch, simple tests done to the
> legacy group path and the cdev path. QEMU changes are in upstreaming[7]
> and the complete code can be found at[8]
> 
> https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v15
> (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)

Alex, if you are still good with this lets make this into a shared
branch, do you want to do it or would you like a PR from me?

Thanks,
Jason


Re: [Intel-gfx] [PATCH v15 22/26] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

2023-07-18 Thread Jason Gunthorpe
On Tue, Jul 18, 2023 at 06:55:47AM -0700, Yi Liu wrote:
> This adds ioctl for userspace to bind device cdev fd to iommufd.
> 
> VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain DMA
> control provided by the iommufd. open_device
> op is called after bind_iommufd op.
> 
> Tested-by: Nicolin Chen 
> Tested-by: Matthew Rosato 
> Tested-by: Yanting Jiang 
> Tested-by: Shameer Kolothum 
> Tested-by: Terrence Xu 
> Tested-by: Zhenzhong Duan 
> Signed-off-by: Yi Liu 
> ---
>  drivers/vfio/device_cdev.c | 107 +
>  drivers/vfio/vfio.h|  13 +
>  drivers/vfio/vfio_main.c   |   5 ++
>  include/linux/vfio.h   |   5 +-
>  include/uapi/linux/vfio.h  |  27 ++
>  5 files changed, 155 insertions(+), 2 deletions(-)

Reviewed-by: Jason Gunthorpe 

Jason


Re: [Intel-gfx] [PATCH v15 20/26] iommufd: Add iommufd_ctx_from_fd()

2023-07-18 Thread Jason Gunthorpe
On Tue, Jul 18, 2023 at 06:55:45AM -0700, Yi Liu wrote:
> It's common to get a reference to the iommufd context from a given file
> descriptor. So adds an API for it. Existing users of this API are compiled
> only when IOMMUFD is enabled, so no need to have a stub for the IOMMUFD
> disabled case.
> 
> Signed-off-by: Yi Liu 
> ---
>  drivers/iommu/iommufd/main.c | 24 
>  include/linux/iommufd.h  |  1 +
>  2 files changed, 25 insertions(+)

Reviewed-by: Jason Gunthorpe 

Jason


Re: [Intel-gfx] [PATCH v10 09/10] vfio/pci: Copy hot-reset device info to userspace in the devices loop

2023-07-18 Thread Jason Gunthorpe
On Tue, Jul 18, 2023 at 03:55:41AM -0700, Yi Liu wrote:
> This copies the vfio_pci_dependent_device to userspace during looping each
> affected device for reporting vfio_pci_hot_reset_info. This avoids counting
> the affected devices and allocating a potential large buffer to store the
> vfio_pci_dependent_device of all the affected devices before copying them
> to userspace.
> 
> Suggested-by: Jason Gunthorpe 
> Tested-by: Yanting Jiang 
> Tested-by: Zhenzhong Duan 
> Signed-off-by: Jason Gunthorpe 
> Signed-off-by: Yi Liu 
> ---
>  drivers/vfio/pci/vfio_pci_core.c | 93 
>  1 file changed, 33 insertions(+), 60 deletions(-)

Reviewed-by: Jason Gunthorpe 

Jason


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Refactor PAT/object cache handling

2023-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915: Refactor PAT/object cache handling
URL   : https://patchwork.freedesktop.org/series/120924/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13394 -> Patchwork_120924v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_120924v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_120924v1, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/index.html

Participating hosts (44 -> 43)
--

  Missing(1): fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_120924v1:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_parallel@engines@userptr:
- bat-dg1-5:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg1-5/igt@gem_exec_parallel@engi...@userptr.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/bat-dg1-5/igt@gem_exec_parallel@engi...@userptr.html
- bat-dg1-7:  [PASS][3] -> [ABORT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg1-7/igt@gem_exec_parallel@engi...@userptr.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/bat-dg1-7/igt@gem_exec_parallel@engi...@userptr.html
- bat-dg2-9:  [PASS][5] -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-9/igt@gem_exec_parallel@engi...@userptr.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/bat-dg2-9/igt@gem_exec_parallel@engi...@userptr.html
- bat-dg2-11: [PASS][7] -> [ABORT][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-11/igt@gem_exec_parallel@engi...@userptr.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/bat-dg2-11/igt@gem_exec_parallel@engi...@userptr.html
- bat-atsm-1: [PASS][9] -> [ABORT][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-atsm-1/igt@gem_exec_parallel@engi...@userptr.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/bat-atsm-1/igt@gem_exec_parallel@engi...@userptr.html
- bat-dg2-8:  [PASS][11] -> [ABORT][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-8/igt@gem_exec_parallel@engi...@userptr.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/bat-dg2-8/igt@gem_exec_parallel@engi...@userptr.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_parallel@engines@userptr:
- {bat-dg2-13}:   [PASS][13] -> [ABORT][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-13/igt@gem_exec_parallel@engi...@userptr.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/bat-dg2-13/igt@gem_exec_parallel@engi...@userptr.html
- {bat-dg2-14}:   [PASS][15] -> [ABORT][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-14/igt@gem_exec_parallel@engi...@userptr.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/bat-dg2-14/igt@gem_exec_parallel@engi...@userptr.html

  
Known issues


  Here are the changes found in Patchwork_120924v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@load:
- fi-kbl-7567u:   [PASS][17] -> [ABORT][18] ([i915#8141])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-7567u/igt@i915_module_l...@load.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/fi-kbl-7567u/igt@i915_module_l...@load.html
- fi-cfl-8109u:   [PASS][19] -> [ABORT][20] ([i915#8141])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-8109u/igt@i915_module_l...@load.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/fi-cfl-8109u/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][21] -> [INCOMPLETE][22] ([i915#7913])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120924v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [PASS][23] -> [DMESG-FAIL][24] ([i915#5334])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [24]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Refactor PAT/object cache handling

2023-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915: Refactor PAT/object cache handling
URL   : https://patchwork.freedesktop.org/series/120924/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Refactor PAT/object cache handling

2023-07-18 Thread Patchwork
== Series Details ==

Series: drm/i915: Refactor PAT/object cache handling
URL   : https://patchwork.freedesktop.org/series/120924/
State : warning

== Summary ==

Error: dim checkpatch failed
ad8a0b08444d drm/i915: Refactor PAT/object cache handling
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:797: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#797: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c:63:
+i915_ttm_cache_pat(struct drm_i915_private *i915, struct ttm_resource *res,
 struct ttm_tt *ttm)

-:1410: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#1410: 
new file mode 100644

-:1415: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#1415: FILE: drivers/gpu/drm/i915/i915_cache.c:1:
+/*

-:1416: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use 
line 1 instead
#1416: FILE: drivers/gpu/drm/i915/i915_cache.c:2:
+ * SPDX-License-Identifier: MIT

-:1473: WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should 
probably be static const char * const
#1473: FILE: drivers/gpu/drm/i915/i915_cache.c:59:
+   static const char *mode_str[] = {

-:1479: WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should 
probably be static const char * const
#1479: FILE: drivers/gpu/drm/i915/i915_cache.c:65:
+   static const char *flag_str[] = {

-:1529: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#1529: FILE: drivers/gpu/drm/i915/i915_cache.h:17:
+#define I915_CACHE(mode) \
+   (i915_cache_t)(I915_CACHE_MODE_##mode)

-:1534: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#1534: FILE: drivers/gpu/drm/i915/i915_cache.h:22:
+#define _I915_CACHE(mode, flag) \
+   (i915_cache_t)((I915_CACHE_MODE_##mode) | __I915_CACHE_FLAG(flag))

-:1537: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#1537: FILE: drivers/gpu/drm/i915/i915_cache.h:25:
+#define __I915_CACHE(mode, flags) \
+   (i915_cache_t)((I915_CACHE_MODE_##mode) | ((flags) << 8))

-:1540: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#1540: FILE: drivers/gpu/drm/i915/i915_cache.h:28:
+#define I915_CACHE_MODE(cache) \
+   (enum i915_cache_mode)(((i915_cache_t)(cache)) & 0xff)

-:1542: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#1542: FILE: drivers/gpu/drm/i915/i915_cache.h:30:
+#define I915_CACHE_FLAGS(cache) \
+   (unsigned int)i915_cache_t)(cache) & 0xff00)) >> 8)

-:2139: WARNING:LINE_CONTINUATIONS: Avoid unnecessary line continuations
#2139: FILE: drivers/gpu/drm/i915/selftests/mock_gem_device.c:134:
+   [2] = __I915_CACHE(WB, BIT(I915_CACHE_FLAG_COH1W) | 
BIT(I915_CACHE_FLAG_L3)), \

total: 5 errors, 6 warnings, 1 checks, 1767 lines checked




[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Move setting of rps thresholds to init (rev3)

2023-07-18 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915: Move setting of rps thresholds 
to init (rev3)
URL   : https://patchwork.freedesktop.org/series/120857/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13394 -> Patchwork_120857v3


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/index.html

Participating hosts (44 -> 42)
--

  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_120857v3 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@core_auth@basic-auth:
- bat-adlp-11:NOTRUN -> [ABORT][1] ([i915#8011])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-adlp-11/igt@core_a...@basic-auth.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-rkl-11600:   [PASS][2] -> [FAIL][3] ([fdo#103375] / [i915#8011])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
- bat-jsl-3:  [PASS][4] -> [ABORT][5] ([i915#5122])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@module-reload:
- fi-rkl-11600:   [PASS][6] -> [FAIL][7] ([i915#7940])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-rkl-11600/igt@i915_pm_...@module-reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/fi-rkl-11600/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-7567u:   [PASS][8] -> [DMESG-FAIL][9] ([i915#5334])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-6: [PASS][10] -> [ABORT][11] ([i915#7982])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-6/igt@i915_selftest@l...@requests.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-mtlp-6/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][12] ([i915#6367])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html
- bat-mtlp-8: [PASS][13] -> [DMESG-WARN][14] ([i915#6367])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-8/igt@i915_selftest@l...@slpc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-mtlp-8/igt@i915_selftest@l...@slpc.html

  * igt@i915_selftest@live@workarounds:
- bat-dg1-7:  [PASS][15] -> [ABORT][16] ([i915#4983])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg1-7/igt@i915_selftest@l...@workarounds.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-dg1-7/igt@i915_selftest@l...@workarounds.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-jsl-3:  [PASS][17] -> [FAIL][18] ([fdo#103375])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#7828])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html
- fi-bsw-n3050:   NOTRUN -> [SKIP][20] ([fdo#109271])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/fi-bsw-n3050/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][21] ([i915#1845])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-guc: [FAIL][22] ([i915#7940]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120857v3/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-kbl-x1275:   [SKIP][24] ([fdo#109271]) -> [PASS][25]
   [24]: 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add vfio_device cdev for iommufd support (rev19)

2023-07-18 Thread Patchwork
== Series Details ==

Series: Add vfio_device cdev for iommufd support (rev19)
URL   : https://patchwork.freedesktop.org/series/113696/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/19/mbox/ not 
applied
Applying: vfio: Allocate per device file structure
Applying: vfio: Refine vfio file kAPIs for KVM
Applying: vfio: Accept vfio device file in the KVM facing kAPI
Applying: kvm/vfio: Prepare for accepting vfio device fd
Applying: kvm/vfio: Accept vfio device file from userspace
Applying: vfio: Pass struct vfio_device_file * to vfio_device_open/close()
Applying: vfio: Block device access via device fd until device is opened
Applying: vfio: Add cdev_device_open_cnt to vfio_group
Applying: vfio: Make vfio_df_open() single open for device cdev path
Applying: vfio-iommufd: Move noiommu compat validation out of 
vfio_iommufd_bind()
Applying: vfio-iommufd: Split bind/attach into two steps
Applying: vfio: Record devid in vfio_device_file
Applying: vfio-iommufd: Add detach_ioas support for physical VFIO devices
Applying: iommufd/device: Add iommufd_access_detach() API
Applying: vfio-iommufd: Add detach_ioas support for emulated VFIO devices
error: sha1 information is lacking or useless (drivers/vfio/iommufd.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0015 vfio-iommufd: Add detach_ioas support for emulated VFIO 
devices
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced




Re: [Intel-gfx] [PATCH v4 2/6] drm/i915/gt: Ensure memory quiesced before invalidation

2023-07-18 Thread Matt Roper
On Tue, Jul 18, 2023 at 02:28:26AM +0200, Andi Shyti wrote:
> Hi Matt,
> 
> > > > > > +   /*
> > > > > > +* Aux invalidations on Aux CCS platforms require
> > > > > > +* memory traffic is quiesced prior.
> > > > > > +*/
> > > > > > +   if ((mode & EMIT_INVALIDATE) && !HAS_FLAT_CCS(engine->i915))
> > > > > 
> > > > > It's a pre-existing mistake in drm-tip at the moment, but we shouldn't
> > > > > assume !flatccs always implies auxccs.  PVC has neither, and there may
> > > > > be other similar platforms in the future.  We should probably add a
> > > > > helper function for AuxCCS, similar to what we added to the Xe driver
> > > > > recently:
> > > > > 
> > > > > https://patchwork.freedesktop.org/patch/539304/?series=118334=1
> > > 
> > > Currently that is done in patch 6...
> > 
> > Are you sure?  Patch #6 consolidates things a bit, but is still incorrectly
> > assuming flatccs = !auxccs:
> > 
> >if (HAS_FLAT_CCS(engine->i915))  
> >   
> >return _MMIO(0); 
> >   
> 
> But isn't it the same the patch you linked is doing?
> 
>   return !xe->info.has_flat_ccs;

No, that's just the end of the function.  The important
platform-specific checks come before that point (at the moment we only
have PVC, but we expect more platforms to be added there very soon too).


Matt

> 
> And

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation


[Intel-gfx] ✗ Fi.CI.BUILD: failure for Update AUX invalidation sequence (rev5)

2023-07-18 Thread Patchwork
== Series Details ==

Series: Update AUX invalidation sequence (rev5)
URL   : https://patchwork.freedesktop.org/series/119798/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/119798/revisions/5/mbox/ not 
applied
Applying: drm-tip: 2023y-07m-17d-16h-04m-53s UTC integration manifest
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
CONFLICT (add/add): Merge conflict in integration-manifest
Auto-merging integration-manifest
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm-tip: 2023y-07m-17d-16h-04m-53s UTC integration manifest
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced




Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine

2023-07-18 Thread Tvrtko Ursulin



On 17/07/2023 19:03, John Harrison wrote:

On 7/13/2023 05:11, Tvrtko Ursulin wrote:

On 13/07/2023 12:09, Andrzej Hajda wrote:

Hi,

On 13.07.2023 09:39, Tvrtko Ursulin wrote:

On 12/07/2023 19:54, John Harrison wrote:

On 7/12/2023 09:27, Andrzej Hajda wrote:

On 12.07.2023 14:35, Tvrtko Ursulin wrote:

On 12/07/2023 13:18, Andrzej Hajda wrote:

On 11.07.2023 17:27, Tvrtko Ursulin wrote:

On 11/07/2023 14:58, Andrzej Hajda wrote:

On 11.07.2023 13:34, Andi Shyti wrote:

Hi Andrzej,

drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 
+++

  1 file changed, 11 insertions(+)

 diff --git 
a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c

 index a0e3ef1c65d246..2c877ea5eda6f0 100644
 --- 
a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
 +++ 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
 @@ -3461,6 +3461,8 @@ static void 
guc_prio_fini(struct i915_request *rq, struct intel_context 
*ce)
  static void remove_from_context(struct 
i915_request *rq)

  {
 struct intel_context *ce = 
request_to_scheduling_context(rq);

 +   struct intel_engine_cs *engine;
 +   intel_engine_mask_t tmp;

GEM_BUG_ON(intel_context_is_child(ce));

 @@ -3478,6 +3480,15 @@ static void 
remove_from_context(struct i915_request *rq)


atomic_dec(>guc_id.ref);
i915_request_notify_execute_cb_imm(rq);
 +
 +   /*
 +    * GuC virtual engine can disappear after 
this call, so let's assign
 +    * something valid, as driver expects this 
to be always valid pointer.

 +    */
 + for_each_engine_masked(engine, rq->engine->gt, 
rq->execution_mask, tmp) {

 +   rq->engine = engine;

 yes... here the context might lose the virtual 
engine... I wonder
 whether this is the rigth solution, though. Maybe we 
should set

 rq->engine = NULL; and check for NULL? Don't know.


Setting NULL causes occasional null page de-reference in

i915_request_wait_timeout:

mutex_release(>engine->gt->reset.mutex.dep_map, _THIS_IP_)

rq->engine after removing rq from context is (IMHO) used as 
a set of aliases

for gt and i915 (despite rq itself contains the alias to i915).

without investigating further, but maybe that code is not even
supposed to be executed, at this point, if the request's 
assigned

virtual engine is removed.


Real tests show it is executed and the function 
i915_request_wait_timeout is quite generic
I guess it is quite typical use-case, the only question is 
about timings - what happens earlier -

finalization of i915_request_wait_timeout or context removal.

The other point rq->engine is accessed after context removal 
is i915_fence_release -
there is long comment there regarding virtual context and 
reuse retired rq.
Anyway calling there "intel_engine_is_virtual(rq->engine)" is 
risky without this patch and KASAN complains clearly about it:

http://gfx-ci.igk.intel.com/tree/drm-tip/kasan.html?testfilter=gem_exec_balancer


Looks like a bug introduced in bcb9aa45d5a0 ("Revert "drm/i915: 
Hold reference to intel_context over life of i915_request""), 
which was a partial revert of 1e98d8c52ed5 ("drm/i915: Hold 
reference to intel_context over life of i915_request").


Ie. if 1e98d8c52ed5 recognised the problem with disappearing 
rq->engine, then I am confused how bcb9aa45d5a0 left the 
rq->engine dereference in there after removing the extra 
reference.


Could it be that the intel_engine_is_virtual check simply needs 
to be removed from i915_fence_release, restoring things to how 
they were before 1e98d8c52ed5? Could you try it out?



I have already tried something similar [1] and KASAN bugs 
disappeared, or more precisely gem_exec_balance tests passed. 
But I have been warned by Nirmoy guc virtual engines can be 
created for only one real engine (ie. 
is_power_of_2(rq->execution_mask) is true but rq->engine points 
to virtual engine).


[1]: https://patchwork.freedesktop.org/series/118879/


Ugh.. Try involving media umd folks to see if they need a single 
engine virtual engine? Or we could always just not create it in 
the driver, I mean just use the physical one.



In case there is single physical engine 
intel_engine_create_virtual falls back to intel_context_create (no 
virtual engine), but in case of parallel contexts there is special 
KMD flag FORCE_VIRTUAL which enforces virtual engine even for 
single physical engine. So it seems to be KMD concept.


Anyway is it worth investigating how to make 
"is_power_of_2(rq->execution_mask)" indication of dangling engine 
pointer? It will not help in 1st case:

mutex_release(>engine->gt->reset.mutex.dep_map, _THIS_IP_)


There seems to be a fundamental problem here. Object 1 (rq) is 
holding a pointer to a reference counted and transient object 2 
(engine) but without taking a reference count for itself. That is a 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915: Move setting of rps thresholds to init (rev3)

2023-07-18 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915: Move setting of rps thresholds 
to init (rev3)
URL   : https://patchwork.freedesktop.org/series/120857/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915: Move setting of rps thresholds to init (rev3)

2023-07-18 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915: Move setting of rps thresholds 
to init (rev3)
URL   : https://patchwork.freedesktop.org/series/120857/
State : warning

== Summary ==

Error: dim checkpatch failed
225af759e3c0 drm/i915: Move setting of rps thresholds to init
-:6: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 36d516be867c ("drm/i915/gt: 
Switch to manual evaluation of RPS")'
#6: 
Since 36d516be867c ("drm/i915/gt: Switch to manual evaluation of RPS")

total: 1 errors, 0 warnings, 0 checks, 73 lines checked
3022f7532463 drm/i915: Record default rps threshold values
ce890a1dae12 drm/i915: Add helpers for managing rps thresholds
7c832a7ad12d drm/i915: Expose RPS thresholds in sysfs




[Intel-gfx] ✓ Fi.CI.IGT: success for Enhance vfio PCI hot reset for vfio cdev device (rev10)

2023-07-18 Thread Patchwork
== Series Details ==

Series: Enhance vfio PCI hot reset for vfio cdev device (rev10)
URL   : https://patchwork.freedesktop.org/series/116991/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13393_full -> Patchwork_116991v10_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


  Here are the changes found in Patchwork_116991v10_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@drm_fdinfo@all-busy-check-all:
- shard-dg2:  NOTRUN -> [SKIP][1] ([i915#8414])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-dg2-7/igt@drm_fdi...@all-busy-check-all.html

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl:  [PASS][2] -> [FAIL][3] ([i915#7742])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@feature_discovery@chamelium:
- shard-dg2:  NOTRUN -> [SKIP][4] ([i915#4854])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-dg2-7/igt@feature_discov...@chamelium.html

  * igt@gem_ctx_persistence@engines-persistence:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-snb4/igt@gem_ctx_persiste...@engines-persistence.html

  * igt@gem_eio@hibernate:
- shard-dg2:  NOTRUN -> [ABORT][6] ([i915#7975] / [i915#8213])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-dg2-7/igt@gem_...@hibernate.html

  * igt@gem_eio@kms:
- shard-dg2:  [PASS][7] -> [INCOMPLETE][8] ([i915#1982] / 
[i915#7892])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/shard-dg2-5/igt@gem_...@kms.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-dg2-1/igt@gem_...@kms.html

  * igt@gem_eio@reset-stress:
- shard-snb:  NOTRUN -> [FAIL][9] ([i915#8898])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-snb1/igt@gem_...@reset-stress.html

  * igt@gem_eio@unwedge-stress:
- shard-tglu: [PASS][10] -> [TIMEOUT][11] ([i915#3063] / 
[i915#7941])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/shard-tglu-5/igt@gem_...@unwedge-stress.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-tglu-6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2846])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/shard-glk1/igt@gem_exec_f...@basic-deadline.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-glk6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-rrul:
- shard-dg2:  NOTRUN -> [SKIP][14] ([i915#3539] / [i915#4852])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-dg2-7/igt@gem_exec_f...@basic-none-rrul.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-rkl:  [PASS][15] -> [FAIL][16] ([i915#2842]) +2 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/shard-rkl-3/igt@gem_exec_fair@basic-p...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-rkl-1/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-tglu: NOTRUN -> [FAIL][17] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-tglu-3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_reloc@basic-gtt-wc-active:
- shard-dg2:  NOTRUN -> [SKIP][18] ([i915#3281]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-dg2-7/igt@gem_exec_re...@basic-gtt-wc-active.html

  * igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [PASS][19] -> [ABORT][20] ([i915#8131])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/shard-mtlp-8/igt@gem_exec_whis...@basic-contexts-forked-all.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-mtlp-8/igt@gem_exec_whis...@basic-contexts-forked-all.html

  * igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-glk:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/shard-glk6/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html

  * igt@gem_lmem_swapping@verify-ccs:
- shard-tglu: NOTRUN -> [SKIP][22] ([i915#4613])
   [22]: 

Re: [Intel-gfx] [PATCH v5 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

2023-07-18 Thread Nirmoy Das

Hi Andi,

On 7/18/2023 3:38 PM, Andi Shyti wrote:

Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before
invalidation") has made sure that the memory is quiesced before
invalidating the AUX CCS table. Do it for all the other engines
and not just RCS.

Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Matt Roper 
---
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 71 +---
  drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
  2 files changed, 62 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 3275e55b18d90..2f40cd515cc78 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -225,6 +225,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
  
  		bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
  
+		/*

+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+
bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
@@ -309,20 +316,64 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
  int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
  {
intel_engine_mask_t aux_inv = 0;
-   u32 cmd, *cs;
+   u32 cmd = 4;
+   u32 *cs;
  
-	cmd = 4;

-   if (mode & EMIT_INVALIDATE) {
+   if (mode & EMIT_INVALIDATE)
cmd += 2;
  
-		if (HAS_AUX_CCS(rq->engine->i915) &&

-   (rq->engine->class == VIDEO_DECODE_CLASS ||
-rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
-   aux_inv = rq->engine->mask &
-   ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-   if (aux_inv)
-   cmd += 4;
+   if (HAS_AUX_CCS(rq->engine->i915))
+   aux_inv = rq->engine->mask &
+ ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
+
+   /*
+* Aux invalidations on Aux CCS platforms require
+* memory traffic is quiesced prior.
+*/
+   if (aux_inv) {
+   u32 bit_group_0 = 0;
+   u32 bit_group_1 = 0;
+
+   cmd += 4;
+
+   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+
+   switch (rq->engine->class) {
+   case VIDEO_DECODE_CLASS:
+   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
+   bit_group_1 |= PIPE_CONTROL_CS_STALL;
+
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+
+   break;
+
+   case VIDEO_ENHANCEMENT_CLASS:
+   case COMPUTE_CLASS:
+   bit_group_1 |= MI_FLUSH_DW;
+
+   break;
+
+   case COPY_ENGINE_CLASS:
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+   break;
}
+
+   if (bit_group_1 || bit_group_0)
+   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+  LRC_PPHWSP_SCRATCH_ADDR);



The pipe control is limited to render and compute engines only and

gen12_emit_flush_xcs() gets called only for other engines(BCS,VE,VD) AFAIU. So 
I imagine changes for this patch as:

gen12_emit_flush_rcs()
pipe_control with CCS_FLUSH
AUX CCS inval
gen12_emit_flush_xcs()
MI_FLUSH_DW (with CCS flush for BCS)
AUX CCS inval

(Note that ccs flush bit for MI_FLUSH_DW is at 16 )

Regards,
Nirmoy


}
  
  	cs = intel_ring_begin(rq, cmd);

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5d143e2a8db03..5df7cce23197c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -299,6 +299,7 @@
  #define   PIPE_CONTROL_QW_WRITE 

[Intel-gfx] [PATCH v2] drm/i915: Refactor PAT/object cache handling

2023-07-18 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
introduced PAT indices to i915 internal APIs, partially replacing the
usage of driver internal cache_level, but has also added a few
questionable design decisions which this patch tries to improve upon.

Principal change is to invert the per platform cache level to PAT index
table which was added by the referenced commit, and by doing so enable
i915 to understand the cache mode between PAT indices, changing them from
opaque to transparent.

Once we have the inverted table we are able to remove the hidden false
"return true" from i915_gem_object_has_cache_level.

Other changes/fixes/improvements we are able to do:

1)
Replace the enum i915_cache_level with i915_cache_t, composed of a more
detailed representation of each cache mode (base mode plus flags).

For instance this way we are able to express the difference between WB and
1-way coherent WB on Meteorlake. Which in turn enables us to map the i915
"cached" mode to the correct Meteorlake PAT index.

2)
We can cache PAT indices of the caching modes used by the driver itself in
struct drm_i915_private, which eliminates the runtime calls to
i915_gem_get_pat_index from both high- and low-level i915 components.

3)
We can also cache the caching modes used by the driver for coherent
access and for display buffers.

4)
Remove the incorrect references to enum i915_cache_level from low level
PTE encode vfuncs, since those are actually given PAT indices by their
callers.

5)
Because i915 now understands PAT indices, we can remove the overly
aggressive flushing triggered from i915_gem_object_can_bypass_llc() and
limit it to non-coherent write-back mode only.

6)
Finally we are able to replace the platform dependent cache mode to string
code in debugfs and elsewhere by the single implementation based on
i915_cache_t.

v2:
 * Fix PAT-to-cache-mode table for PVC. (Fei)
 * Cache display caching mode too. (Fei)
 * Improve and document criteria in i915_gem_object_can_bypass_llc() (Matt)

Signed-off-by: Tvrtko Ursulin 
Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
Cc: Chris Wilson 
Cc: Fei Yang 
Cc: Andi Shyti 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../drm/i915/display/intel_plane_initial.c|   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c|  56 +++
 drivers/gpu/drm/i915/gem/i915_gem_domain.h|   5 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  13 +-
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  12 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 147 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  11 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 116 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |   8 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  11 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  44 +++---
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   2 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |   4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   6 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |   4 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  19 +--
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  33 ++--
 drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   3 +-
 drivers/gpu/drm/i915/gt/intel_migrate.c   |  11 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   6 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   4 +-
 drivers/gpu/drm/i915/gt/intel_timeline.c  |   2 +-
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   2 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c|   9 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  14 +-
 drivers/gpu/drm/i915/gt/selftest_tlb.c|   5 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |   8 +-
 drivers/gpu/drm/i915/i915_cache.c |  92 +++
 drivers/gpu/drm/i915/i915_cache.h |  61 
 drivers/gpu/drm/i915/i915_debugfs.c   |  53 +--
 drivers/gpu/drm/i915/i915_driver.c|   5 +
 drivers/gpu/drm/i915/i915_drv.h   |   5 +
 drivers/gpu/drm/i915/i915_gem.c   |  21 +--
 drivers/gpu/drm/i915/i915_gpu_error.c |   7 +-
 drivers/gpu/drm/i915/i915_pci.c   |  82 +-
 drivers/gpu/drm/i915/i915_perf.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.h  |   6 +-
 drivers/gpu/drm/i915/selftests/i915_gem.c |   5 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |   8 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  13 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c  |   2 +-
 .../drm/i915/selftests/intel_memory_region.c  |   4 +-
 

[Intel-gfx] [PATCH v15 26/26] docs: vfio: Add vfio device cdev description

2023-07-18 Thread Yi Liu
This gives notes for userspace applications on device cdev usage.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Yi Liu 
---
 Documentation/driver-api/vfio.rst | 139 ++
 1 file changed, 139 insertions(+)

diff --git a/Documentation/driver-api/vfio.rst 
b/Documentation/driver-api/vfio.rst
index 363e12c90b87..633d11c7fa71 100644
--- a/Documentation/driver-api/vfio.rst
+++ b/Documentation/driver-api/vfio.rst
@@ -239,6 +239,137 @@ group and can access them as follows::
/* Gratuitous device reset and go... */
ioctl(device, VFIO_DEVICE_RESET);
 
+IOMMUFD and vfio_iommu_type1
+
+
+IOMMUFD is the new user API to manage I/O page tables from userspace.
+It intends to be the portal of delivering advanced userspace DMA
+features (nested translation [5]_, PASID [6]_, etc.) while also providing
+a backwards compatibility interface for existing VFIO_TYPE1v2_IOMMU use
+cases.  Eventually the vfio_iommu_type1 driver, as well as the legacy
+vfio container and group model is intended to be deprecated.
+
+The IOMMUFD backwards compatibility interface can be enabled two ways.
+In the first method, the kernel can be configured with
+CONFIG_IOMMUFD_VFIO_CONTAINER, in which case the IOMMUFD subsystem
+transparently provides the entire infrastructure for the VFIO
+container and IOMMU backend interfaces.  The compatibility mode can
+also be accessed if the VFIO container interface, ie. /dev/vfio/vfio is
+simply symlink'd to /dev/iommu.  Note that at the time of writing, the
+compatibility mode is not entirely feature complete relative to
+VFIO_TYPE1v2_IOMMU (ex. DMA mapping MMIO) and does not attempt to
+provide compatibility to the VFIO_SPAPR_TCE_IOMMU interface.  Therefore
+it is not generally advisable at this time to switch from native VFIO
+implementations to the IOMMUFD compatibility interfaces.
+
+Long term, VFIO users should migrate to device access through the cdev
+interface described below, and native access through the IOMMUFD
+provided interfaces.
+
+VFIO Device cdev
+
+
+Traditionally user acquires a device fd via VFIO_GROUP_GET_DEVICE_FD
+in a VFIO group.
+
+With CONFIG_VFIO_DEVICE_CDEV=y the user can now acquire a device fd
+by directly opening a character device /dev/vfio/devices/vfioX where
+"X" is the number allocated uniquely by VFIO for registered devices.
+cdev interface does not support noiommu devices, so user should use
+the legacy group interface if noiommu is wanted.
+
+The cdev only works with IOMMUFD.  Both VFIO drivers and applications
+must adapt to the new cdev security model which requires using
+VFIO_DEVICE_BIND_IOMMUFD to claim DMA ownership before starting to
+actually use the device.  Once BIND succeeds then a VFIO device can
+be fully accessed by the user.
+
+VFIO device cdev doesn't rely on VFIO group/container/iommu drivers.
+Hence those modules can be fully compiled out in an environment
+where no legacy VFIO application exists.
+
+So far SPAPR does not support IOMMUFD yet.  So it cannot support device
+cdev either.
+
+vfio device cdev access is still bound by IOMMU group semantics, ie. there
+can be only one DMA owner for the group.  Devices belonging to the same
+group can not be bound to multiple iommufd_ctx or shared between native
+kernel and vfio bus driver or other driver supporting the driver_managed_dma
+flag.  A violation of this ownership requirement will fail at the
+VFIO_DEVICE_BIND_IOMMUFD ioctl, which gates full device access.
+
+Device cdev Example
+---
+
+Assume user wants to access PCI device :6a:01.0::
+
+   $ ls /sys/bus/pci/devices/:6a:01.0/vfio-dev/
+   vfio0
+
+This device is therefore represented as vfio0.  The user can verify
+its existence::
+
+   $ ls -l /dev/vfio/devices/vfio0
+   crw--- 1 root root 511, 0 Feb 16 01:22 /dev/vfio/devices/vfio0
+   $ cat /sys/bus/pci/devices/:6a:01.0/vfio-dev/vfio0/dev
+   511:0
+   $ ls -l /dev/char/511\:0
+   lrwxrwxrwx 1 root root 21 Feb 16 01:22 /dev/char/511:0 -> 
../vfio/devices/vfio0
+
+Then provide the user with access to the device if unprivileged
+operation is desired::
+
+   $ chown user:user /dev/vfio/devices/vfio0
+
+Finally the user could get cdev fd by::
+
+   cdev_fd = open("/dev/vfio/devices/vfio0", O_RDWR);
+
+An opened cdev_fd doesn't give the user any permission of accessing
+the device except binding the cdev_fd to an iommufd.  After that point
+then the device is fully accessible including attaching it to an
+IOMMUFD IOAS/HWPT to enable userspace DMA::
+
+   struct vfio_device_bind_iommufd bind = {
+   .argsz = sizeof(bind),
+   .flags = 0,
+   };
+   struct iommu_ioas_alloc alloc_data  = {
+   .size = sizeof(alloc_data),
+   .flags = 0,
+   };
+   struct vfio_device_attach_iommufd_pt attach_data = {
+   .argsz = sizeof(attach_data),
+   

[Intel-gfx] [PATCH v15 25/26] vfio: Compile vfio_group infrastructure optionally

2023-07-18 Thread Yi Liu
vfio_group is not needed for vfio device cdev, so with vfio device cdev
introduced, the vfio_group infrastructures can be compiled out if only
cdev is needed.

Reviewed-by: Jason Gunthorpe 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Terrence Xu 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/iommu/iommufd/Kconfig |  4 +-
 drivers/vfio/Kconfig  | 15 ++
 drivers/vfio/Makefile |  2 +-
 drivers/vfio/vfio.h   | 89 ---
 include/linux/vfio.h  | 25 --
 5 files changed, 123 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/iommufd/Kconfig b/drivers/iommu/iommufd/Kconfig
index ada693ea51a7..99d4b075df49 100644
--- a/drivers/iommu/iommufd/Kconfig
+++ b/drivers/iommu/iommufd/Kconfig
@@ -14,8 +14,8 @@ config IOMMUFD
 if IOMMUFD
 config IOMMUFD_VFIO_CONTAINER
bool "IOMMUFD provides the VFIO container /dev/vfio/vfio"
-   depends on VFIO && !VFIO_CONTAINER
-   default VFIO && !VFIO_CONTAINER
+   depends on VFIO_GROUP && !VFIO_CONTAINER
+   default VFIO_GROUP && !VFIO_CONTAINER
help
  IOMMUFD will provide /dev/vfio/vfio instead of VFIO. This relies on
  IOMMUFD providing compatibility emulation to give the same ioctls.
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 26f18d92eb97..6bda6dbb4878 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -4,6 +4,8 @@ menuconfig VFIO
select IOMMU_API
depends on IOMMUFD || !IOMMUFD
select INTERVAL_TREE
+   select VFIO_GROUP if SPAPR_TCE_IOMMU || IOMMUFD=n
+   select VFIO_DEVICE_CDEV if !VFIO_GROUP
select VFIO_CONTAINER if IOMMUFD=n
help
  VFIO provides a framework for secure userspace device drivers.
@@ -15,6 +17,7 @@ if VFIO
 config VFIO_DEVICE_CDEV
bool "Support for the VFIO cdev /dev/vfio/devices/vfioX"
depends on IOMMUFD && !SPAPR_TCE_IOMMU
+   default !VFIO_GROUP
help
  The VFIO device cdev is another way for userspace to get device
  access. Userspace gets device fd by opening device cdev under
@@ -24,9 +27,20 @@ config VFIO_DEVICE_CDEV
 
  If you don't know what to do here, say N.
 
+config VFIO_GROUP
+   bool "Support for the VFIO group /dev/vfio/$group_id"
+   default y
+   help
+  VFIO group support provides the traditional model for accessing
+  devices through VFIO and is used by the majority of userspace
+  applications and drivers making use of VFIO.
+
+  If you don't know what to do here, say Y.
+
 config VFIO_CONTAINER
bool "Support for the VFIO container /dev/vfio/vfio"
select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
+   depends on VFIO_GROUP
default y
help
  The VFIO container is the classic interface to VFIO for establishing
@@ -48,6 +62,7 @@ endif
 
 config VFIO_NOIOMMU
bool "VFIO No-IOMMU support"
+   depends on VFIO_GROUP
help
  VFIO is built on the ability to isolate devices using the IOMMU.
  Only with an IOMMU can userspace access to DMA capable devices be
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 87ccb16fdd77..c82ea032d352 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -2,9 +2,9 @@
 obj-$(CONFIG_VFIO) += vfio.o
 
 vfio-y += vfio_main.o \
- group.o \
  iova_bitmap.o
 vfio-$(CONFIG_VFIO_DEVICE_CDEV) += device_cdev.o
+vfio-$(CONFIG_VFIO_GROUP) += group.o
 vfio-$(CONFIG_IOMMUFD) += iommufd.o
 vfio-$(CONFIG_VFIO_CONTAINER) += container.o
 vfio-$(CONFIG_VFIO_VIRQFD) += virqfd.o
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 8353774a5d07..307e3f29b527 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -36,6 +36,12 @@ vfio_allocate_device_file(struct vfio_device *device);
 
 extern const struct file_operations vfio_device_fops;
 
+#ifdef CONFIG_VFIO_NOIOMMU
+extern bool vfio_noiommu __read_mostly;
+#else
+enum { vfio_noiommu = false };
+#endif
+
 enum vfio_group_type {
/*
 * Physical device with IOMMU backing.
@@ -60,6 +66,7 @@ enum vfio_group_type {
VFIO_NO_IOMMU,
 };
 
+#if IS_ENABLED(CONFIG_VFIO_GROUP)
 struct vfio_group {
struct device   dev;
struct cdev cdev;
@@ -111,6 +118,82 @@ static inline bool vfio_device_is_noiommu(struct 
vfio_device *vdev)
return IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
   vdev->group->type == VFIO_NO_IOMMU;
 }
+#else
+struct vfio_group;
+
+static inline int vfio_device_block_group(struct vfio_device *device)
+{
+   return 0;
+}
+
+static inline void vfio_device_unblock_group(struct vfio_device *device)
+{
+}
+
+static inline int vfio_device_set_group(struct vfio_device *device,
+   enum vfio_group_type type)
+{
+   return 0;
+}
+

[Intel-gfx] [PATCH v15 22/26] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

2023-07-18 Thread Yi Liu
This adds ioctl for userspace to bind device cdev fd to iommufd.

VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain DMA
  control provided by the iommufd. open_device
  op is called after bind_iommufd op.

Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Terrence Xu 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/device_cdev.c | 107 +
 drivers/vfio/vfio.h|  13 +
 drivers/vfio/vfio_main.c   |   5 ++
 include/linux/vfio.h   |   5 +-
 include/uapi/linux/vfio.h  |  27 ++
 5 files changed, 155 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
index bf1032d00107..f40784dd5561 100644
--- a/drivers/vfio/device_cdev.c
+++ b/drivers/vfio/device_cdev.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2023 Intel Corporation.
  */
 #include 
+#include 
 
 #include "vfio.h"
 
@@ -45,6 +46,112 @@ int vfio_device_fops_cdev_open(struct inode *inode, struct 
file *filep)
return ret;
 }
 
+static void vfio_df_get_kvm_safe(struct vfio_device_file *df)
+{
+   spin_lock(>kvm_ref_lock);
+   vfio_device_get_kvm_safe(df->device, df->kvm);
+   spin_unlock(>kvm_ref_lock);
+}
+
+long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df,
+   struct vfio_device_bind_iommufd __user *arg)
+{
+   struct vfio_device *device = df->device;
+   struct vfio_device_bind_iommufd bind;
+   unsigned long minsz;
+   int ret;
+
+   static_assert(__same_type(arg->out_devid, df->devid));
+
+   minsz = offsetofend(struct vfio_device_bind_iommufd, out_devid);
+
+   if (copy_from_user(, arg, minsz))
+   return -EFAULT;
+
+   if (bind.argsz < minsz || bind.flags || bind.iommufd < 0)
+   return -EINVAL;
+
+   /* BIND_IOMMUFD only allowed for cdev fds */
+   if (df->group)
+   return -EINVAL;
+
+   ret = vfio_device_block_group(device);
+   if (ret)
+   return ret;
+
+   mutex_lock(>dev_set->lock);
+   /* one device cannot be bound twice */
+   if (df->access_granted) {
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
+   df->iommufd = iommufd_ctx_from_fd(bind.iommufd);
+   if (IS_ERR(df->iommufd)) {
+   ret = PTR_ERR(df->iommufd);
+   df->iommufd = NULL;
+   goto out_unlock;
+   }
+
+   /*
+* Before the device open, get the KVM pointer currently
+* associated with the device file (if there is) and obtain
+* a reference.  This reference is held until device closed.
+* Save the pointer in the device for use by drivers.
+*/
+   vfio_df_get_kvm_safe(df);
+
+   ret = vfio_df_open(df);
+   if (ret)
+   goto out_put_kvm;
+
+   ret = copy_to_user(>out_devid, >devid,
+  sizeof(df->devid)) ? -EFAULT : 0;
+   if (ret)
+   goto out_close_device;
+
+   device->cdev_opened = true;
+   /*
+* Paired with smp_load_acquire() in vfio_device_fops::ioctl/
+* read/write/mmap
+*/
+   smp_store_release(>access_granted, true);
+   mutex_unlock(>dev_set->lock);
+   return 0;
+
+out_close_device:
+   vfio_df_close(df);
+out_put_kvm:
+   vfio_device_put_kvm(device);
+   iommufd_ctx_put(df->iommufd);
+   df->iommufd = NULL;
+out_unlock:
+   mutex_unlock(>dev_set->lock);
+   vfio_device_unblock_group(device);
+   return ret;
+}
+
+void vfio_df_unbind_iommufd(struct vfio_device_file *df)
+{
+   struct vfio_device *device = df->device;
+
+   /*
+* In the time of close, there is no contention with another one
+* changing this flag.  So read df->access_granted without lock
+* and no smp_load_acquire() is ok.
+*/
+   if (!df->access_granted)
+   return;
+
+   mutex_lock(>dev_set->lock);
+   vfio_df_close(df);
+   vfio_device_put_kvm(device);
+   iommufd_ctx_put(df->iommufd);
+   device->cdev_opened = false;
+   mutex_unlock(>dev_set->lock);
+   vfio_device_unblock_group(device);
+}
+
 static char *vfio_device_devnode(const struct device *dev, umode_t *mode)
 {
return kasprintf(GFP_KERNEL, "vfio/devices/%s", dev_name(dev));
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index c2aa65382592..b6d4ba1ef2b8 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -287,6 +287,9 @@ static inline void vfio_device_del(struct vfio_device 
*device)
 }
 
 int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep);
+long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df,
+   struct vfio_device_bind_iommufd __user *arg);
+void vfio_df_unbind_iommufd(struct vfio_device_file *df);
 int 

[Intel-gfx] [PATCH v15 21/26] vfio: Avoid repeated user pointer cast in vfio_device_fops_unl_ioctl()

2023-07-18 Thread Yi Liu
This adds a local variable to store the user pointer cast result from arg.
It avoids the repeated casts in the code when more ioctls are added.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: Yi Liu 
---
 drivers/vfio/vfio_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 5f7c3151d8c0..a2744cb64c6d 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -1146,6 +1146,7 @@ static long vfio_device_fops_unl_ioctl(struct file *filep,
 {
struct vfio_device_file *df = filep->private_data;
struct vfio_device *device = df->device;
+   void __user *uptr = (void __user *)arg;
int ret;
 
/* Paired with smp_store_release() following vfio_df_open() */
@@ -1158,7 +1159,7 @@ static long vfio_device_fops_unl_ioctl(struct file *filep,
 
switch (cmd) {
case VFIO_DEVICE_FEATURE:
-   ret = vfio_ioctl_device_feature(device, (void __user *)arg);
+   ret = vfio_ioctl_device_feature(device, uptr);
break;
 
default:
-- 
2.34.1



[Intel-gfx] [PATCH v15 23/26] vfio: Add VFIO_DEVICE_[AT|DE]TACH_IOMMUFD_PT

2023-07-18 Thread Yi Liu
This adds ioctl for userspace to attach device cdev fd to and detach
from IOAS/hw_pagetable managed by iommufd.

VFIO_DEVICE_ATTACH_IOMMUFD_PT: attach vfio device to IOAS or hw_pagetable
   managed by iommufd. Attach can be undo
   by VFIO_DEVICE_DETACH_IOMMUFD_PT or device
   fd close.
VFIO_DEVICE_DETACH_IOMMUFD_PT: detach vfio device from the current attached
   IOAS or hw_pagetable managed by iommufd.

Reviewed-by: Jason Gunthorpe 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Terrence Xu 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/device_cdev.c | 58 ++
 drivers/vfio/vfio.h|  5 
 drivers/vfio/vfio_main.c   | 15 +-
 include/uapi/linux/vfio.h  | 44 +
 4 files changed, 121 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
index f40784dd5561..e75da0a70d1f 100644
--- a/drivers/vfio/device_cdev.c
+++ b/drivers/vfio/device_cdev.c
@@ -152,6 +152,64 @@ void vfio_df_unbind_iommufd(struct vfio_device_file *df)
vfio_device_unblock_group(device);
 }
 
+int vfio_df_ioctl_attach_pt(struct vfio_device_file *df,
+   struct vfio_device_attach_iommufd_pt __user *arg)
+{
+   struct vfio_device *device = df->device;
+   struct vfio_device_attach_iommufd_pt attach;
+   unsigned long minsz;
+   int ret;
+
+   minsz = offsetofend(struct vfio_device_attach_iommufd_pt, pt_id);
+
+   if (copy_from_user(, arg, minsz))
+   return -EFAULT;
+
+   if (attach.argsz < minsz || attach.flags)
+   return -EINVAL;
+
+   mutex_lock(>dev_set->lock);
+   ret = device->ops->attach_ioas(device, _id);
+   if (ret)
+   goto out_unlock;
+
+   if (copy_to_user(>pt_id, _id, sizeof(attach.pt_id))) {
+   ret = -EFAULT;
+   goto out_detach;
+   }
+   mutex_unlock(>dev_set->lock);
+
+   return 0;
+
+out_detach:
+   device->ops->detach_ioas(device);
+out_unlock:
+   mutex_unlock(>dev_set->lock);
+   return ret;
+}
+
+int vfio_df_ioctl_detach_pt(struct vfio_device_file *df,
+   struct vfio_device_detach_iommufd_pt __user *arg)
+{
+   struct vfio_device *device = df->device;
+   struct vfio_device_detach_iommufd_pt detach;
+   unsigned long minsz;
+
+   minsz = offsetofend(struct vfio_device_detach_iommufd_pt, flags);
+
+   if (copy_from_user(, arg, minsz))
+   return -EFAULT;
+
+   if (detach.argsz < minsz || detach.flags)
+   return -EINVAL;
+
+   mutex_lock(>dev_set->lock);
+   device->ops->detach_ioas(device);
+   mutex_unlock(>dev_set->lock);
+
+   return 0;
+}
+
 static char *vfio_device_devnode(const struct device *dev, umode_t *mode)
 {
return kasprintf(GFP_KERNEL, "vfio/devices/%s", dev_name(dev));
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index b6d4ba1ef2b8..8353774a5d07 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -266,6 +266,11 @@ vfio_iommufd_compat_attach_ioas(struct vfio_device *device,
 }
 #endif
 
+int vfio_df_ioctl_attach_pt(struct vfio_device_file *df,
+   struct vfio_device_attach_iommufd_pt __user *arg);
+int vfio_df_ioctl_detach_pt(struct vfio_device_file *df,
+   struct vfio_device_detach_iommufd_pt __user *arg);
+
 #if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)
 void vfio_init_device_cdev(struct vfio_device *device);
 
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 9fdf93ff17cf..ba1d84afe081 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -1162,6 +1162,19 @@ static long vfio_device_fops_unl_ioctl(struct file 
*filep,
if (ret)
return ret;
 
+   /* cdev only ioctls */
+   if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV) && !df->group) {
+   switch (cmd) {
+   case VFIO_DEVICE_ATTACH_IOMMUFD_PT:
+   ret = vfio_df_ioctl_attach_pt(df, uptr);
+   goto out;
+
+   case VFIO_DEVICE_DETACH_IOMMUFD_PT:
+   ret = vfio_df_ioctl_detach_pt(df, uptr);
+   goto out;
+   }
+   }
+
switch (cmd) {
case VFIO_DEVICE_FEATURE:
ret = vfio_ioctl_device_feature(device, uptr);
@@ -1174,7 +1187,7 @@ static long vfio_device_fops_unl_ioctl(struct file *filep,
ret = device->ops->ioctl(device, cmd, arg);
break;
}
-
+out:
vfio_device_pm_runtime_put(device);
return ret;
 }
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 098946b23e86..fa06e3eb4955 100644
--- 

[Intel-gfx] [PATCH v15 24/26] vfio: Move the IOMMU_CAP_CACHE_COHERENCY check in __vfio_register_dev()

2023-07-18 Thread Yi Liu
The IOMMU_CAP_CACHE_COHERENCY check only applies to the physical devices
that are IOMMU-backed. But it is now in the group code. If want to compile
vfio_group infrastructure out, this check needs to be moved out of the group
code.

Another reason for this change is to fail the device registration for the
physical devices that do not have IOMMU if the group code is not compiled
as the cdev interface does not support such devices.

Suggested-by: Jason Gunthorpe 
Reviewed-by: Jason Gunthorpe 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c | 10 --
 drivers/vfio/vfio_main.c | 11 +++
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 5c17ad812313..610a429c6191 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -682,16 +682,6 @@ static struct vfio_group *vfio_group_find_or_alloc(struct 
device *dev)
if (!iommu_group)
return ERR_PTR(-EINVAL);
 
-   /*
-* VFIO always sets IOMMU_CACHE because we offer no way for userspace to
-* restore cache coherency. It has to be checked here because it is only
-* valid for cases where we are using iommu groups.
-*/
-   if (!device_iommu_capable(dev, IOMMU_CAP_CACHE_COHERENCY)) {
-   iommu_group_put(iommu_group);
-   return ERR_PTR(-EINVAL);
-   }
-
mutex_lock(_lock);
group = vfio_group_find_from_iommu(iommu_group);
if (group) {
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index ba1d84afe081..902f06e52c48 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -292,6 +292,17 @@ static int __vfio_register_dev(struct vfio_device *device,
if (ret)
return ret;
 
+   /*
+* VFIO always sets IOMMU_CACHE because we offer no way for userspace to
+* restore cache coherency. It has to be checked here because it is only
+* valid for cases where we are using iommu groups.
+*/
+   if (type == VFIO_IOMMU && !vfio_device_is_noiommu(device) &&
+   !device_iommu_capable(device->dev, IOMMU_CAP_CACHE_COHERENCY)) {
+   ret = -EINVAL;
+   goto err_out;
+   }
+
ret = vfio_device_add(device);
if (ret)
goto err_out;
-- 
2.34.1



[Intel-gfx] [PATCH v15 17/26] vfio: Move device_del() before waiting for the last vfio_device registration refcount

2023-07-18 Thread Yi Liu
device_del() destroys the vfio-dev/vfioX under the sysfs for vfio_device.
There is no reason to keep it while the device is going to be unregistered.

This movement is also a preparation for adding vfio_device cdev. Kernel
should remove the cdev node of the vfio_device to avoid new registration
refcount increment while the device is going to be unregistered.

Reviewed-by: Jason Gunthorpe 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/vfio_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 6d45caa1f9a0..294bb5ecfc1c 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -338,6 +338,9 @@ void vfio_unregister_group_dev(struct vfio_device *device)
 */
vfio_device_group_unregister(device);
 
+   /* Balances device_add in register path */
+   device_del(>device);
+
vfio_device_put_registration(device);
rc = try_wait_for_completion(>comp);
while (rc <= 0) {
@@ -361,9 +364,6 @@ void vfio_unregister_group_dev(struct vfio_device *device)
}
}
 
-   /* Balances device_add in register path */
-   device_del(>device);
-
/* Balances vfio_device_set_group in register path */
vfio_device_remove_group(device);
 }
-- 
2.34.1



[Intel-gfx] [PATCH v15 20/26] iommufd: Add iommufd_ctx_from_fd()

2023-07-18 Thread Yi Liu
It's common to get a reference to the iommufd context from a given file
descriptor. So adds an API for it. Existing users of this API are compiled
only when IOMMUFD is enabled, so no need to have a stub for the IOMMUFD
disabled case.

Signed-off-by: Yi Liu 
---
 drivers/iommu/iommufd/main.c | 24 
 include/linux/iommufd.h  |  1 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/iommu/iommufd/main.c b/drivers/iommu/iommufd/main.c
index 32ce7befc8dd..4bbb20dff430 100644
--- a/drivers/iommu/iommufd/main.c
+++ b/drivers/iommu/iommufd/main.c
@@ -377,6 +377,30 @@ struct iommufd_ctx *iommufd_ctx_from_file(struct file 
*file)
 }
 EXPORT_SYMBOL_NS_GPL(iommufd_ctx_from_file, IOMMUFD);
 
+/**
+ * iommufd_ctx_from_fd - Acquires a reference to the iommufd context
+ * @fd: File descriptor to obtain the reference from
+ *
+ * Returns a pointer to the iommufd_ctx, otherwise ERR_PTR. On success
+ * the caller is responsible to call iommufd_ctx_put().
+ */
+struct iommufd_ctx *iommufd_ctx_from_fd(int fd)
+{
+   struct file *file;
+
+   file = fget(fd);
+   if (!file)
+   return ERR_PTR(-EBADF);
+
+   if (file->f_op != _fops) {
+   fput(file);
+   return ERR_PTR(-EBADFD);
+   }
+   /* fget is the same as iommufd_ctx_get() */
+   return file->private_data;
+}
+EXPORT_SYMBOL_NS_GPL(iommufd_ctx_from_fd, IOMMUFD);
+
 /**
  * iommufd_ctx_put - Put back a reference
  * @ictx: Context to put back
diff --git a/include/linux/iommufd.h b/include/linux/iommufd.h
index 3a3216cb9482..9657c58813dc 100644
--- a/include/linux/iommufd.h
+++ b/include/linux/iommufd.h
@@ -54,6 +54,7 @@ void iommufd_ctx_get(struct iommufd_ctx *ictx);
 
 #if IS_ENABLED(CONFIG_IOMMUFD)
 struct iommufd_ctx *iommufd_ctx_from_file(struct file *file);
+struct iommufd_ctx *iommufd_ctx_from_fd(int fd);
 void iommufd_ctx_put(struct iommufd_ctx *ictx);
 bool iommufd_ctx_has_group(struct iommufd_ctx *ictx, struct iommu_group 
*group);
 
-- 
2.34.1



[Intel-gfx] [PATCH v15 15/26] vfio-iommufd: Add detach_ioas support for emulated VFIO devices

2023-07-18 Thread Yi Liu
This prepares for adding DETACH ioctl for emulated VFIO devices.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c  |  1 +
 drivers/s390/cio/vfio_ccw_ops.c   |  1 +
 drivers/s390/crypto/vfio_ap_ops.c |  1 +
 drivers/vfio/iommufd.c| 13 +
 include/linux/vfio.h  |  3 +++
 samples/vfio-mdev/mbochs.c|  1 +
 samples/vfio-mdev/mdpy.c  |  1 +
 samples/vfio-mdev/mtty.c  |  1 +
 8 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index de675d799c7d..9cd9e9da60dd 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1474,6 +1474,7 @@ static const struct vfio_device_ops intel_vgpu_dev_ops = {
.bind_iommufd   = vfio_iommufd_emulated_bind,
.unbind_iommufd = vfio_iommufd_emulated_unbind,
.attach_ioas= vfio_iommufd_emulated_attach_ioas,
+   .detach_ioas= vfio_iommufd_emulated_detach_ioas,
 };
 
 static int intel_vgpu_probe(struct mdev_device *mdev)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 5b53b94f13c7..cba4971618ff 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -632,6 +632,7 @@ static const struct vfio_device_ops vfio_ccw_dev_ops = {
.bind_iommufd = vfio_iommufd_emulated_bind,
.unbind_iommufd = vfio_iommufd_emulated_unbind,
.attach_ioas = vfio_iommufd_emulated_attach_ioas,
+   .detach_ioas = vfio_iommufd_emulated_detach_ioas,
 };
 
 struct mdev_driver vfio_ccw_mdev_driver = {
diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
b/drivers/s390/crypto/vfio_ap_ops.c
index b441745b0418..2d3c3a79b687 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1975,6 +1975,7 @@ static const struct vfio_device_ops 
vfio_ap_matrix_dev_ops = {
.bind_iommufd = vfio_iommufd_emulated_bind,
.unbind_iommufd = vfio_iommufd_emulated_unbind,
.attach_ioas = vfio_iommufd_emulated_attach_ioas,
+   .detach_ioas = vfio_iommufd_emulated_detach_ioas,
.request = vfio_ap_mdev_request
 };
 
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 86df5415759a..4d84904fd927 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -231,3 +231,16 @@ int vfio_iommufd_emulated_attach_ioas(struct vfio_device 
*vdev, u32 *pt_id)
return 0;
 }
 EXPORT_SYMBOL_GPL(vfio_iommufd_emulated_attach_ioas);
+
+void vfio_iommufd_emulated_detach_ioas(struct vfio_device *vdev)
+{
+   lockdep_assert_held(>dev_set->lock);
+
+   if (WARN_ON(!vdev->iommufd_access) ||
+   !vdev->iommufd_attached)
+   return;
+
+   iommufd_access_detach(vdev->iommufd_access);
+   vdev->iommufd_attached = false;
+}
+EXPORT_SYMBOL_GPL(vfio_iommufd_emulated_detach_ioas);
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index f2f02273ece1..24091a7c7bdb 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -128,6 +128,7 @@ int vfio_iommufd_emulated_bind(struct vfio_device *vdev,
   struct iommufd_ctx *ictx, u32 *out_device_id);
 void vfio_iommufd_emulated_unbind(struct vfio_device *vdev);
 int vfio_iommufd_emulated_attach_ioas(struct vfio_device *vdev, u32 *pt_id);
+void vfio_iommufd_emulated_detach_ioas(struct vfio_device *vdev);
 #else
 static inline struct iommufd_ctx *
 vfio_iommufd_device_ictx(struct vfio_device *vdev)
@@ -157,6 +158,8 @@ vfio_iommufd_get_dev_id(struct vfio_device *vdev, struct 
iommufd_ctx *ictx)
((void (*)(struct vfio_device *vdev)) NULL)
 #define vfio_iommufd_emulated_attach_ioas \
((int (*)(struct vfio_device *vdev, u32 *pt_id)) NULL)
+#define vfio_iommufd_emulated_detach_ioas \
+   ((void (*)(struct vfio_device *vdev)) NULL)
 #endif
 
 static inline bool vfio_device_cdev_opened(struct vfio_device *device)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index c6c6b5d26670..3764d1911b51 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -1377,6 +1377,7 @@ static const struct vfio_device_ops mbochs_dev_ops = {
.bind_iommufd   = vfio_iommufd_emulated_bind,
.unbind_iommufd = vfio_iommufd_emulated_unbind,
.attach_ioas= vfio_iommufd_emulated_attach_ioas,
+   .detach_ioas= vfio_iommufd_emulated_detach_ioas,
 };
 
 static struct mdev_driver mbochs_driver = {
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index a62ea11e20ec..064e1c0a7aa8 100644
--- a/samples/vfio-mdev/mdpy.c
+++ b/samples/vfio-mdev/mdpy.c
@@ -666,6 +666,7 @@ static const struct vfio_device_ops mdpy_dev_ops = {
.bind_iommufd   = vfio_iommufd_emulated_bind,
.unbind_iommufd = 

[Intel-gfx] [PATCH v15 19/26] vfio: Test kvm pointer in _vfio_device_get_kvm_safe()

2023-07-18 Thread Yi Liu
This saves some lines when adding the kvm get logic for the vfio_device
cdev path.

This also renames _vfio_device_get_kvm_safe() to be vfio_device_get_kvm_safe().

Suggested-by: Jason Gunthorpe 
Reviewed-by: Jason Gunthorpe 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c | 7 +--
 drivers/vfio/vfio.h  | 6 +++---
 drivers/vfio/vfio_main.c | 5 -
 3 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 41a09a2df690..5c17ad812313 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -160,12 +160,7 @@ static int vfio_group_ioctl_set_container(struct 
vfio_group *group,
 static void vfio_device_group_get_kvm_safe(struct vfio_device *device)
 {
spin_lock(>group->kvm_ref_lock);
-   if (!device->group->kvm)
-   goto unlock;
-
-   _vfio_device_get_kvm_safe(device, device->group->kvm);
-
-unlock:
+   vfio_device_get_kvm_safe(device, device->group->kvm);
spin_unlock(>group->kvm_ref_lock);
 }
 
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index fb8f2fac3d23..c2aa65382592 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -340,11 +340,11 @@ enum { vfio_noiommu = false };
 #endif
 
 #ifdef CONFIG_HAVE_KVM
-void _vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm);
+void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm);
 void vfio_device_put_kvm(struct vfio_device *device);
 #else
-static inline void _vfio_device_get_kvm_safe(struct vfio_device *device,
-struct kvm *kvm)
+static inline void vfio_device_get_kvm_safe(struct vfio_device *device,
+   struct kvm *kvm)
 {
 }
 
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 8a9ebcc6980b..5f7c3151d8c0 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -373,7 +373,7 @@ void vfio_unregister_group_dev(struct vfio_device *device)
 EXPORT_SYMBOL_GPL(vfio_unregister_group_dev);
 
 #ifdef CONFIG_HAVE_KVM
-void _vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
+void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
 {
void (*pfn)(struct kvm *kvm);
bool (*fn)(struct kvm *kvm);
@@ -381,6 +381,9 @@ void _vfio_device_get_kvm_safe(struct vfio_device *device, 
struct kvm *kvm)
 
lockdep_assert_held(>dev_set->lock);
 
+   if (!kvm)
+   return;
+
pfn = symbol_get(kvm_put_kvm);
if (WARN_ON(!pfn))
return;
-- 
2.34.1



[Intel-gfx] [PATCH v15 09/26] vfio: Make vfio_df_open() single open for device cdev path

2023-07-18 Thread Yi Liu
VFIO group has historically allowed multi-open of the device FD. This
was made secure because the "open" was executed via an ioctl to the
group FD which is itself only single open.

However, no known use of multiple device FDs today. It is kind of a
strange thing to do because new device FDs can naturally be created
via dup().

When we implement the new device uAPI (only used in cdev path) there is
no natural way to allow the device itself from being multi-opened in a
secure manner. Without the group FD we cannot prove the security context
of the opener.

Thus, when moving to the new uAPI we block the ability of opening
a device multiple times. Given old group path still allows it we store
a vfio_group pointer in struct vfio_device_file to differentiate.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Eric Auger 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c | 2 ++
 drivers/vfio/vfio.h  | 1 +
 drivers/vfio/vfio_main.c | 7 +++
 3 files changed, 10 insertions(+)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 2751d61689c4..4e6277191eb4 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -245,6 +245,8 @@ static struct file *vfio_device_open_file(struct 
vfio_device *device)
goto err_out;
}
 
+   df->group = device->group;
+
ret = vfio_df_group_open(df);
if (ret)
goto err_free;
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index ae7dd2ca14b9..85484a971a3e 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -18,6 +18,7 @@ struct vfio_container;
 
 struct vfio_device_file {
struct vfio_device *device;
+   struct vfio_group *group;
 
u8 access_granted;
spinlock_t kvm_ref_lock; /* protect kvm field */
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index c37fc14599d0..be5e4ddd5901 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -492,6 +492,13 @@ int vfio_df_open(struct vfio_device_file *df)
 
lockdep_assert_held(>dev_set->lock);
 
+   /*
+* Only the group path allows the device to be opened multiple
+* times.  The device cdev path doesn't have a secure way for it.
+*/
+   if (device->open_count != 0 && !df->group)
+   return -EINVAL;
+
device->open_count++;
if (device->open_count == 1) {
ret = vfio_df_device_first_open(df);
-- 
2.34.1



[Intel-gfx] [PATCH v15 16/26] vfio: Move vfio_device_group_unregister() to be the first operation in unregister

2023-07-18 Thread Yi Liu
This avoids endless vfio_device refcount increment by userspace, which
would keep blocking the vfio_unregister_group_dev().

Reviewed-by: Jason Gunthorpe 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Terrence Xu 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/vfio_main.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index c71c0d1a079f..6d45caa1f9a0 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -332,6 +332,12 @@ void vfio_unregister_group_dev(struct vfio_device *device)
bool interrupted = false;
long rc;
 
+   /*
+* Prevent new device opened by userspace via the
+* VFIO_GROUP_GET_DEVICE_FD in the group path.
+*/
+   vfio_device_group_unregister(device);
+
vfio_device_put_registration(device);
rc = try_wait_for_completion(>comp);
while (rc <= 0) {
@@ -355,8 +361,6 @@ void vfio_unregister_group_dev(struct vfio_device *device)
}
}
 
-   vfio_device_group_unregister(device);
-
/* Balances device_add in register path */
device_del(>device);
 
-- 
2.34.1



[Intel-gfx] [PATCH v15 13/26] vfio-iommufd: Add detach_ioas support for physical VFIO devices

2023-07-18 Thread Yi Liu
This prepares for adding DETACH ioctl for physical VFIO devices.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 Documentation/driver-api/vfio.rst |  8 +---
 drivers/vfio/fsl-mc/vfio_fsl_mc.c |  1 +
 drivers/vfio/iommufd.c| 20 +++
 .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c|  2 ++
 drivers/vfio/pci/mlx5/main.c  |  1 +
 drivers/vfio/pci/vfio_pci.c   |  1 +
 drivers/vfio/platform/vfio_amba.c |  1 +
 drivers/vfio/platform/vfio_platform.c |  1 +
 drivers/vfio/vfio_main.c  |  3 ++-
 include/linux/vfio.h  |  8 +++-
 10 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/Documentation/driver-api/vfio.rst 
b/Documentation/driver-api/vfio.rst
index 68abc089d6dd..363e12c90b87 100644
--- a/Documentation/driver-api/vfio.rst
+++ b/Documentation/driver-api/vfio.rst
@@ -279,6 +279,7 @@ similar to a file operations structure::
struct iommufd_ctx *ictx, u32 
*out_device_id);
void(*unbind_iommufd)(struct vfio_device *vdev);
int (*attach_ioas)(struct vfio_device *vdev, u32 *pt_id);
+   void(*detach_ioas)(struct vfio_device *vdev);
int (*open_device)(struct vfio_device *vdev);
void(*close_device)(struct vfio_device *vdev);
ssize_t (*read)(struct vfio_device *vdev, char __user *buf,
@@ -315,9 +316,10 @@ container_of().
- The [un]bind_iommufd callbacks are issued when the device is bound to
  and unbound from iommufd.
 
-   - The attach_ioas callback is issued when the device is attached to an
- IOAS managed by the bound iommufd. The attached IOAS is automatically
- detached when the device is unbound from iommufd.
+   - The [de]attach_ioas callback is issued when the device is attached to
+ and detached from an IOAS managed by the bound iommufd. However, the
+ attached IOAS can also be automatically detached when the device is
+ unbound from iommufd.
 
- The read/write/mmap callbacks implement the device region access 
defined
  by the device's own VFIO_DEVICE_GET_REGION_INFO ioctl.
diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c 
b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
index f2140e94d41e..116358a8f1cf 100644
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -593,6 +593,7 @@ static const struct vfio_device_ops vfio_fsl_mc_ops = {
.bind_iommufd   = vfio_iommufd_physical_bind,
.unbind_iommufd = vfio_iommufd_physical_unbind,
.attach_ioas= vfio_iommufd_physical_attach_ioas,
+   .detach_ioas= vfio_iommufd_physical_detach_ioas,
 };
 
 static struct fsl_mc_driver vfio_fsl_mc_driver = {
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 4fc674c01a05..86df5415759a 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -140,6 +140,14 @@ int vfio_iommufd_physical_attach_ioas(struct vfio_device 
*vdev, u32 *pt_id)
 {
int rc;
 
+   lockdep_assert_held(>dev_set->lock);
+
+   if (WARN_ON(!vdev->iommufd_device))
+   return -EINVAL;
+
+   if (vdev->iommufd_attached)
+   return -EBUSY;
+
rc = iommufd_device_attach(vdev->iommufd_device, pt_id);
if (rc)
return rc;
@@ -148,6 +156,18 @@ int vfio_iommufd_physical_attach_ioas(struct vfio_device 
*vdev, u32 *pt_id)
 }
 EXPORT_SYMBOL_GPL(vfio_iommufd_physical_attach_ioas);
 
+void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
+{
+   lockdep_assert_held(>dev_set->lock);
+
+   if (WARN_ON(!vdev->iommufd_device) || !vdev->iommufd_attached)
+   return;
+
+   iommufd_device_detach(vdev->iommufd_device);
+   vdev->iommufd_attached = false;
+}
+EXPORT_SYMBOL_GPL(vfio_iommufd_physical_detach_ioas);
+
 /*
  * The emulated standard ops mean that vfio_device is going to use the
  * "mdev path" and will call vfio_pin_pages()/vfio_dma_rw(). Drivers using this
diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c 
b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
index a117eaf21c14..b2f9778c8366 100644
--- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
+++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
@@ -1373,6 +1373,7 @@ static const struct vfio_device_ops 
hisi_acc_vfio_pci_migrn_ops = {
.bind_iommufd = vfio_iommufd_physical_bind,
.unbind_iommufd = vfio_iommufd_physical_unbind,
.attach_ioas = vfio_iommufd_physical_attach_ioas,
+   .detach_ioas = vfio_iommufd_physical_detach_ioas,
 };
 
 static const struct vfio_device_ops hisi_acc_vfio_pci_ops = {
@@ -1391,6 +1392,7 @@ 

[Intel-gfx] [PATCH v15 08/26] vfio: Add cdev_device_open_cnt to vfio_group

2023-07-18 Thread Yi Liu
This is for counting the devices that are opened via the cdev path. This
count is increased and decreased by the cdev path. The group path checks
it to achieve exclusion with the cdev path. With this, only one path
(group path or cdev path) will claim DMA ownership. This avoids scenarios
in which devices within the same group may be opened via different paths.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Eric Auger 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c | 33 +
 drivers/vfio/vfio.h  |  3 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 088dd34c8931..2751d61689c4 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -383,6 +383,33 @@ static long vfio_group_fops_unl_ioctl(struct file *filep,
}
 }
 
+int vfio_device_block_group(struct vfio_device *device)
+{
+   struct vfio_group *group = device->group;
+   int ret = 0;
+
+   mutex_lock(>group_lock);
+   if (group->opened_file) {
+   ret = -EBUSY;
+   goto out_unlock;
+   }
+
+   group->cdev_device_open_cnt++;
+
+out_unlock:
+   mutex_unlock(>group_lock);
+   return ret;
+}
+
+void vfio_device_unblock_group(struct vfio_device *device)
+{
+   struct vfio_group *group = device->group;
+
+   mutex_lock(>group_lock);
+   group->cdev_device_open_cnt--;
+   mutex_unlock(>group_lock);
+}
+
 static int vfio_group_fops_open(struct inode *inode, struct file *filep)
 {
struct vfio_group *group =
@@ -405,6 +432,11 @@ static int vfio_group_fops_open(struct inode *inode, 
struct file *filep)
goto out_unlock;
}
 
+   if (group->cdev_device_open_cnt) {
+   ret = -EBUSY;
+   goto out_unlock;
+   }
+
/*
 * Do we need multiple instances of the group open?  Seems not.
 */
@@ -479,6 +511,7 @@ static void vfio_group_release(struct device *dev)
mutex_destroy(>device_lock);
mutex_destroy(>group_lock);
WARN_ON(group->iommu_group);
+   WARN_ON(group->cdev_device_open_cnt);
ida_free(_ida, MINOR(group->dev.devt));
kfree(group);
 }
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 4478a1e77a5e..ae7dd2ca14b9 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -84,8 +84,11 @@ struct vfio_group {
struct blocking_notifier_head   notifier;
struct iommufd_ctx  *iommufd;
spinlock_t  kvm_ref_lock;
+   unsigned intcdev_device_open_cnt;
 };
 
+int vfio_device_block_group(struct vfio_device *device);
+void vfio_device_unblock_group(struct vfio_device *device);
 int vfio_device_set_group(struct vfio_device *device,
  enum vfio_group_type type);
 void vfio_device_remove_group(struct vfio_device *device);
-- 
2.34.1



[Intel-gfx] [PATCH v15 07/26] vfio: Block device access via device fd until device is opened

2023-07-18 Thread Yi Liu
Allow the vfio_device file to be in a state where the device FD is
opened but the device cannot be used by userspace (i.e. its .open_device()
hasn't been called). This inbetween state is not used when the device
FD is spawned from the group FD, however when we create the device FD
directly by opening a cdev it will be opened in the blocked state.

The reason for the inbetween state is that userspace only gets a FD but
doesn't gain access permission until binding the FD to an iommufd. So in
the blocked state, only the bind operation is allowed. Completing bind
will allow user to further access the device.

This is implemented by adding a flag in struct vfio_device_file to mark
the blocked state and using a simple smp_load_acquire() to obtain the
flag value and serialize all the device setup with the thread accessing
this device.

Following this lockless scheme, it can safely handle the device FD
unbound->bound but it cannot handle bound->unbound. To allow this we'd
need to add a lock on all the vfio ioctls which seems costly. So once
device FD is bound, it remains bound until the FD is closed.

Suggested-by: Jason Gunthorpe 
Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Eric Auger 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c | 11 ++-
 drivers/vfio/vfio.h  |  1 +
 drivers/vfio/vfio_main.c | 16 
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index caf53716ddb2..088dd34c8931 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -194,9 +194,18 @@ static int vfio_df_group_open(struct vfio_device_file *df)
df->iommufd = device->group->iommufd;
 
ret = vfio_df_open(df);
-   if (ret)
+   if (ret) {
df->iommufd = NULL;
+   goto out_put_kvm;
+   }
+
+   /*
+* Paired with smp_load_acquire() in vfio_device_fops::ioctl/
+* read/write/mmap and vfio_file_has_device_access()
+*/
+   smp_store_release(>access_granted, true);
 
+out_put_kvm:
if (device->open_count == 0)
vfio_device_put_kvm(device);
 
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 2094f5a4ef04..4478a1e77a5e 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -19,6 +19,7 @@ struct vfio_container;
 struct vfio_device_file {
struct vfio_device *device;
 
+   u8 access_granted;
spinlock_t kvm_ref_lock; /* protect kvm field */
struct kvm *kvm;
struct iommufd_ctx *iommufd; /* protected by struct 
vfio_device_set::lock */
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 825b1eeaebe2..c37fc14599d0 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -1129,6 +1129,10 @@ static long vfio_device_fops_unl_ioctl(struct file 
*filep,
struct vfio_device *device = df->device;
int ret;
 
+   /* Paired with smp_store_release() following vfio_df_open() */
+   if (!smp_load_acquire(>access_granted))
+   return -EINVAL;
+
ret = vfio_device_pm_runtime_get(device);
if (ret)
return ret;
@@ -1156,6 +1160,10 @@ static ssize_t vfio_device_fops_read(struct file *filep, 
char __user *buf,
struct vfio_device_file *df = filep->private_data;
struct vfio_device *device = df->device;
 
+   /* Paired with smp_store_release() following vfio_df_open() */
+   if (!smp_load_acquire(>access_granted))
+   return -EINVAL;
+
if (unlikely(!device->ops->read))
return -EINVAL;
 
@@ -1169,6 +1177,10 @@ static ssize_t vfio_device_fops_write(struct file *filep,
struct vfio_device_file *df = filep->private_data;
struct vfio_device *device = df->device;
 
+   /* Paired with smp_store_release() following vfio_df_open() */
+   if (!smp_load_acquire(>access_granted))
+   return -EINVAL;
+
if (unlikely(!device->ops->write))
return -EINVAL;
 
@@ -1180,6 +1192,10 @@ static int vfio_device_fops_mmap(struct file *filep, 
struct vm_area_struct *vma)
struct vfio_device_file *df = filep->private_data;
struct vfio_device *device = df->device;
 
+   /* Paired with smp_store_release() following vfio_df_open() */
+   if (!smp_load_acquire(>access_granted))
+   return -EINVAL;
+
if (unlikely(!device->ops->mmap))
return -EINVAL;
 
-- 
2.34.1



[Intel-gfx] [PATCH v15 05/26] kvm/vfio: Accept vfio device file from userspace

2023-07-18 Thread Yi Liu
This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*.
Old userspace uses KVM_DEV_VFIO_GROUP* works as well.

Reviewed-by: Jason Gunthorpe 
Reviewed-by: Kevin Tian 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 Documentation/virt/kvm/devices/vfio.rst | 47 -
 include/uapi/linux/kvm.h| 13 +--
 virt/kvm/vfio.c | 12 +++
 3 files changed, 47 insertions(+), 25 deletions(-)

diff --git a/Documentation/virt/kvm/devices/vfio.rst 
b/Documentation/virt/kvm/devices/vfio.rst
index 08b544212638..c549143bb891 100644
--- a/Documentation/virt/kvm/devices/vfio.rst
+++ b/Documentation/virt/kvm/devices/vfio.rst
@@ -9,22 +9,34 @@ Device types supported:
   - KVM_DEV_TYPE_VFIO
 
 Only one VFIO instance may be created per VM.  The created device
-tracks VFIO groups in use by the VM and features of those groups
-important to the correctness and acceleration of the VM.  As groups
-are enabled and disabled for use by the VM, KVM should be updated
-about their presence.  When registered with KVM, a reference to the
-VFIO-group is held by KVM.
+tracks VFIO files (group or device) in use by the VM and features
+of those groups/devices important to the correctness and acceleration
+of the VM.  As groups/devices are enabled and disabled for use by the
+VM, KVM should be updated about their presence.  When registered with
+KVM, a reference to the VFIO file is held by KVM.
 
 Groups:
-  KVM_DEV_VFIO_GROUP
-
-KVM_DEV_VFIO_GROUP attributes:
-  KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
-   kvm_device_attr.addr points to an int32_t file descriptor
-   for the VFIO group.
-  KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
-   kvm_device_attr.addr points to an int32_t file descriptor
-   for the VFIO group.
+  KVM_DEV_VFIO_FILE
+   alias: KVM_DEV_VFIO_GROUP
+
+KVM_DEV_VFIO_FILE attributes:
+  KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device
+   tracking
+
+   kvm_device_attr.addr points to an int32_t file descriptor for the
+   VFIO file.
+
+  KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM
+   device tracking
+
+   kvm_device_attr.addr points to an int32_t file descriptor for the
+   VFIO file.
+
+KVM_DEV_VFIO_GROUP (legacy kvm device group restricted to the handling of VFIO 
group fd):
+  KVM_DEV_VFIO_GROUP_ADD: same as KVM_DEV_VFIO_FILE_ADD for group fd only
+
+  KVM_DEV_VFIO_GROUP_DEL: same as KVM_DEV_VFIO_FILE_DEL for group fd only
+
   KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table
allocated by sPAPR KVM.
kvm_device_attr.addr points to a struct::
@@ -40,7 +52,10 @@ KVM_DEV_VFIO_GROUP attributes:
- @tablefd is a file descriptor for a TCE table allocated via
  KVM_CREATE_SPAPR_TCE.
 
-The GROUP_ADD operation above should be invoked prior to accessing the
+The FILE/GROUP_ADD operation above should be invoked prior to accessing the
 device file descriptor via VFIO_GROUP_GET_DEVICE_FD in order to support
 drivers which require a kvm pointer to be set in their .open_device()
-callback.
+callback.  It is the same for device file descriptor via character device
+open which gets device access via VFIO_DEVICE_BIND_IOMMUFD.  For such file
+descriptors, FILE_ADD should be invoked before VFIO_DEVICE_BIND_IOMMUFD
+to support the drivers mentioned in prior sentence as well.
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index f089ab290978..13065dd96132 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1418,9 +1418,16 @@ struct kvm_device_attr {
__u64   addr;   /* userspace address of attr data */
 };
 
-#define  KVM_DEV_VFIO_GROUP1
-#define   KVM_DEV_VFIO_GROUP_ADD   1
-#define   KVM_DEV_VFIO_GROUP_DEL   2
+#define  KVM_DEV_VFIO_FILE 1
+
+#define   KVM_DEV_VFIO_FILE_ADD1
+#define   KVM_DEV_VFIO_FILE_DEL2
+
+/* KVM_DEV_VFIO_GROUP aliases are for compile time uapi compatibility */
+#define  KVM_DEV_VFIO_GROUPKVM_DEV_VFIO_FILE
+
+#define   KVM_DEV_VFIO_GROUP_ADD   KVM_DEV_VFIO_FILE_ADD
+#define   KVM_DEV_VFIO_GROUP_DEL   KVM_DEV_VFIO_FILE_DEL
 #define   KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE 3
 
 enum kvm_device_type {
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 8f7fa07e8170..07cb5f44b2a2 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -286,12 +286,12 @@ static int kvm_vfio_set_file(struct kvm_device *dev, long 
attr,
int32_t fd;
 
switch (attr) {
-   case KVM_DEV_VFIO_GROUP_ADD:
+   case KVM_DEV_VFIO_FILE_ADD:
if (get_user(fd, argp))
return -EFAULT;
 

[Intel-gfx] [PATCH v15 12/26] vfio: Record devid in vfio_device_file

2023-07-18 Thread Yi Liu
.bind_iommufd() will generate an ID to represent this bond, which is
needed by userspace for further usage. Store devid in vfio_device_file
to avoid passing the pointer in multiple places.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/iommufd.c   | 12 +++-
 drivers/vfio/vfio.h  | 10 +-
 drivers/vfio/vfio_main.c |  6 +++---
 3 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 91fdae69bb45..4fc674c01a05 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -18,14 +18,14 @@ bool vfio_iommufd_device_has_compat_ioas(struct vfio_device 
*vdev,
return !iommufd_vfio_compat_ioas_get_id(ictx, _id);
 }
 
-int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
+int vfio_df_iommufd_bind(struct vfio_device_file *df)
 {
-   u32 device_id;
+   struct vfio_device *vdev = df->device;
+   struct iommufd_ctx *ictx = df->iommufd;
 
lockdep_assert_held(>dev_set->lock);
 
-   /* The legacy path has no way to return the device id */
-   return vdev->ops->bind_iommufd(vdev, ictx, _id);
+   return vdev->ops->bind_iommufd(vdev, ictx, >devid);
 }
 
 int vfio_iommufd_compat_attach_ioas(struct vfio_device *vdev,
@@ -48,8 +48,10 @@ int vfio_iommufd_compat_attach_ioas(struct vfio_device *vdev,
return vdev->ops->attach_ioas(vdev, _id);
 }
 
-void vfio_iommufd_unbind(struct vfio_device *vdev)
+void vfio_df_iommufd_unbind(struct vfio_device_file *df)
 {
+   struct vfio_device *vdev = df->device;
+
lockdep_assert_held(>dev_set->lock);
 
if (vfio_device_is_noiommu(vdev))
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 04755379940c..58801adc1a7e 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -21,6 +21,7 @@ struct vfio_device_file {
struct vfio_group *group;
 
u8 access_granted;
+   u32 devid; /* only valid when iommufd is valid */
spinlock_t kvm_ref_lock; /* protect kvm field */
struct kvm *kvm;
struct iommufd_ctx *iommufd; /* protected by struct 
vfio_device_set::lock */
@@ -236,8 +237,8 @@ static inline void vfio_container_cleanup(void)
 #if IS_ENABLED(CONFIG_IOMMUFD)
 bool vfio_iommufd_device_has_compat_ioas(struct vfio_device *vdev,
 struct iommufd_ctx *ictx);
-int vfio_iommufd_bind(struct vfio_device *device, struct iommufd_ctx *ictx);
-void vfio_iommufd_unbind(struct vfio_device *device);
+int vfio_df_iommufd_bind(struct vfio_device_file *df);
+void vfio_df_iommufd_unbind(struct vfio_device_file *df);
 int vfio_iommufd_compat_attach_ioas(struct vfio_device *device,
struct iommufd_ctx *ictx);
 #else
@@ -248,13 +249,12 @@ vfio_iommufd_device_has_compat_ioas(struct vfio_device 
*vdev,
return false;
 }
 
-static inline int vfio_iommufd_bind(struct vfio_device *device,
-   struct iommufd_ctx *ictx)
+static inline int vfio_df_iommufd_bind(struct vfio_device_file *fd)
 {
return -EOPNOTSUPP;
 }
 
-static inline void vfio_iommufd_unbind(struct vfio_device *device)
+static inline void vfio_df_iommufd_unbind(struct vfio_device_file *df)
 {
 }
 
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index be5e4ddd5901..3a4b7eb128df 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -446,7 +446,7 @@ static int vfio_df_device_first_open(struct 
vfio_device_file *df)
return -ENODEV;
 
if (iommufd)
-   ret = vfio_iommufd_bind(device, iommufd);
+   ret = vfio_df_iommufd_bind(df);
else
ret = vfio_device_group_use_iommu(device);
if (ret)
@@ -461,7 +461,7 @@ static int vfio_df_device_first_open(struct 
vfio_device_file *df)
 
 err_unuse_iommu:
if (iommufd)
-   vfio_iommufd_unbind(device);
+   vfio_df_iommufd_unbind(df);
else
vfio_device_group_unuse_iommu(device);
 err_module_put:
@@ -479,7 +479,7 @@ static void vfio_df_device_last_close(struct 
vfio_device_file *df)
if (device->ops->close_device)
device->ops->close_device(device);
if (iommufd)
-   vfio_iommufd_unbind(device);
+   vfio_df_iommufd_unbind(df);
else
vfio_device_group_unuse_iommu(device);
module_put(device->dev->driver->owner);
-- 
2.34.1



[Intel-gfx] [PATCH v15 18/26] vfio: Add cdev for vfio_device

2023-07-18 Thread Yi Liu
This adds cdev support for vfio_device. It allows the user to directly
open a vfio device w/o using the legacy container/group interface, as a
prerequisite for supporting new iommu features like nested translation
and etc.

The device fd opened in this manner doesn't have the capability to access
the device as the fops open() doesn't open the device until the successful
VFIO_DEVICE_BIND_IOMMUFD ioctl which will be added in a later patch.

With this patch, devices registered to vfio core would have both the legacy
group and the new device interfaces created.

- group interface : /dev/vfio/$groupID
- device interface: /dev/vfio/devices/vfioX - normal device
("X" is a unique number across vfio devices)

For a given device, the user can identify the matching vfioX by searching
the vfio-dev folder under the sysfs path of the device. Take PCI device
(:6a:01.0) as an example, /sys/bus/pci/devices/\:6a\:01.0/vfio-dev/vfioX
implies the matching vfioX under /dev/vfio/devices/, and vfio-dev/vfioX/dev
contains the major:minor number of the matching /dev/vfio/devices/vfioX.
The user can get device fd by opening the /dev/vfio/devices/vfioX.

The vfio_device cdev logic in this patch:
*) __vfio_register_dev() path ends up doing cdev_device_add() for each
   vfio_device if VFIO_DEVICE_CDEV configured.
*) vfio_unregister_group_dev() path does cdev_device_del();

cdev interface does not support noiommu devices, so VFIO only creates the
legacy group interface for the physical devices that do not have IOMMU.
noiommu users should use the legacy group interface.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/Kconfig   | 12 
 drivers/vfio/Makefile  |  1 +
 drivers/vfio/device_cdev.c | 63 ++
 drivers/vfio/vfio.h| 54 
 drivers/vfio/vfio_main.c   | 21 ++---
 include/linux/vfio.h   |  4 +++
 6 files changed, 151 insertions(+), 4 deletions(-)
 create mode 100644 drivers/vfio/device_cdev.c

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index aba36f5be4ec..26f18d92eb97 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -12,6 +12,18 @@ menuconfig VFIO
  If you don't know what to do here, say N.
 
 if VFIO
+config VFIO_DEVICE_CDEV
+   bool "Support for the VFIO cdev /dev/vfio/devices/vfioX"
+   depends on IOMMUFD && !SPAPR_TCE_IOMMU
+   help
+ The VFIO device cdev is another way for userspace to get device
+ access. Userspace gets device fd by opening device cdev under
+ /dev/vfio/devices/vfioX, and then bind the device fd with an iommufd
+ to set up secure DMA context for device access.  This interface does
+ not support noiommu.
+
+ If you don't know what to do here, say N.
+
 config VFIO_CONTAINER
bool "Support for the VFIO container /dev/vfio/vfio"
select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 66f418aef5a9..87ccb16fdd77 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_VFIO) += vfio.o
 vfio-y += vfio_main.o \
  group.o \
  iova_bitmap.o
+vfio-$(CONFIG_VFIO_DEVICE_CDEV) += device_cdev.o
 vfio-$(CONFIG_IOMMUFD) += iommufd.o
 vfio-$(CONFIG_VFIO_CONTAINER) += container.o
 vfio-$(CONFIG_VFIO_VIRQFD) += virqfd.o
diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
new file mode 100644
index ..bf1032d00107
--- /dev/null
+++ b/drivers/vfio/device_cdev.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Intel Corporation.
+ */
+#include 
+
+#include "vfio.h"
+
+static dev_t device_devt;
+
+void vfio_init_device_cdev(struct vfio_device *device)
+{
+   device->device.devt = MKDEV(MAJOR(device_devt), device->index);
+   cdev_init(>cdev, _device_fops);
+   device->cdev.owner = THIS_MODULE;
+}
+
+/*
+ * device access via the fd opened by this function is blocked until
+ * .open_device() is called successfully during BIND_IOMMUFD.
+ */
+int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep)
+{
+   struct vfio_device *device = container_of(inode->i_cdev,
+ struct vfio_device, cdev);
+   struct vfio_device_file *df;
+   int ret;
+
+   /* Paired with the put in vfio_device_fops_release() */
+   if (!vfio_device_try_get_registration(device))
+   return -ENODEV;
+
+   df = vfio_allocate_device_file(device);
+   if (IS_ERR(df)) {
+   ret = PTR_ERR(df);
+   goto err_put_registration;
+   }
+
+   filep->private_data = df;
+
+   return 0;
+
+err_put_registration:
+   

[Intel-gfx] [PATCH v15 14/26] iommufd/device: Add iommufd_access_detach() API

2023-07-18 Thread Yi Liu
From: Nicolin Chen 

Previously, the detach routine is only done by the destroy(). And it was
called by vfio_iommufd_emulated_unbind() when the device runs close(), so
all the mappings in iopt were cleaned in that setup, when the call trace
reaches this detach() routine.

Now, there's a need of a detach uAPI, meaning that it does not only need
a new iommufd_access_detach() API, but also requires access->ops->unmap()
call as a cleanup. So add one.

However, leaving that unprotected can introduce some potential of a race
condition during the pin_/unpin_pages() call, where access->ioas->iopt is
getting referenced. So, add an ioas_lock to protect the context of iopt
referencings.

Also, to allow the iommufd_access_unpin_pages() callback to happen via
this unmap() call, add an ioas_unpin pointer, so the unpin routine won't
be affected by the "access->ioas = NULL" trick.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Nicolin Chen 
Signed-off-by: Yi Liu 
---
 drivers/iommu/iommufd/device.c  | 74 +++--
 drivers/iommu/iommufd/iommufd_private.h |  2 +
 include/linux/iommufd.h |  1 +
 3 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
index cd5d8ab907f9..59fec5783eb9 100644
--- a/drivers/iommu/iommufd/device.c
+++ b/drivers/iommu/iommufd/device.c
@@ -486,6 +486,7 @@ iommufd_access_create(struct iommufd_ctx *ictx,
iommufd_ctx_get(ictx);
iommufd_object_finalize(ictx, >obj);
*id = access->obj.id;
+   mutex_init(>ioas_lock);
return access;
 }
 EXPORT_SYMBOL_NS_GPL(iommufd_access_create, IOMMUFD);
@@ -505,26 +506,60 @@ void iommufd_access_destroy(struct iommufd_access *access)
 }
 EXPORT_SYMBOL_NS_GPL(iommufd_access_destroy, IOMMUFD);
 
+void iommufd_access_detach(struct iommufd_access *access)
+{
+   struct iommufd_ioas *cur_ioas = access->ioas;
+
+   mutex_lock(>ioas_lock);
+   if (WARN_ON(!access->ioas))
+   goto out;
+   /*
+* Set ioas to NULL to block any further iommufd_access_pin_pages().
+* iommufd_access_unpin_pages() can continue using access->ioas_unpin.
+*/
+   access->ioas = NULL;
+
+   if (access->ops->unmap) {
+   mutex_unlock(>ioas_lock);
+   access->ops->unmap(access->data, 0, ULONG_MAX);
+   mutex_lock(>ioas_lock);
+   }
+   iopt_remove_access(_ioas->iopt, access);
+   refcount_dec(_ioas->obj.users);
+out:
+   access->ioas_unpin = NULL;
+   mutex_unlock(>ioas_lock);
+}
+EXPORT_SYMBOL_NS_GPL(iommufd_access_detach, IOMMUFD);
+
 int iommufd_access_attach(struct iommufd_access *access, u32 ioas_id)
 {
struct iommufd_ioas *new_ioas;
int rc = 0;
 
-   if (access->ioas)
+   mutex_lock(>ioas_lock);
+   if (WARN_ON(access->ioas || access->ioas_unpin)) {
+   mutex_unlock(>ioas_lock);
return -EINVAL;
+   }
 
new_ioas = iommufd_get_ioas(access->ictx, ioas_id);
-   if (IS_ERR(new_ioas))
+   if (IS_ERR(new_ioas)) {
+   mutex_unlock(>ioas_lock);
return PTR_ERR(new_ioas);
+   }
 
rc = iopt_add_access(_ioas->iopt, access);
if (rc) {
+   mutex_unlock(>ioas_lock);
iommufd_put_object(_ioas->obj);
return rc;
}
iommufd_ref_to_users(_ioas->obj);
 
access->ioas = new_ioas;
+   access->ioas_unpin = new_ioas;
+   mutex_unlock(>ioas_lock);
return 0;
 }
 EXPORT_SYMBOL_NS_GPL(iommufd_access_attach, IOMMUFD);
@@ -579,8 +614,8 @@ void iommufd_access_notify_unmap(struct io_pagetable *iopt, 
unsigned long iova,
 void iommufd_access_unpin_pages(struct iommufd_access *access,
unsigned long iova, unsigned long length)
 {
-   struct io_pagetable *iopt = >ioas->iopt;
struct iopt_area_contig_iter iter;
+   struct io_pagetable *iopt;
unsigned long last_iova;
struct iopt_area *area;
 
@@ -588,6 +623,17 @@ void iommufd_access_unpin_pages(struct iommufd_access 
*access,
WARN_ON(check_add_overflow(iova, length - 1, _iova)))
return;
 
+   mutex_lock(>ioas_lock);
+   /*
+* The driver must be doing something wrong if it calls this before an
+* iommufd_access_attach() or after an iommufd_access_detach().
+*/
+   if (WARN_ON(!access->ioas_unpin)) {
+   mutex_unlock(>ioas_lock);
+   return;
+   }
+   iopt = >ioas_unpin->iopt;
+
down_read(>iova_rwsem);
iopt_for_each_contig_area(, area, iopt, iova, last_iova)
iopt_area_remove_access(
@@ -597,6 +643,7 @@ void iommufd_access_unpin_pages(struct iommufd_access 
*access,

[Intel-gfx] [PATCH v15 11/26] vfio-iommufd: Split bind/attach into two steps

2023-07-18 Thread Yi Liu
This aligns the bind/attach logic with the coming vfio device cdev support.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c   | 17 +
 drivers/vfio/iommufd.c | 35 +--
 drivers/vfio/vfio.h|  9 +
 3 files changed, 39 insertions(+), 22 deletions(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index b8b77daf7aa6..41a09a2df690 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -207,9 +207,13 @@ static int vfio_df_group_open(struct vfio_device_file *df)
}
 
ret = vfio_df_open(df);
-   if (ret) {
-   df->iommufd = NULL;
+   if (ret)
goto out_put_kvm;
+
+   if (df->iommufd && device->open_count == 1) {
+   ret = vfio_iommufd_compat_attach_ioas(device, df->iommufd);
+   if (ret)
+   goto out_close_device;
}
 
/*
@@ -218,12 +222,17 @@ static int vfio_df_group_open(struct vfio_device_file *df)
 */
smp_store_release(>access_granted, true);
 
+   mutex_unlock(>dev_set->lock);
+   mutex_unlock(>group->group_lock);
+   return 0;
+
+out_close_device:
+   vfio_df_close(df);
 out_put_kvm:
+   df->iommufd = NULL;
if (device->open_count == 0)
vfio_device_put_kvm(device);
-
mutex_unlock(>dev_set->lock);
-
 out_unlock:
mutex_unlock(>group->group_lock);
return ret;
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 36f838dad084..91fdae69bb45 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -20,33 +20,32 @@ bool vfio_iommufd_device_has_compat_ioas(struct vfio_device 
*vdev,
 
 int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
 {
-   u32 ioas_id;
u32 device_id;
+
+   lockdep_assert_held(>dev_set->lock);
+
+   /* The legacy path has no way to return the device id */
+   return vdev->ops->bind_iommufd(vdev, ictx, _id);
+}
+
+int vfio_iommufd_compat_attach_ioas(struct vfio_device *vdev,
+   struct iommufd_ctx *ictx)
+{
+   u32 ioas_id;
int ret;
 
lockdep_assert_held(>dev_set->lock);
 
-   ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
-   if (ret)
-   return ret;
+   /* compat noiommu does not need to do ioas attach */
+   if (vfio_device_is_noiommu(vdev))
+   return 0;
 
ret = iommufd_vfio_compat_ioas_get_id(ictx, _id);
if (ret)
-   goto err_unbind;
-   ret = vdev->ops->attach_ioas(vdev, _id);
-   if (ret)
-   goto err_unbind;
-
-   /*
-* The legacy path has no way to return the device id or the selected
-* pt_id
-*/
-   return 0;
+   return ret;
 
-err_unbind:
-   if (vdev->ops->unbind_iommufd)
-   vdev->ops->unbind_iommufd(vdev);
-   return ret;
+   /* The legacy path has no way to return the selected pt_id */
+   return vdev->ops->attach_ioas(vdev, _id);
 }
 
 void vfio_iommufd_unbind(struct vfio_device *vdev)
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 300cab04f4e1..04755379940c 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -238,6 +238,8 @@ bool vfio_iommufd_device_has_compat_ioas(struct vfio_device 
*vdev,
 struct iommufd_ctx *ictx);
 int vfio_iommufd_bind(struct vfio_device *device, struct iommufd_ctx *ictx);
 void vfio_iommufd_unbind(struct vfio_device *device);
+int vfio_iommufd_compat_attach_ioas(struct vfio_device *device,
+   struct iommufd_ctx *ictx);
 #else
 static inline bool
 vfio_iommufd_device_has_compat_ioas(struct vfio_device *vdev,
@@ -255,6 +257,13 @@ static inline int vfio_iommufd_bind(struct vfio_device 
*device,
 static inline void vfio_iommufd_unbind(struct vfio_device *device)
 {
 }
+
+static inline int
+vfio_iommufd_compat_attach_ioas(struct vfio_device *device,
+   struct iommufd_ctx *ictx)
+{
+   return -EOPNOTSUPP;
+}
 #endif
 
 #if IS_ENABLED(CONFIG_VFIO_VIRQFD)
-- 
2.34.1



[Intel-gfx] [PATCH v15 10/26] vfio-iommufd: Move noiommu compat validation out of vfio_iommufd_bind()

2023-07-18 Thread Yi Liu
This moves the noiommu compat validation logic into vfio_df_group_open().
This is more consistent with what will be done in vfio device cdev path.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c   | 13 +
 drivers/vfio/iommufd.c | 22 --
 drivers/vfio/vfio.h|  9 +
 3 files changed, 30 insertions(+), 14 deletions(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 4e6277191eb4..b8b77daf7aa6 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -192,6 +192,19 @@ static int vfio_df_group_open(struct vfio_device_file *df)
vfio_device_group_get_kvm_safe(device);
 
df->iommufd = device->group->iommufd;
+   if (df->iommufd && vfio_device_is_noiommu(device) && device->open_count 
== 0) {
+   /*
+* Require no compat ioas to be assigned to proceed.  The basic
+* statement is that the user cannot have done something that
+* implies they expected translation to exist
+*/
+   if (!capable(CAP_SYS_RAWIO) ||
+   vfio_iommufd_device_has_compat_ioas(device, df->iommufd))
+   ret = -EPERM;
+   else
+   ret = 0;
+   goto out_put_kvm;
+   }
 
ret = vfio_df_open(df);
if (ret) {
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index afda47ee9663..36f838dad084 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -10,6 +10,14 @@
 MODULE_IMPORT_NS(IOMMUFD);
 MODULE_IMPORT_NS(IOMMUFD_VFIO);
 
+bool vfio_iommufd_device_has_compat_ioas(struct vfio_device *vdev,
+struct iommufd_ctx *ictx)
+{
+   u32 ioas_id;
+
+   return !iommufd_vfio_compat_ioas_get_id(ictx, _id);
+}
+
 int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
 {
u32 ioas_id;
@@ -18,20 +26,6 @@ int vfio_iommufd_bind(struct vfio_device *vdev, struct 
iommufd_ctx *ictx)
 
lockdep_assert_held(>dev_set->lock);
 
-   if (vfio_device_is_noiommu(vdev)) {
-   if (!capable(CAP_SYS_RAWIO))
-   return -EPERM;
-
-   /*
-* Require no compat ioas to be assigned to proceed. The basic
-* statement is that the user cannot have done something that
-* implies they expected translation to exist
-*/
-   if (!iommufd_vfio_compat_ioas_get_id(ictx, _id))
-   return -EPERM;
-   return 0;
-   }
-
ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
if (ret)
return ret;
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 85484a971a3e..300cab04f4e1 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -234,9 +234,18 @@ static inline void vfio_container_cleanup(void)
 #endif
 
 #if IS_ENABLED(CONFIG_IOMMUFD)
+bool vfio_iommufd_device_has_compat_ioas(struct vfio_device *vdev,
+struct iommufd_ctx *ictx);
 int vfio_iommufd_bind(struct vfio_device *device, struct iommufd_ctx *ictx);
 void vfio_iommufd_unbind(struct vfio_device *device);
 #else
+static inline bool
+vfio_iommufd_device_has_compat_ioas(struct vfio_device *vdev,
+   struct iommufd_ctx *ictx)
+{
+   return false;
+}
+
 static inline int vfio_iommufd_bind(struct vfio_device *device,
struct iommufd_ctx *ictx)
 {
-- 
2.34.1



[Intel-gfx] [PATCH v15 04/26] kvm/vfio: Prepare for accepting vfio device fd

2023-07-18 Thread Yi Liu
This renames kvm_vfio_group related helpers to prepare for accepting
vfio device fd. No functional change is intended.

Reviewed-by: Kevin Tian 
Reviewed-by: Eric Auger 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 virt/kvm/vfio.c | 115 
 1 file changed, 58 insertions(+), 57 deletions(-)

diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index b33c7b8488b3..8f7fa07e8170 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -21,7 +21,7 @@
 #include 
 #endif
 
-struct kvm_vfio_group {
+struct kvm_vfio_file {
struct list_head node;
struct file *file;
 #ifdef CONFIG_SPAPR_TCE_IOMMU
@@ -30,7 +30,7 @@ struct kvm_vfio_group {
 };
 
 struct kvm_vfio {
-   struct list_head group_list;
+   struct list_head file_list;
struct mutex lock;
bool noncoherent;
 };
@@ -98,34 +98,35 @@ static struct iommu_group *kvm_vfio_file_iommu_group(struct 
file *file)
 }
 
 static void kvm_spapr_tce_release_vfio_group(struct kvm *kvm,
-struct kvm_vfio_group *kvg)
+struct kvm_vfio_file *kvf)
 {
-   if (WARN_ON_ONCE(!kvg->iommu_group))
+   if (WARN_ON_ONCE(!kvf->iommu_group))
return;
 
-   kvm_spapr_tce_release_iommu_group(kvm, kvg->iommu_group);
-   iommu_group_put(kvg->iommu_group);
-   kvg->iommu_group = NULL;
+   kvm_spapr_tce_release_iommu_group(kvm, kvf->iommu_group);
+   iommu_group_put(kvf->iommu_group);
+   kvf->iommu_group = NULL;
 }
 #endif
 
 /*
- * Groups can use the same or different IOMMU domains.  If the same then
- * adding a new group may change the coherency of groups we've previously
- * been told about.  We don't want to care about any of that so we retest
- * each group and bail as soon as we find one that's noncoherent.  This
- * means we only ever [un]register_noncoherent_dma once for the whole device.
+ * Groups/devices can use the same or different IOMMU domains. If the same
+ * then adding a new group/device may change the coherency of groups/devices
+ * we've previously been told about. We don't want to care about any of
+ * that so we retest each group/device and bail as soon as we find one that's
+ * noncoherent.  This means we only ever [un]register_noncoherent_dma once
+ * for the whole device.
  */
 static void kvm_vfio_update_coherency(struct kvm_device *dev)
 {
struct kvm_vfio *kv = dev->private;
bool noncoherent = false;
-   struct kvm_vfio_group *kvg;
+   struct kvm_vfio_file *kvf;
 
mutex_lock(>lock);
 
-   list_for_each_entry(kvg, >group_list, node) {
-   if (!kvm_vfio_file_enforced_coherent(kvg->file)) {
+   list_for_each_entry(kvf, >file_list, node) {
+   if (!kvm_vfio_file_enforced_coherent(kvf->file)) {
noncoherent = true;
break;
}
@@ -143,10 +144,10 @@ static void kvm_vfio_update_coherency(struct kvm_device 
*dev)
mutex_unlock(>lock);
 }
 
-static int kvm_vfio_group_add(struct kvm_device *dev, unsigned int fd)
+static int kvm_vfio_file_add(struct kvm_device *dev, unsigned int fd)
 {
struct kvm_vfio *kv = dev->private;
-   struct kvm_vfio_group *kvg;
+   struct kvm_vfio_file *kvf;
struct file *filp;
int ret;
 
@@ -162,27 +163,27 @@ static int kvm_vfio_group_add(struct kvm_device *dev, 
unsigned int fd)
 
mutex_lock(>lock);
 
-   list_for_each_entry(kvg, >group_list, node) {
-   if (kvg->file == filp) {
+   list_for_each_entry(kvf, >file_list, node) {
+   if (kvf->file == filp) {
ret = -EEXIST;
goto err_unlock;
}
}
 
-   kvg = kzalloc(sizeof(*kvg), GFP_KERNEL_ACCOUNT);
-   if (!kvg) {
+   kvf = kzalloc(sizeof(*kvf), GFP_KERNEL_ACCOUNT);
+   if (!kvf) {
ret = -ENOMEM;
goto err_unlock;
}
 
-   kvg->file = filp;
-   list_add_tail(>node, >group_list);
+   kvf->file = filp;
+   list_add_tail(>node, >file_list);
 
kvm_arch_start_assignment(dev->kvm);
 
mutex_unlock(>lock);
 
-   kvm_vfio_file_set_kvm(kvg->file, dev->kvm);
+   kvm_vfio_file_set_kvm(kvf->file, dev->kvm);
kvm_vfio_update_coherency(dev);
 
return 0;
@@ -193,10 +194,10 @@ static int kvm_vfio_group_add(struct kvm_device *dev, 
unsigned int fd)
return ret;
 }
 
-static int kvm_vfio_group_del(struct kvm_device *dev, unsigned int fd)
+static int kvm_vfio_file_del(struct kvm_device *dev, unsigned int fd)
 {
struct kvm_vfio *kv = dev->private;
-   struct kvm_vfio_group *kvg;
+   struct kvm_vfio_file *kvf;
struct fd f;
int ret;
 
@@ 

[Intel-gfx] [PATCH v15 06/26] vfio: Pass struct vfio_device_file * to vfio_device_open/close()

2023-07-18 Thread Yi Liu
This avoids passing too much parameters in multiple functions. Per the
input parameter change, rename the function to be vfio_df_open/close().

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Eric Auger 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c | 20 ++--
 drivers/vfio/vfio.h  |  8 
 drivers/vfio/vfio_main.c | 25 +++--
 3 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index b56e19d2a02d..caf53716ddb2 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -169,8 +169,9 @@ static void vfio_device_group_get_kvm_safe(struct 
vfio_device *device)
spin_unlock(>group->kvm_ref_lock);
 }
 
-static int vfio_device_group_open(struct vfio_device *device)
+static int vfio_df_group_open(struct vfio_device_file *df)
 {
+   struct vfio_device *device = df->device;
int ret;
 
mutex_lock(>group->group_lock);
@@ -190,7 +191,11 @@ static int vfio_device_group_open(struct vfio_device 
*device)
if (device->open_count == 0)
vfio_device_group_get_kvm_safe(device);
 
-   ret = vfio_device_open(device, device->group->iommufd);
+   df->iommufd = device->group->iommufd;
+
+   ret = vfio_df_open(df);
+   if (ret)
+   df->iommufd = NULL;
 
if (device->open_count == 0)
vfio_device_put_kvm(device);
@@ -202,12 +207,15 @@ static int vfio_device_group_open(struct vfio_device 
*device)
return ret;
 }
 
-void vfio_device_group_close(struct vfio_device *device)
+void vfio_df_group_close(struct vfio_device_file *df)
 {
+   struct vfio_device *device = df->device;
+
mutex_lock(>group->group_lock);
mutex_lock(>dev_set->lock);
 
-   vfio_device_close(device, device->group->iommufd);
+   vfio_df_close(df);
+   df->iommufd = NULL;
 
if (device->open_count == 0)
vfio_device_put_kvm(device);
@@ -228,7 +236,7 @@ static struct file *vfio_device_open_file(struct 
vfio_device *device)
goto err_out;
}
 
-   ret = vfio_device_group_open(device);
+   ret = vfio_df_group_open(df);
if (ret)
goto err_free;
 
@@ -260,7 +268,7 @@ static struct file *vfio_device_open_file(struct 
vfio_device *device)
return filep;
 
 err_close_device:
-   vfio_device_group_close(device);
+   vfio_df_group_close(df);
 err_free:
kfree(df);
 err_out:
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 332528af0846..2094f5a4ef04 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -21,13 +21,13 @@ struct vfio_device_file {
 
spinlock_t kvm_ref_lock; /* protect kvm field */
struct kvm *kvm;
+   struct iommufd_ctx *iommufd; /* protected by struct 
vfio_device_set::lock */
 };
 
 void vfio_device_put_registration(struct vfio_device *device);
 bool vfio_device_try_get_registration(struct vfio_device *device);
-int vfio_device_open(struct vfio_device *device, struct iommufd_ctx *iommufd);
-void vfio_device_close(struct vfio_device *device,
-  struct iommufd_ctx *iommufd);
+int vfio_df_open(struct vfio_device_file *df);
+void vfio_df_close(struct vfio_device_file *df);
 struct vfio_device_file *
 vfio_allocate_device_file(struct vfio_device *device);
 
@@ -92,7 +92,7 @@ void vfio_device_group_register(struct vfio_device *device);
 void vfio_device_group_unregister(struct vfio_device *device);
 int vfio_device_group_use_iommu(struct vfio_device *device);
 void vfio_device_group_unuse_iommu(struct vfio_device *device);
-void vfio_device_group_close(struct vfio_device *device);
+void vfio_df_group_close(struct vfio_device_file *df);
 struct vfio_group *vfio_group_from_file(struct file *file);
 bool vfio_group_enforced_coherent(struct vfio_group *group);
 void vfio_group_set_kvm(struct vfio_group *group, struct kvm *kvm);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 8ef9210ad2aa..825b1eeaebe2 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -434,9 +434,10 @@ vfio_allocate_device_file(struct vfio_device *device)
return df;
 }
 
-static int vfio_device_first_open(struct vfio_device *device,
- struct iommufd_ctx *iommufd)
+static int vfio_df_device_first_open(struct vfio_device_file *df)
 {
+   struct vfio_device *device = df->device;
+   struct iommufd_ctx *iommufd = df->iommufd;
int ret;
 
lockdep_assert_held(>dev_set->lock);
@@ -468,9 +469,11 @@ static int vfio_device_first_open(struct vfio_device 
*device,
return ret;
 }
 
-static void vfio_device_last_close(struct vfio_device *device,
-  struct iommufd_ctx *iommufd)
+static void 

[Intel-gfx] [PATCH v15 03/26] vfio: Accept vfio device file in the KVM facing kAPI

2023-07-18 Thread Yi Liu
This makes the vfio file kAPIs to accept vfio device files, also a
preparation for vfio device cdev support.

For the kvm set with vfio device file, kvm pointer is stored in struct
vfio_device_file, and use kvm_ref_lock to protect kvm set and kvm
pointer usage within VFIO. This kvm pointer will be set to vfio_device
after device file is bound to iommufd in the cdev path.

Reviewed-by: Kevin Tian 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/vfio.h  |  3 +++
 drivers/vfio/vfio_main.c | 36 +++-
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index b1e327a85a32..332528af0846 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -18,6 +18,9 @@ struct vfio_container;
 
 struct vfio_device_file {
struct vfio_device *device;
+
+   spinlock_t kvm_ref_lock; /* protect kvm field */
+   struct kvm *kvm;
 };
 
 void vfio_device_put_registration(struct vfio_device *device);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 4665791aa2eb..8ef9210ad2aa 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -429,6 +429,7 @@ vfio_allocate_device_file(struct vfio_device *device)
return ERR_PTR(-ENOMEM);
 
df->device = device;
+   spin_lock_init(>kvm_ref_lock);
 
return df;
 }
@@ -1190,13 +1191,23 @@ const struct file_operations vfio_device_fops = {
.mmap   = vfio_device_fops_mmap,
 };
 
+static struct vfio_device *vfio_device_from_file(struct file *file)
+{
+   struct vfio_device_file *df = file->private_data;
+
+   if (file->f_op != _device_fops)
+   return NULL;
+   return df->device;
+}
+
 /**
  * vfio_file_is_valid - True if the file is valid vfio file
  * @file: VFIO group file or VFIO device file
  */
 bool vfio_file_is_valid(struct file *file)
 {
-   return vfio_group_from_file(file);
+   return vfio_group_from_file(file) ||
+  vfio_device_from_file(file);
 }
 EXPORT_SYMBOL_GPL(vfio_file_is_valid);
 
@@ -1211,16 +1222,36 @@ EXPORT_SYMBOL_GPL(vfio_file_is_valid);
  */
 bool vfio_file_enforced_coherent(struct file *file)
 {
+   struct vfio_device *device;
struct vfio_group *group;
 
group = vfio_group_from_file(file);
if (group)
return vfio_group_enforced_coherent(group);
 
+   device = vfio_device_from_file(file);
+   if (device)
+   return device_iommu_capable(device->dev,
+   IOMMU_CAP_ENFORCE_CACHE_COHERENCY);
+
return true;
 }
 EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
 
+static void vfio_device_file_set_kvm(struct file *file, struct kvm *kvm)
+{
+   struct vfio_device_file *df = file->private_data;
+
+   /*
+* The kvm is first recorded in the vfio_device_file, and will
+* be propagated to vfio_device::kvm when the file is bound to
+* iommufd successfully in the vfio device cdev path.
+*/
+   spin_lock(>kvm_ref_lock);
+   df->kvm = kvm;
+   spin_unlock(>kvm_ref_lock);
+}
+
 /**
  * vfio_file_set_kvm - Link a kvm with VFIO drivers
  * @file: VFIO group file or VFIO device file
@@ -1236,6 +1267,9 @@ void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
group = vfio_group_from_file(file);
if (group)
vfio_group_set_kvm(group, kvm);
+
+   if (vfio_device_from_file(file))
+   vfio_device_file_set_kvm(file, kvm);
 }
 EXPORT_SYMBOL_GPL(vfio_file_set_kvm);
 
-- 
2.34.1



[Intel-gfx] [PATCH v15 02/26] vfio: Refine vfio file kAPIs for KVM

2023-07-18 Thread Yi Liu
This prepares for making the below kAPIs to accept both group file
and device file instead of only vfio group file.

  bool vfio_file_enforced_coherent(struct file *file);
  void vfio_file_set_kvm(struct file *file, struct kvm *kvm);

Reviewed-by: Kevin Tian 
Reviewed-by: Eric Auger 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c | 53 +---
 drivers/vfio/vfio.h  |  3 +++
 drivers/vfio/vfio_main.c | 49 +
 include/linux/vfio.h |  1 +
 virt/kvm/vfio.c  | 10 
 5 files changed, 75 insertions(+), 41 deletions(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index fbba9fc15e57..b56e19d2a02d 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -754,6 +754,15 @@ bool vfio_device_has_container(struct vfio_device *device)
return device->group->container;
 }
 
+struct vfio_group *vfio_group_from_file(struct file *file)
+{
+   struct vfio_group *group = file->private_data;
+
+   if (file->f_op != _group_fops)
+   return NULL;
+   return group;
+}
+
 /**
  * vfio_file_iommu_group - Return the struct iommu_group for the vfio group 
file
  * @file: VFIO group file
@@ -764,13 +773,13 @@ bool vfio_device_has_container(struct vfio_device *device)
  */
 struct iommu_group *vfio_file_iommu_group(struct file *file)
 {
-   struct vfio_group *group = file->private_data;
+   struct vfio_group *group = vfio_group_from_file(file);
struct iommu_group *iommu_group = NULL;
 
if (!IS_ENABLED(CONFIG_SPAPR_TCE_IOMMU))
return NULL;
 
-   if (!vfio_file_is_group(file))
+   if (!group)
return NULL;
 
mutex_lock(>group_lock);
@@ -784,33 +793,20 @@ struct iommu_group *vfio_file_iommu_group(struct file 
*file)
 EXPORT_SYMBOL_GPL(vfio_file_iommu_group);
 
 /**
- * vfio_file_is_group - True if the file is usable with VFIO aPIS
+ * vfio_file_is_group - True if the file is a vfio group file
  * @file: VFIO group file
  */
 bool vfio_file_is_group(struct file *file)
 {
-   return file->f_op == _group_fops;
+   return vfio_group_from_file(file);
 }
 EXPORT_SYMBOL_GPL(vfio_file_is_group);
 
-/**
- * vfio_file_enforced_coherent - True if the DMA associated with the VFIO file
- *is always CPU cache coherent
- * @file: VFIO group file
- *
- * Enforced coherency means that the IOMMU ignores things like the PCIe 
no-snoop
- * bit in DMA transactions. A return of false indicates that the user has
- * rights to access additional instructions such as wbinvd on x86.
- */
-bool vfio_file_enforced_coherent(struct file *file)
+bool vfio_group_enforced_coherent(struct vfio_group *group)
 {
-   struct vfio_group *group = file->private_data;
struct vfio_device *device;
bool ret = true;
 
-   if (!vfio_file_is_group(file))
-   return true;
-
/*
 * If the device does not have IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
 * any domain later attached to it will also not support it. If the cap
@@ -828,28 +824,13 @@ bool vfio_file_enforced_coherent(struct file *file)
mutex_unlock(>device_lock);
return ret;
 }
-EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
 
-/**
- * vfio_file_set_kvm - Link a kvm with VFIO drivers
- * @file: VFIO group file
- * @kvm: KVM to link
- *
- * When a VFIO device is first opened the KVM will be available in
- * device->kvm if one was associated with the group.
- */
-void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
+void vfio_group_set_kvm(struct vfio_group *group, struct kvm *kvm)
 {
-   struct vfio_group *group = file->private_data;
-
-   if (!vfio_file_is_group(file))
-   return;
-
spin_lock(>kvm_ref_lock);
group->kvm = kvm;
spin_unlock(>kvm_ref_lock);
 }
-EXPORT_SYMBOL_GPL(vfio_file_set_kvm);
 
 /**
  * vfio_file_has_dev - True if the VFIO file is a handle for device
@@ -860,9 +841,9 @@ EXPORT_SYMBOL_GPL(vfio_file_set_kvm);
  */
 bool vfio_file_has_dev(struct file *file, struct vfio_device *device)
 {
-   struct vfio_group *group = file->private_data;
+   struct vfio_group *group = vfio_group_from_file(file);
 
-   if (!vfio_file_is_group(file))
+   if (!group)
return false;
 
return group == device->group;
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 87d3dd6b9ef9..b1e327a85a32 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -90,6 +90,9 @@ void vfio_device_group_unregister(struct vfio_device *device);
 int vfio_device_group_use_iommu(struct vfio_device *device);
 void vfio_device_group_unuse_iommu(struct vfio_device *device);
 void vfio_device_group_close(struct vfio_device *device);
+struct vfio_group 

[Intel-gfx] [PATCH v15 01/26] vfio: Allocate per device file structure

2023-07-18 Thread Yi Liu
This is preparation for adding vfio device cdev support. vfio device
cdev requires:
1) A per device file memory to store the kvm pointer set by KVM. It will
   be propagated to vfio_device:kvm after the device cdev file is bound
   to an iommufd.
2) A mechanism to block device access through device cdev fd before it
   is bound to an iommufd.

To address the above requirements, this adds a per device file structure
named vfio_device_file. For now, it's only a wrapper of struct vfio_device
pointer. Other fields will be added to this per file structure in future
commits.

Reviewed-by: Kevin Tian 
Reviewed-by: Eric Auger 
Reviewed-by: Jason Gunthorpe 
Tested-by: Terrence Xu 
Tested-by: Nicolin Chen 
Tested-by: Matthew Rosato 
Tested-by: Yanting Jiang 
Tested-by: Shameer Kolothum 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/group.c | 13 +++--
 drivers/vfio/vfio.h  |  6 ++
 drivers/vfio/vfio_main.c | 31 ++-
 3 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index fc75c1000d74..fbba9fc15e57 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -218,19 +218,26 @@ void vfio_device_group_close(struct vfio_device *device)
 
 static struct file *vfio_device_open_file(struct vfio_device *device)
 {
+   struct vfio_device_file *df;
struct file *filep;
int ret;
 
+   df = vfio_allocate_device_file(device);
+   if (IS_ERR(df)) {
+   ret = PTR_ERR(df);
+   goto err_out;
+   }
+
ret = vfio_device_group_open(device);
if (ret)
-   goto err_out;
+   goto err_free;
 
/*
 * We can't use anon_inode_getfd() because we need to modify
 * the f_mode flags directly to allow more than just ioctls
 */
filep = anon_inode_getfile("[vfio-device]", _device_fops,
-  device, O_RDWR);
+  df, O_RDWR);
if (IS_ERR(filep)) {
ret = PTR_ERR(filep);
goto err_close_device;
@@ -254,6 +261,8 @@ static struct file *vfio_device_open_file(struct 
vfio_device *device)
 
 err_close_device:
vfio_device_group_close(device);
+err_free:
+   kfree(df);
 err_out:
return ERR_PTR(ret);
 }
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 7b19c621e0e6..87d3dd6b9ef9 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -16,11 +16,17 @@ struct iommufd_ctx;
 struct iommu_group;
 struct vfio_container;
 
+struct vfio_device_file {
+   struct vfio_device *device;
+};
+
 void vfio_device_put_registration(struct vfio_device *device);
 bool vfio_device_try_get_registration(struct vfio_device *device);
 int vfio_device_open(struct vfio_device *device, struct iommufd_ctx *iommufd);
 void vfio_device_close(struct vfio_device *device,
   struct iommufd_ctx *iommufd);
+struct vfio_device_file *
+vfio_allocate_device_file(struct vfio_device *device);
 
 extern const struct file_operations vfio_device_fops;
 
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index ab4f3a794f78..39c1158ffef0 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -419,6 +419,20 @@ static bool vfio_assert_device_open(struct vfio_device 
*device)
return !WARN_ON_ONCE(!READ_ONCE(device->open_count));
 }
 
+struct vfio_device_file *
+vfio_allocate_device_file(struct vfio_device *device)
+{
+   struct vfio_device_file *df;
+
+   df = kzalloc(sizeof(*df), GFP_KERNEL_ACCOUNT);
+   if (!df)
+   return ERR_PTR(-ENOMEM);
+
+   df->device = device;
+
+   return df;
+}
+
 static int vfio_device_first_open(struct vfio_device *device,
  struct iommufd_ctx *iommufd)
 {
@@ -532,12 +546,15 @@ static inline void vfio_device_pm_runtime_put(struct 
vfio_device *device)
  */
 static int vfio_device_fops_release(struct inode *inode, struct file *filep)
 {
-   struct vfio_device *device = filep->private_data;
+   struct vfio_device_file *df = filep->private_data;
+   struct vfio_device *device = df->device;
 
vfio_device_group_close(device);
 
vfio_device_put_registration(device);
 
+   kfree(df);
+
return 0;
 }
 
@@ -1102,7 +1119,8 @@ static int vfio_ioctl_device_feature(struct vfio_device 
*device,
 static long vfio_device_fops_unl_ioctl(struct file *filep,
   unsigned int cmd, unsigned long arg)
 {
-   struct vfio_device *device = filep->private_data;
+   struct vfio_device_file *df = filep->private_data;
+   struct vfio_device *device = df->device;
int ret;
 
ret = vfio_device_pm_runtime_get(device);
@@ -1129,7 +1147,8 @@ static long vfio_device_fops_unl_ioctl(struct file *filep,
 static ssize_t vfio_device_fops_read(struct file *filep, char __user *buf,
 

[Intel-gfx] [PATCH v15 00/26] Add vfio_device cdev for iommufd support

2023-07-18 Thread Yi Liu
Existing VFIO provides group-centric user APIs for userspace. Userspace
opens the /dev/vfio/$group_id first before getting device fd and hence
getting access to device. This is not the desired model for iommufd. Per
the conclusion of community discussion[1], iommufd provides device-centric
kAPIs and requires its consumer (like VFIO) to be device-centric user
APIs. Such user APIs are used to associate device with iommufd and also
the I/O address spaces managed by the iommufd.

This series first introduces a per device file structure to be prepared
for further enhancement and refactors the kvm-vfio code to be prepared
for accepting device file from userspace. After this, adds a mechanism for
blocking device access before iommufd bind. Then refactors the vfio to be
able to handle cdev paths (e.g. iommufd binding, no-iommufd, [de]attach ioas).
This refactor includes making the device_open exclusive between the group
and the cdev path, only allow single device open in cdev path; vfio-iommufd
code is also refactored to support cdev. e.g. split the vfio_iommufd_bind()
into two steps. Eventually, adds the cdev support for vfio device and the
new ioctls, then makes group infrastructure optional as it is not needed
when vfio device cdev is compiled.

This series is based on some preparation works done to vfio emulated devices[2]
and vfio pci hot reset enhancements[3]. Per discussion[4], this series does not
support cdev for physical devices that do not have IOMMU. Such devices only
have group-centric user APIs.

This series is a prerequisite for iommu nesting for vfio device[5] [6].

The complete code can be found in below branch, simple tests done to the
legacy group path and the cdev path. QEMU changes are in upstreaming[7]
and the complete code can be found at[8]

https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v15
(config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)

base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c

[1] 
https://lore.kernel.org/kvm/bn9pr11mb5433b1e4ae5b0480369f97178c...@bn9pr11mb5433.namprd11.prod.outlook.com/
[2] https://lore.kernel.org/kvm/20230327093351.44505-1-yi.l@intel.com/ - 
merged
[3] https://lore.kernel.org/kvm/20230718105542.4138-1-yi.l@intel.com/
[4] 
https://lore.kernel.org/kvm/20230525095939.37ddb8ce.alex.william...@redhat.com/
[5] 
https://lore.kernel.org/linux-iommu/20230511143844.22693-1-yi.l@intel.com/
[6] 
https://lore.kernel.org/linux-iommu/20230511145110.27707-1-yi.l@intel.com/#t
[7] 
https://lore.kernel.org/qemu-devel/20230712072528.275577-1-zhenzhong.d...@intel.com/
[8] https://github.com/yiliu1765/qemu/tree/zhenzhong/iommufd_rfcv4

Change log:

v15:
 - Add Jason's r-b to patch 14, 17, 19, 21, 23, 24 and 26 of cdev v14
 - Tweak the iommufd_ctx_from_fd() in patch 20 per Jason's suggestion (Jason)
 - Return -ENOTTY in vfio_df_ioctl_bind_iommufd() stub function (Jason)
 - Add t-b from Zhenzhong (wrote a selftest app to verify functions of this 
patchset
   by referencing https://github.com/awilliam/tests/)

v14: https://lore.kernel.org/kvm/20230711025928.6438-1-yi.l@intel.com/
 - Add Jason's r-b to patch 10, 11, 12, 13, 15, 16, 17 and 23 of cdev v12
 - Refine iommufd_access_detach() (Jason)
 - Split the device_del() movement to be a separate patch (Jason)
 - Move kvm !null test into _vfio_device_get_kvm_safe() to save some lines
   and rename it to be vfio_device_get_kvm_safe() (Jason)
 - Make VFIO_DEVICE_CDEV depending on !SPAPR_TCE_IOMMU to suit the fact that
   SPAPR_TCE_IOMMU does not support cdev (Alex)
 - Add iommufd_ctx_from_fd() to replace vfio_get_iommufd_from_fd() (Jason)
 - Check cdev only ioctls in vfio_device_fops_unl_ioctl() (Jason)
 - patch 17, 19, 20 and 21 of v14 is newly added per above review comemnts.

v13: https://lore.kernel.org/kvm/20230616093946.68711-1-yi.l@intel.com/
 - vfio_device_first_open() and vfio_device_last_close() to be 
vfio_df_device_first_open()
   vfio_df_device_last_close() (Alex)
 - Define struct vfio_device_file::access_granted as u8 and also place the u32 
devid to
   be behind this flag as this structure access is hot, so needs to avoid too 
much hole
   in the structure (Alex)
 - Use u8 instead bool in the struct vfio_device for the flags (Alex)
 - Define BIND, ATTACH, DETACH ioctl behind VFIO_DEVICE_FEATURE whose offset is 
17 (Alex)
 - Drop patch 20, 21, 22 of v12 (Alex)
 - Per the patch drop, still needs to detect the physical devices that do not 
have
   IOMMU in the cdev registration as cdev does not support such devices. Per the
   suggestion from Jason, lift the IOMMU_CAP_CACHE_COHERENCY check to be in 
vfio_main.c
   so that it can fail the registration of such devices if only cdev is 
compiled. (Jason, Alex)
 - Refine the vfio.rst doc, highlight that the cdev device access is stil bound 
with
   iommu group. (Alex)
 - Reaffirm t-b from below folks:
   Nicolin Chen - Test nesting branch which is based on cdev v12, the test is 
done on ARM64 (SMMUv3)
   Matthew 

Re: [Intel-gfx] [PATCH v5 1/9] drm-tip: 2023y-07m-17d-16h-04m-53s UTC integration manifest

2023-07-18 Thread Andi Shyti
Sorry! wrong format-patch :)
Please ignore patch 1.

Andi

On Tue, Jul 18, 2023 at 03:38:28PM +0200, Andi Shyti wrote:
> From: Robert Foss 
> 
> ---
>  integration-manifest | 24 
>  1 file changed, 24 insertions(+)
>  create mode 100644 integration-manifest
> 
> diff --git a/integration-manifest b/integration-manifest
> new file mode 100644
> index 0..8642016b34817
> --- /dev/null
> +++ b/integration-manifest
> @@ -0,0 +1,24 @@
> +drm drm-fixes 38d88d5e97c9032ebeca092b9372209f2ca92cdf
> + Merge tag 'amd-drm-fixes-6.5-2023-07-12' of 
> https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
> +drm-misc drm-misc-fixes 05abb3be91d8788328231ee02973ab3d47f5e3d2
> + dma-buf/dma-resv: Stop leaking on krealloc() failure
> +drm-intel drm-intel-fixes fdf0eaf11452d72945af31804e2a1048ee1b574c
> + Linux 6.5-rc2
> +drm drm-next 6c7f27441d6af776a89147027c6f4a11c0162c64
> + Merge tag 'drm-misc-next-2023-07-13' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-next
> +drm-misc drm-misc-next-fixes 59bba51ec2a50e3dc5c3ee80f0a23207346303ff
> + drm/panel: Fine tune Starry-ili9882t panel HFP and HBP
> +drm-intel drm-intel-next-fixes f6cf3883df471abbcf1553127681dc244c8ff8dd
> + drm/i915: use mock device info for creating mock device
> +drm-misc drm-misc-next 41639b3a8b0f1f194dfe0577d99db70613f78626
> + drm/bridge: anx7625: Use common macros for HDCP capabilities
> +drm-intel drm-intel-next c5741c5c1122b7944d9af185c83ab7056153259e
> + drm/i915/display: Do not use stolen on MTL
> +drm-intel drm-intel-gt-next 8529e3777b7644d41105a06141574a24795f8348
> + drm/i915/gt: Do not use stolen on MTL
> +drm-intel topic/core-for-CI c0ea2fa0491287dea97b384bec1b5a614408b8e3
> + drm/i915/gsc: define gsc fw
> +drm-misc topic/i915-ttm 1e3944578b749449bd7fa6bf0bae4c3d3f5f1733
> + Merge tag 'amd-drm-next-5.16-2021-09-27' of 
> https://gitlab.freedesktop.org/agd5f/linux into drm-next
> +drm topic/nouveau-misc dfc4005f8c172eea359f9db08c3b2b0ff0153699
> + drm/nouveau/disp: move DAC load detection method
> -- 
> 2.40.1


[Intel-gfx] [PATCH v5 9/9] drm/i915/gt: Support aux invalidation on all engines

2023-07-18 Thread Andi Shyti
Perform some refactoring with the purpose of keeping in one
single place all the operations around the aux table
invalidation.

With this refactoring add more engines where the invalidation
should be performed.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Matt Roper 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 58 +++-
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h |  3 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 17 +--
 3 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 029ef1a5d3b6a..05f5794ce7fa7 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,9 +165,36 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
 }
 
-u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t 
inv_reg)
+static i915_reg_t gen12_get_aux_inv_reg(struct intel_engine_cs *engine)
 {
-   u32 gsi_offset = gt->uncore->gsi_offset;
+   if (!HAS_AUX_CCS(engine->i915))
+   return INVALID_MMIO_REG;
+
+   switch (engine->id) {
+   case RCS0:
+   return GEN12_CCS_AUX_INV;
+   case BCS0:
+   return GEN12_BCS0_AUX_INV;
+   case VCS0:
+   return GEN12_VD0_AUX_INV;
+   case VCS2:
+   return GEN12_VD2_AUX_INV;
+   case VECS0:
+   return GEN12_VE0_AUX_INV;
+   case CCS0:
+   return GEN12_CCS0_AUX_INV;
+   default:
+   return INVALID_MMIO_REG;
+   }
+}
+
+u32 *gen12_emit_aux_table_inv(struct intel_engine_cs *engine, u32 *cs)
+{
+   i915_reg_t inv_reg = gen12_get_aux_inv_reg(engine);
+   u32 gsi_offset = engine->gt->uncore->gsi_offset;
+
+   if (i915_mmio_reg_valid(inv_reg))
+   return cs;
 
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
@@ -201,6 +228,11 @@ static u32 *intel_emit_pipe_control_cs(struct i915_request 
*rq, u32 bit_group_0,
return cs;
 }
 
+static bool gen12_engine_has_aux_inv(struct intel_engine_cs *engine)
+{
+   return i915_mmio_reg_valid(gen12_get_aux_inv_reg(engine));
+}
+
 static int mtl_dummy_pipe_control(struct i915_request *rq)
 {
/* Wa_14016712196 */
@@ -307,11 +339,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
 
-   if (!HAS_FLAT_CCS(rq->engine->i915)) {
-   /* hsdes: 1809175790 */
-   cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
- GEN12_CCS_AUX_INV);
-   }
+   cs = gen12_emit_aux_table_inv(engine, cs);
 
*cs++ = preparser_disable(false);
intel_ring_advance(rq, cs);
@@ -322,22 +350,17 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
 
 int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 {
-   intel_engine_mask_t aux_inv = 0;
u32 cmd = 4;
u32 *cs;
 
if (mode & EMIT_INVALIDATE)
cmd += 2;
 
-   if (HAS_AUX_CCS(rq->engine->i915))
-   aux_inv = rq->engine->mask &
- ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-
/*
 * Aux invalidations on Aux CCS platforms require
 * memory traffic is quiesced prior.
 */
-   if (aux_inv) {
+   if (gen12_engine_has_aux_inv(rq->engine)) {
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
 
@@ -411,14 +434,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
*cs++ = 0; /* upper addr */
*cs++ = 0; /* value */
 
-   if (aux_inv) { /* hsdes: 1809175790 */
-   if (rq->engine->class == VIDEO_DECODE_CLASS)
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VD0_AUX_INV);
-   else
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VE0_AUX_INV);
-   }
+   cs = gen12_emit_aux_table_inv(rq->engine, cs);
 
if (mode & EMIT_INVALIDATE)
*cs++ = preparser_disable(false);
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index a44eda096557c..867ba697aceb8 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -13,6 +13,7 @@
 #include "intel_gt_regs.h"
 #include "intel_gpu_commands.h"
 
+struct intel_engine_cs;
 struct intel_gt;
 struct i915_request;
 
@@ -46,7 +47,7 @@ u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *rq, 
u32 *cs);
 u32 

[Intel-gfx] [PATCH v5 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

2023-07-18 Thread Andi Shyti
Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before
invalidation") has made sure that the memory is quiesced before
invalidating the AUX CCS table. Do it for all the other engines
and not just RCS.

Signed-off-by: Andi Shyti 
Cc: Jonathan Cavitt 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 71 +---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
 2 files changed, 62 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 3275e55b18d90..2f40cd515cc78 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -225,6 +225,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
 
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+
bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
@@ -309,20 +316,64 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
 int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
 {
intel_engine_mask_t aux_inv = 0;
-   u32 cmd, *cs;
+   u32 cmd = 4;
+   u32 *cs;
 
-   cmd = 4;
-   if (mode & EMIT_INVALIDATE) {
+   if (mode & EMIT_INVALIDATE)
cmd += 2;
 
-   if (HAS_AUX_CCS(rq->engine->i915) &&
-   (rq->engine->class == VIDEO_DECODE_CLASS ||
-rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
-   aux_inv = rq->engine->mask &
-   ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
-   if (aux_inv)
-   cmd += 4;
+   if (HAS_AUX_CCS(rq->engine->i915))
+   aux_inv = rq->engine->mask &
+ ~GENMASK(_BCS(I915_MAX_BCS - 1), BCS0);
+
+   /*
+* Aux invalidations on Aux CCS platforms require
+* memory traffic is quiesced prior.
+*/
+   if (aux_inv) {
+   u32 bit_group_0 = 0;
+   u32 bit_group_1 = 0;
+
+   cmd += 4;
+
+   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+
+   switch (rq->engine->class) {
+   case VIDEO_DECODE_CLASS:
+   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
+   bit_group_1 |= PIPE_CONTROL_CS_STALL;
+
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+
+   break;
+
+   case VIDEO_ENHANCEMENT_CLASS:
+   case COMPUTE_CLASS:
+   bit_group_1 |= MI_FLUSH_DW;
+
+   break;
+
+   case COPY_ENGINE_CLASS:
+   /*
+* When required, in MTL+ platforms we need to
+* set the CCS_FLUSH bit in the pipe control
+*/
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
+   break;
}
+
+   if (bit_group_1 || bit_group_0)
+   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+  LRC_PPHWSP_SCRATCH_ADDR);
}
 
cs = intel_ring_begin(rq, cmd);
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5d143e2a8db03..5df7cce23197c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -299,6 +299,7 @@
 #define   PIPE_CONTROL_QW_WRITE(1<<14)
 #define   PIPE_CONTROL_POST_SYNC_OP_MASK(3<<14)
 #define   PIPE_CONTROL_DEPTH_STALL (1<<13)
+#define   PIPE_CONTROL_CCS_FLUSH   (1<<13) /* MTL+ */
 #define   PIPE_CONTROL_WRITE_FLUSH (1<<12)
 #define   PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH   (1<<12) /* gen6+ */
 #define   PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE(1<<11) /* MBZ on ILK */
-- 

[Intel-gfx] [PATCH v5 8/9] drm/i915/gt: Poll aux invalidation register bit on invalidation

2023-07-18 Thread Andi Shyti
From: Jonathan Cavitt 

For platforms that use Aux CCS, wait for aux invalidation to
complete by checking the aux invalidation register bit is
cleared.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 17 -
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 2f40cd515cc78..029ef1a5d3b6a 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -172,7 +172,15 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
*cs, const i915_reg_t inv
*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
*cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
*cs++ = AUX_INV;
-   *cs++ = MI_NOOP;
+
+   *cs++ = MI_SEMAPHORE_WAIT_TOKEN |
+   MI_SEMAPHORE_REGISTER_POLL |
+   MI_SEMAPHORE_POLL |
+   MI_SEMAPHORE_SAD_EQ_SDD;
+   *cs++ = 0;
+   *cs++ = i915_mmio_reg_offset(inv_reg) + gsi_offset;
+   *cs++ = 0;
+   *cs++ = 0;
 
return cs;
 }
@@ -282,10 +290,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
+   count = 8;
if (HAS_AUX_CCS(rq->engine->i915))
-   count = 8 + 4;
-   else
-   count = 8;
+   count += 8;
 
cs = intel_ring_begin(rq, count);
if (IS_ERR(cs))
@@ -334,7 +341,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
 
-   cmd += 4;
+   cmd += 8;
 
bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 5df7cce23197c..2bd8d98d21102 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -121,6 +121,7 @@
 #define   MI_SEMAPHORE_TARGET(engine)  ((engine)<<15)
 #define MI_SEMAPHORE_WAIT  MI_INSTR(0x1c, 2) /* GEN8+ */
 #define MI_SEMAPHORE_WAIT_TOKENMI_INSTR(0x1c, 3) /* GEN12+ */
+#define   MI_SEMAPHORE_REGISTER_POLL   (1 << 16)
 #define   MI_SEMAPHORE_POLL(1 << 15)
 #define   MI_SEMAPHORE_SAD_GT_SDD  (0 << 12)
 #define   MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
-- 
2.40.1



[Intel-gfx] [PATCH v5 3/9] drm/i915: Add the has_aux_ccs device property

2023-07-18 Thread Andi Shyti
We always assumed that a device might either have AUX or FLAT
CCS, but this is an approximation that is not always true as it
requires some further per device checks.

Add the "has_aux_ccs" flag in the intel_device_info structure in
order to have a per device flag indicating of the AUX CCS.

Signed-off-by: Andi Shyti 
Cc: Matt Roper 
Cc: Jonathan Cavitt 
Cc:  # v5.8+
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 4 ++--
 drivers/gpu/drm/i915/i915_drv.h  | 1 +
 drivers/gpu/drm/i915/i915_pci.c  | 5 -
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 563efee055602..0d4d5e0407a2d 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -267,7 +267,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915))
+   if (HAS_AUX_CCS(rq->engine->i915))
count = 8 + 4;
else
count = 8;
@@ -307,7 +307,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE) {
cmd += 2;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915) &&
+   if (HAS_AUX_CCS(rq->engine->i915) &&
(rq->engine->class == VIDEO_DECODE_CLASS ||
 rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
aux_inv = rq->engine->mask &
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 682ef2b5c7d59..e9cc048b5727a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -848,6 +848,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  * stored in lmem to support the 3D and media compression formats.
  */
 #define HAS_FLAT_CCS(i915)   (INTEL_INFO(i915)->has_flat_ccs)
+#define HAS_AUX_CCS(i915)(INTEL_INFO(i915)->has_aux_ccs)
 
 #define HAS_GT_UC(i915)(INTEL_INFO(i915)->has_gt_uc)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fcacdc21643cf..c9ff1d11a9fce 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -643,7 +643,8 @@ static const struct intel_device_info jsl_info = {
TGL_CACHELEVEL, \
.has_global_mocs = 1, \
.has_pxp = 1, \
-   .max_pat_index = 3
+   .max_pat_index = 3, \
+   .has_aux_ccs = 1
 
 static const struct intel_device_info tgl_info = {
GEN12_FEATURES,
@@ -775,6 +776,7 @@ static const struct intel_device_info dg2_info = {
 
 static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
+   .has_aux_ccs = 1,
.require_force_probe = 1,
.tuning_thread_rr_after_dep = 1,
 };
@@ -827,6 +829,7 @@ static const struct intel_device_info mtl_info = {
.__runtime.media.ip.ver = 13,
PLATFORM(INTEL_METEORLAKE),
.extra_gt_list = xelpmp_extra_gt,
+   .has_aux_ccs = 1,
.has_flat_ccs = 0,
.has_gmd_id = 1,
.has_guc_deprivilege = 1,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index dbfe6443457b5..93485507506cc 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -151,6 +151,7 @@ enum intel_ppgtt_type {
func(has_reset_engine); \
func(has_3d_pipeline); \
func(has_4tile); \
+   func(has_aux_ccs); \
func(has_flat_ccs); \
func(has_global_mocs); \
func(has_gmd_id); \
-- 
2.40.1



[Intel-gfx] [PATCH v5 5/9] drm/i915/gt: Rename flags with bit_group_X according to the datasheet

2023-07-18 Thread Andi Shyti
In preparation of the next patch align with the datasheet (BSPEC
47112) with the naming of the pipe control set of flag values.
The variable "flags" in gen12_emit_flush_rcs() is applied as a
set of flags called Bit Group 1.

Define also the Bit Group 0 as bit_group_0 where currently only
PIPE_CONTROL0_HDC_PIPELINE_FLUSH bit is set.

Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Matt Roper 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 34 +---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 18 -
 2 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 6fd1f254b84a2..c9951bcf091a2 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -207,7 +207,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 * memory traffic is quiesced prior.
 */
if (mode & EMIT_FLUSH || HAS_AUX_CCS(engine->i915)) {
-   u32 flags = 0;
+   u32 bit_group_0 = 0;
+   u32 bit_group_1 = 0;
int err;
u32 *cs;
 
@@ -215,32 +216,33 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
mode)
if (err)
return err;
 
-   flags |= PIPE_CONTROL_TILE_CACHE_FLUSH;
-   flags |= PIPE_CONTROL_FLUSH_L3;
-   flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
-   flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+
+   bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
+   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
/* Wa_1409600907:tgl,adl-p */
-   flags |= PIPE_CONTROL_DEPTH_STALL;
-   flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
-   flags |= PIPE_CONTROL_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_STALL;
+   bit_group_1 |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+   bit_group_1 |= PIPE_CONTROL_FLUSH_ENABLE;
 
-   flags |= PIPE_CONTROL_STORE_DATA_INDEX;
-   flags |= PIPE_CONTROL_QW_WRITE;
+   bit_group_1 |= PIPE_CONTROL_STORE_DATA_INDEX;
+   bit_group_1 |= PIPE_CONTROL_QW_WRITE;
 
-   flags |= PIPE_CONTROL_CS_STALL;
+   bit_group_1 |= PIPE_CONTROL_CS_STALL;
 
if (!HAS_3D_PIPELINE(engine->i915))
-   flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
else if (engine->class == COMPUTE_CLASS)
-   flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   cs = gen12_emit_pipe_control(cs,
-PIPE_CONTROL0_HDC_PIPELINE_FLUSH,
-flags, LRC_PPHWSP_SCRATCH_ADDR);
+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
intel_ring_advance(rq, cs);
}
 
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index 655e5c00ddc27..a44eda096557c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -49,25 +49,29 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs);
 u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 *cs, const i915_reg_t 
inv_reg);
 
 static inline u32 *
-__gen8_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, u32 offset)
+__gen8_emit_pipe_control(u32 *batch, u32 bit_group_0,
+u32 bit_group_1, u32 offset)
 {
memset(batch, 0, 6 * sizeof(u32));
 
-   batch[0] = GFX_OP_PIPE_CONTROL(6) | flags0;
-   batch[1] = flags1;
+   batch[0] = GFX_OP_PIPE_CONTROL(6) | bit_group_0;
+   batch[1] = bit_group_1;
batch[2] = offset;
 
return batch + 6;
 }
 
-static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset)
+static inline u32 *gen8_emit_pipe_control(u32 *batch,
+ u32 bit_group_1, u32 offset)
 {
-   return __gen8_emit_pipe_control(batch, 0, flags, offset);
+   return __gen8_emit_pipe_control(batch, 0, bit_group_1, offset);
 }
 
-static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1, 
u32 offset)
+static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 bit_group_0,
+  u32 

[Intel-gfx] [PATCH v5 4/9] drm/i915/gt: Ensure memory quiesced before invalidation

2023-07-18 Thread Andi Shyti
From: Jonathan Cavitt 

All memory traffic must be quiesced before requesting
an aux invalidation on platforms that use Aux CCS.

Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 0d4d5e0407a2d..6fd1f254b84a2 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -202,7 +202,11 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 {
struct intel_engine_cs *engine = rq->engine;
 
-   if (mode & EMIT_FLUSH) {
+   /*
+* Aux invalidations on Aux CCS platforms require
+* memory traffic is quiesced prior.
+*/
+   if (mode & EMIT_FLUSH || HAS_AUX_CCS(engine->i915)) {
u32 flags = 0;
int err;
u32 *cs;
-- 
2.40.1



[Intel-gfx] [PATCH v5 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

2023-07-18 Thread Andi Shyti
Just a trivial refactoring for reducing the number of code
duplicate. This will come at handy in the next commits.

Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 44 +---
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index c9951bcf091a2..3275e55b18d90 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -177,23 +177,31 @@ u32 *gen12_emit_aux_table_inv(struct intel_gt *gt, u32 
*cs, const i915_reg_t inv
return cs;
 }
 
+static u32 *intel_emit_pipe_control_cs(struct i915_request *rq, u32 
bit_group_0,
+  u32 bit_group_1, u32 offset)
+{
+   u32 *cs;
+
+   cs = intel_ring_begin(rq, 6);
+   if (IS_ERR(cs))
+   return cs;
+
+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
+LRC_PPHWSP_SCRATCH_ADDR);
+   intel_ring_advance(rq, cs);
+
+   return cs;
+}
+
 static int mtl_dummy_pipe_control(struct i915_request *rq)
 {
/* Wa_14016712196 */
if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) ||
-   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) {
-   u32 *cs;
-
-   /* dummy PIPE_CONTROL + depth flush */
-   cs = intel_ring_begin(rq, 6);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
-   cs = gen12_emit_pipe_control(cs,
-0,
-PIPE_CONTROL_DEPTH_CACHE_FLUSH,
-LRC_PPHWSP_SCRATCH_ADDR);
-   intel_ring_advance(rq, cs);
-   }
+   IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0))
+   intel_emit_pipe_control_cs(rq,
+  0,
+  PIPE_CONTROL_DEPTH_CACHE_FLUSH,
+  LRC_PPHWSP_SCRATCH_ADDR);
 
return 0;
 }
@@ -210,7 +218,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
int err;
-   u32 *cs;
 
err = mtl_dummy_pipe_control(rq);
if (err)
@@ -237,13 +244,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
else if (engine->class == COMPUTE_CLASS)
bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
 
-   cs = intel_ring_begin(rq, 6);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
-
-   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
-LRC_PPHWSP_SCRATCH_ADDR);
-   intel_ring_advance(rq, cs);
+   intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
+  LRC_PPHWSP_SCRATCH_ADDR);
}
 
if (mode & EMIT_INVALIDATE) {
-- 
2.40.1



[Intel-gfx] [PATCH v5 2/9] drm/i915/gt: Cleanup aux invalidation registers

2023-07-18 Thread Andi Shyti
Fix the 'NV' definition postfix that is supposed to be INV.

Take the chance to also order properly the registers based on
their address and call the GEN12_GFX_CCS_AUX_INV address as
GEN12_CCS_AUX_INV like all the other similar registers.

Remove also VD1, VD3 and VE1 registers that don't exist and add
BCS0 and CCS0.

Signed-off-by: Andi Shyti 
Cc:  # v5.8+
Reviewed-by: Nirmoy Das 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c |  8 
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  | 16 
 drivers/gpu/drm/i915/gt/intel_lrc.c  |  6 +++---
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 23857cc08eca1..563efee055602 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -287,8 +287,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
if (!HAS_FLAT_CCS(rq->engine->i915)) {
/* hsdes: 1809175790 */
-   cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_GFX_CCS_AUX_NV);
+   cs = gen12_emit_aux_table_inv(rq->engine->gt, cs,
+ GEN12_CCS_AUX_INV);
}
 
*cs++ = preparser_disable(false);
@@ -348,10 +348,10 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
if (aux_inv) { /* hsdes: 1809175790 */
if (rq->engine->class == VIDEO_DECODE_CLASS)
cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VD0_AUX_NV);
+ cs, GEN12_VD0_AUX_INV);
else
cs = gen12_emit_aux_table_inv(rq->engine->gt,
- cs, GEN12_VE0_AUX_NV);
+ cs, GEN12_VE0_AUX_INV);
}
 
if (mode & EMIT_INVALIDATE)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 718cb2c80f79e..2cdfb2f713d02 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -332,9 +332,11 @@
 #define GEN8_PRIVATE_PAT_HI_MMIO(0x40e0 + 4)
 #define GEN10_PAT_INDEX(index) _MMIO(0x40e0 + (index) * 4)
 #define BSD_HWS_PGA_GEN7   _MMIO(0x4180)
-#define GEN12_GFX_CCS_AUX_NV   _MMIO(0x4208)
-#define GEN12_VD0_AUX_NV   _MMIO(0x4218)
-#define GEN12_VD1_AUX_NV   _MMIO(0x4228)
+
+#define GEN12_CCS_AUX_INV  _MMIO(0x4208)
+#define GEN12_VD0_AUX_INV  _MMIO(0x4218)
+#define GEN12_VE0_AUX_INV  _MMIO(0x4238)
+#define GEN12_BCS0_AUX_INV _MMIO(0x4248)
 
 #define GEN8_RTCR  _MMIO(0x4260)
 #define GEN8_M1TCR _MMIO(0x4264)
@@ -342,14 +344,12 @@
 #define GEN8_BTCR  _MMIO(0x426c)
 #define GEN8_VTCR  _MMIO(0x4270)
 
-#define GEN12_VD2_AUX_NV   _MMIO(0x4298)
-#define GEN12_VD3_AUX_NV   _MMIO(0x42a8)
-#define GEN12_VE0_AUX_NV   _MMIO(0x4238)
-
 #define BLT_HWS_PGA_GEN7   _MMIO(0x4280)
 
-#define GEN12_VE1_AUX_NV   _MMIO(0x42b8)
+#define GEN12_VD2_AUX_INV  _MMIO(0x4298)
+#define GEN12_CCS0_AUX_INV _MMIO(0x42c8)
 #define   AUX_INV  REG_BIT(0)
+
 #define VEBOX_HWS_PGA_GEN7 _MMIO(0x4380)
 
 #define GEN12_AUX_ERR_DBG  _MMIO(0x43f4)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1b710102390bf..235f3fab60a98 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1374,7 +1374,7 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context 
*ce, u32 *cs)
/* hsdes: 1809175790 */
if (!HAS_FLAT_CCS(ce->engine->i915))
cs = gen12_emit_aux_table_inv(ce->engine->gt,
- cs, GEN12_GFX_CCS_AUX_NV);
+ cs, GEN12_CCS_AUX_INV);
 
/* Wa_16014892111 */
if (IS_MTL_GRAPHICS_STEP(ce->engine->i915, M, STEP_A0, STEP_B0) ||
@@ -1403,10 +1403,10 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context 
*ce, u32 *cs)
if (!HAS_FLAT_CCS(ce->engine->i915)) {
if (ce->engine->class == VIDEO_DECODE_CLASS)
cs = gen12_emit_aux_table_inv(ce->engine->gt,
- cs, GEN12_VD0_AUX_NV);
+   

[Intel-gfx] [PATCH v5 1/9] drm-tip: 2023y-07m-17d-16h-04m-53s UTC integration manifest

2023-07-18 Thread Andi Shyti
From: Robert Foss 

---
 integration-manifest | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 integration-manifest

diff --git a/integration-manifest b/integration-manifest
new file mode 100644
index 0..8642016b34817
--- /dev/null
+++ b/integration-manifest
@@ -0,0 +1,24 @@
+drm drm-fixes 38d88d5e97c9032ebeca092b9372209f2ca92cdf
+   Merge tag 'amd-drm-fixes-6.5-2023-07-12' of 
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
+drm-misc drm-misc-fixes 05abb3be91d8788328231ee02973ab3d47f5e3d2
+   dma-buf/dma-resv: Stop leaking on krealloc() failure
+drm-intel drm-intel-fixes fdf0eaf11452d72945af31804e2a1048ee1b574c
+   Linux 6.5-rc2
+drm drm-next 6c7f27441d6af776a89147027c6f4a11c0162c64
+   Merge tag 'drm-misc-next-2023-07-13' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next
+drm-misc drm-misc-next-fixes 59bba51ec2a50e3dc5c3ee80f0a23207346303ff
+   drm/panel: Fine tune Starry-ili9882t panel HFP and HBP
+drm-intel drm-intel-next-fixes f6cf3883df471abbcf1553127681dc244c8ff8dd
+   drm/i915: use mock device info for creating mock device
+drm-misc drm-misc-next 41639b3a8b0f1f194dfe0577d99db70613f78626
+   drm/bridge: anx7625: Use common macros for HDCP capabilities
+drm-intel drm-intel-next c5741c5c1122b7944d9af185c83ab7056153259e
+   drm/i915/display: Do not use stolen on MTL
+drm-intel drm-intel-gt-next 8529e3777b7644d41105a06141574a24795f8348
+   drm/i915/gt: Do not use stolen on MTL
+drm-intel topic/core-for-CI c0ea2fa0491287dea97b384bec1b5a614408b8e3
+   drm/i915/gsc: define gsc fw
+drm-misc topic/i915-ttm 1e3944578b749449bd7fa6bf0bae4c3d3f5f1733
+   Merge tag 'amd-drm-next-5.16-2021-09-27' of 
https://gitlab.freedesktop.org/agd5f/linux into drm-next
+drm topic/nouveau-misc dfc4005f8c172eea359f9db08c3b2b0ff0153699
+   drm/nouveau/disp: move DAC load detection method
-- 
2.40.1



[Intel-gfx] [PATCH v5 0/9] Update AUX invalidation sequence

2023-07-18 Thread Andi Shyti
Hi,

as there are new hardware directives, we need a little adaptation
for the AUX invalidation sequence.

In this version we support all the engines affected by this
change.

The stable backport has some challenges because the original
patch that this series fixes has had more changes in between.

This patch is slowly exploding with code refactorings and
features added and fixed.

Thanks a lot Nirmoy, Andrzej and Matt for your review and for the
fruitful discussions!

Thanks,
Andi

Changelog:
=
v4 -> v5
 - The AUX CCS is added as a device property instead of checking
   against FLAT CCS. This adds the new HAS_AUX_CCS check
   (Patch 2, new).
 - little and trivial refactoring here and there.
 - extended the flags{0,1}/bit_group_{0,1} renaming to other
   functions.
 - Created an intel_emit_pipe_control_cs() wrapper for submitting
   the pipe control.
 - Quiesce memory for all the engines, not just RCS (Patch 6,
   new).
 - The PIPE_CONTROL_CCS_FLUSH is added to all the engines.
 - Remove redundant EMIT_FLUSH_CCS mode flag.
 - Remove unnecessary NOOPs from the command streamer for
   invalidating the CCS table.
 - Use INVALID_MMIO_REG and gen12_get_aux_inv_reg() instad of
   __MMIO(0) and reg.reg.
 - Remove useless wrapper and just use gen12_get_aux_inv_reg().

v3 -> v4
 - A trivial patch 3 is added to rename the flags with
   bit_group_{0,1} to align with the datasheet naming.
 - Patch 4 fixes a confusion I made where the CCS flag was
   applied to the wrong bit group.

v2 -> v3
 - added r-b from Nirmoy in patch 1 and 4.
 - added patch 3 which enables the ccs_flush in the control pipe
   for mtl+ compute and render engines.
 - added redundant checks in patch 2 for enabling the EMIT_FLUSH
   flag.

v1 -> v2
 - add a clean up preliminary patch for the existing registers
 - add support for more engines
 - add the Fixes tag

Andi Shyti (6):
  drm/i915/gt: Cleanup aux invalidation registers
  drm/i915: Add the has_aux_ccs device property
  drm/i915/gt: Rename flags with bit_group_X according to the datasheet
  drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single
function
  drm/i915/gt: Ensure memory quiesced before invalidation for all
engines
  drm/i915/gt: Support aux invalidation on all engines

Jonathan Cavitt (2):
  drm/i915/gt: Ensure memory quiesced before invalidation
  drm/i915/gt: Poll aux invalidation register bit on invalidation

Robert Foss (1):
  drm-tip: 2023y-07m-17d-16h-04m-53s UTC integration manifest

 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 216 +--
 drivers/gpu/drm/i915/gt/gen8_engine_cs.h |  21 +-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   2 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  16 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  |  17 +-
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/i915_pci.c  |   5 +-
 drivers/gpu/drm/i915/intel_device_info.h |   1 +
 integration-manifest |  24 +++
 9 files changed, 204 insertions(+), 99 deletions(-)
 create mode 100644 integration-manifest

-- 
2.40.1



Re: [Intel-gfx] [PATCH] drm/i915: Fix an error handling path in igt_write_huge()

2023-07-18 Thread Andrzej Hajda

On 17.07.2023 20:49, Christophe JAILLET wrote:

All error handling paths go to 'out', except this one. Be consistent and
also branch to 'out' here.

Fixes: c10a652e239e ("drm/i915/selftests: Rework context handling in hugepages 
selftests")
Signed-off-by: Christophe JAILLET 



For me seems correct.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej



---
/!\ Speculative /!\

This patch is based on analysis of the surrounding code and should be
reviewed with care !

If the patch is wrong, maybe a comment in the code could explain why.

/!\ Speculative /!\
---
  drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index df6c9a84252c..6b9f6cf50bf6 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1246,8 +1246,10 @@ static int igt_write_huge(struct drm_i915_private *i915,
 * times in succession a possibility by enlarging the permutation array.
 */
order = i915_random_order(count * count, );
-   if (!order)
-   return -ENOMEM;
+   if (!order) {
+   err = -ENOMEM;
+   goto out;
+   }
  
  	max_page_size = rounddown_pow_of_two(obj->mm.page_sizes.sg);

max = div_u64(max - size, max_page_size);




Re: [Intel-gfx] [v2 14/15] drm/i915/adls: s/ADLS/ALDERLAKE_S in platform and subplatform defines

2023-07-18 Thread Lucas De Marchi

On Tue, Jul 18, 2023 at 11:53:17AM +0100, Tvrtko Ursulin wrote:


On 18/07/2023 09:11, Dnyaneshwar Bhadane wrote:

From: Anusha Srivatsa 

Driver refers to the platform Alderlake S as ADLS in places
and ALDERLAKE_S in some. Making the consistent change
to avoid confusion of the right naming convention for
the platform.

v2:
- Unrolled wrapper IS_ADLS_GRAPHICS_STEP and Replace
with IS_ALDERLAKE_S() && IS_GRAPHICS_STEP() (Jani/Tvrtko).

Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_display_device.c | 2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c   | 2 +-
 drivers/gpu/drm/i915/i915_drv.h | 6 +++---
 drivers/gpu/drm/i915/intel_step.c   | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c 
b/drivers/gpu/drm/i915/display/intel_display_device.c
index 3fd30e7f0062..252dd8446410 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.c
+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
@@ -797,7 +797,7 @@ void intel_display_device_info_runtime_init(struct 
drm_i915_private *i915)
enum pipe pipe;
/* Wa_14011765242: adl-s A0,A1 */
-   if (IS_ADLS_DISPLAY_STEP(i915, STEP_A0, STEP_A2))
+   if (IS_ALDERLAKE_S(i915) && IS_DISPLAY_STEP(i915, STEP_A0, STEP_A2))
for_each_pipe(i915, pipe)
display_runtime->num_scalers[pipe] = 0;
else if (DISPLAY_VER(i915) >= 11) {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 18250fb64bd8..eb28705b88bd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -43,7 +43,7 @@ static void uc_expand_default_options(struct intel_uc *uc)
}
/* Intermediate platforms are HuC authentication only */
-   if (IS_ALDERLAKE_S(i915) && !IS_ADLS_RPLS(i915)) {
+   if (IS_ALDERLAKE_S(i915) && !IS_ALDERLAKE_S_RPLS(i915)) {
i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
return;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 942004afdd2f..e15471bbad5a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -585,7 +585,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G11)
 #define IS_DG2_G12(i915) \
IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G12)
-#define IS_ADLS_RPLS(i915) \
+#define IS_ALDERLAKE_S_RPLS(i915) \


I don't know what we should/could do with these Alderlake macros.. I 
mean all three of:


IS_ALDERLAKE_S_RPLS
IS_ALDERLAKE_P_RPLP
IS_ALDERLAKE_RPLU

It becomes too long to expand the TLA suffix..

Is there scope to turn this around and simplify in code like:

 IS_RAPTORLAKE_S/P/U ?

Not sure at all, just throwing out wild ideas.. There aren't many call 
sites for those three but despite that I don't see any easy cheats to 
tidy it.


I agree. I think "promoting" it like you mention is great and avoids the
super long macro. IS_ADLS_RPLS() was already ambiguous if you don't know
rpl is treated as a subplatform (is it ADLS || RPLS?). That's kind of
different than the DG2 case since there isn't a G10/G11/G12 platform by
itself.


thanks
Lucas De Marchi



Regards,

Tvrtko


IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_S, INTEL_SUBPLATFORM_RPL)
 #define IS_ALDERLAKE_P_N(i915) \
IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P, INTEL_SUBPLATFORM_N)
@@ -664,11 +664,11 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 IS_DISPLAY_STEP(__i915, since, until))
-#define IS_ADLS_DISPLAY_STEP(__i915, since, until) \
+#define IS_ALDERLAKE_S_DISPLAY_STEP(__i915, since, until) \
(IS_ALDERLAKE_S(__i915) && \
 IS_DISPLAY_STEP(__i915, since, until))
-#define IS_ADLS_GRAPHICS_STEP(__i915, since, until) \
+#define IS_ALDERLAKE_GRAPHICS_STEP(__i915, since, until) \
(IS_ALDERLAKE_S(__i915) && \
 IS_GRAPHICS_STEP(__i915, since, until))
diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index 545102d14ba4..5904aa5640e1 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -201,7 +201,7 @@ void intel_step_init(struct drm_i915_private *i915)
} else if (IS_ALDERLAKE_P(i915)) {
revids = adlp_revids;
size = ARRAY_SIZE(adlp_revids);
-   } else if (IS_ADLS_RPLS(i915)) {
+   } else if (IS_ALDERLAKE_S_RPLS(i915)) {
revids = adls_rpls_revids;
size = ARRAY_SIZE(adls_rpls_revids);
} else if (IS_ALDERLAKE_S(i915)) {


[Intel-gfx] ✓ Fi.CI.BAT: success for Enhance vfio PCI hot reset for vfio cdev device (rev10)

2023-07-18 Thread Patchwork
== Series Details ==

Series: Enhance vfio PCI hot reset for vfio cdev device (rev10)
URL   : https://patchwork.freedesktop.org/series/116991/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13393 -> Patchwork_116991v10


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/index.html

Participating hosts (44 -> 42)
--

  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_116991v10 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-9: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-adlp-9/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-adlp-11/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-1115g4:  [PASS][4] -> [FAIL][5] ([i915#7940])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/fi-tgl-1115g4/igt@i915_pm_...@basic-pci-d3-state.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/fi-tgl-1115g4/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@basic-rte:
- fi-skl-guc: [PASS][6] -> [FAIL][7] ([i915#7940]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/fi-skl-guc/igt@i915_pm_...@basic-rte.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/fi-skl-guc/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rps@basic-api:
- bat-adlp-9: NOTRUN -> [SKIP][8] ([i915#6621])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-adlp-9/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][9] -> [ABORT][10] ([i915#7911] / [i915#7913])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@guc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][11] ([i915#7852])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@migrate:
- bat-mtlp-8: [PASS][12] -> [DMESG-FAIL][13] ([i915#7699])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/bat-mtlp-8/igt@i915_selftest@l...@migrate.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-mtlp-8/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][14] -> [ABORT][15] ([i915#4983] / [i915#7461] 
/ [i915#8347] / [i915#8384])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13393/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-6: NOTRUN -> [SKIP][16] ([i915#6645])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-mtlp-6/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- bat-adlp-11:NOTRUN -> [SKIP][17] ([i915#7828]) +7 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-adlp-11/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-adlp-9: NOTRUN -> [SKIP][18] ([i915#7828])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-adlp-9/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-mtlp-6: NOTRUN -> [SKIP][19] ([i915#7828])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-mtlp-6/igt@kms_chamelium_...@common-hpd-after-suspend.html
- bat-rpls-2: NOTRUN -> [SKIP][20] ([i915#7828])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-11:NOTRUN -> [SKIP][21] ([i915#4103]) +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116991v10/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@prune-stale-modes:

Re: [Intel-gfx] [PATCH] drm/i915/tv: avoid possible division by zero

2023-07-18 Thread Andrzej Hajda




On 18.07.2023 12:10, Su Hui wrote:

On 2023/7/18 13:39, Dan Carpenter wrote:

On Mon, Jul 17, 2023 at 04:52:51PM +0200, Andrzej Hajda wrote:


On 17.07.2023 08:22, Su Hui wrote:

Clang warning: drivers/gpu/drm/i915/display/intel_tv.c:
line 991, column 22 Division by zero.
Assuming tv_mode->oversample=1 and (!tv_mode->progressive)=1,
then division by zero will happen.

Fixes: 1bba5543e4fe ("drm/i915: Fix TV encoder clock computation")
Signed-off-by: Su Hui 
---
   drivers/gpu/drm/i915/display/intel_tv.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tv.c 
b/drivers/gpu/drm/i915/display/intel_tv.c

index 36b479b46b60..82b54af51f23 100644
--- a/drivers/gpu/drm/i915/display/intel_tv.c
+++ b/drivers/gpu/drm/i915/display/intel_tv.c
@@ -988,7 +988,8 @@ intel_tv_mode_to_mode(struct drm_display_mode 
*mode,

 const struct tv_mode *tv_mode,
 int clock)
   {
-    mode->clock = clock / (tv_mode->oversample >> 
!tv_mode->progressive);

+    mode->clock = clock / (tv_mode->oversample != 1 ?
+    tv_mode->oversample >> !tv_mode->progressive : 1);

Seems too smart to me, why not just:
mode->clock = clock / tv_mode->oversample;
if (!tv_mode->progressive)
 mode->clock <<= 1;

This is nice.


mode->clock = clock / tv_mode->oversample << !tv_mode->progressive;

But I think this one is much better,  it has less code and run faster.
Should I resend v3 to add some explanation or follow Dan's advice?


Speed gain here is irrelevant here, and disputable.

One thing which could be problematic is that we could loose the least 
significant bit in mode->clock,
in case non-progressive, but I am not sure if it really matters, as 
mode->clock is not precise value anyway.
Alternatively we could 1st shift, then divide, but in this case overflow 
can occur, at least in theory - I suspect there are no such big clocks 
(in kHz).


Finally I would agree with Dan, readability is better with conditional.

Regards
Andrzej



Su Hui


regards,
dan carpenter




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enhance vfio PCI hot reset for vfio cdev device (rev10)

2023-07-18 Thread Patchwork
== Series Details ==

Series: Enhance vfio PCI hot reset for vfio cdev device (rev10)
URL   : https://patchwork.freedesktop.org/series/116991/
State : warning

== Summary ==

Error: dim checkpatch failed
7a4aaa443b7a vfio/pci: Update comment around group_fd get in 
vfio_pci_ioctl_pci_hot_reset()
65975a376988 vfio/pci: Move the existing hot reset logic to be a helper
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#6: 
This prepares to add another method for hot reset. The major hot reset logic

total: 0 errors, 1 warnings, 0 checks, 99 lines checked
3b0915db2889 iommufd: Reserve all negative IDs in the iommufd xarray
46920e53d4d4 iommufd: Add iommufd_ctx_has_group()
ef78cfe7dd6c iommufd: Add helper to retrieve iommufd_ctx and devid
f8e653236125 vfio: Mark cdev usage in vfio_device
-:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#8: 
cdev path yet, so the vfio_device_cdev_opened() helper always returns false.

total: 0 errors, 1 warnings, 0 checks, 11 lines checked
16f20b24151e vfio: Add helper to search vfio_device in a dev_set
f6cfba828e30 vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio 
device cdev
88350a705281 vfio/pci: Copy hot-reset device info to userspace in the devices 
loop
392ee2f33799 vfio/pci: Allow passing zero-length fd array in 
VFIO_DEVICE_PCI_HOT_RESET




[Intel-gfx] [PATCH v10 10/10] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

2023-07-18 Thread Yi Liu
This is the way user to invoke hot-reset for the devices opened by cdev
interface. User should check the flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID_OWNED
in the output of VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl before doing
hot-reset for cdev devices.

Suggested-by: Jason Gunthorpe 
Reviewed-by: Jason Gunthorpe 
Tested-by: Yanting Jiang 
Tested-by: Zhenzhong Duan 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Yi Liu 
---
 drivers/vfio/pci/vfio_pci_core.c | 61 ++--
 include/uapi/linux/vfio.h| 21 +++
 2 files changed, 71 insertions(+), 11 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index f4a0ea01559e..65cbada3ec13 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -181,7 +181,8 @@ static void vfio_pci_probe_mmaps(struct 
vfio_pci_core_device *vdev)
 struct vfio_pci_group_info;
 static void vfio_pci_dev_set_try_reset(struct vfio_device_set *dev_set);
 static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
- struct vfio_pci_group_info *groups);
+ struct vfio_pci_group_info *groups,
+ struct iommufd_ctx *iommufd_ctx);
 
 /*
  * INTx masking requires the ability to disable INTx signaling via PCI_COMMAND
@@ -1329,8 +1330,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct 
vfio_pci_core_device *vdev,
if (ret)
return ret;
 
-   /* Somewhere between 1 and count is OK */
-   if (!array_count || array_count > count)
+   if (array_count > count)
return -EINVAL;
 
group_fds = kcalloc(array_count, sizeof(*group_fds), GFP_KERNEL);
@@ -1379,7 +1379,7 @@ vfio_pci_ioctl_pci_hot_reset_groups(struct 
vfio_pci_core_device *vdev,
info.count = array_count;
info.files = files;
 
-   ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, );
+   ret = vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, , NULL);
 
 hot_reset_release:
for (file_idx--; file_idx >= 0; file_idx--)
@@ -1402,13 +1402,21 @@ static int vfio_pci_ioctl_pci_hot_reset(struct 
vfio_pci_core_device *vdev,
if (hdr.argsz < minsz || hdr.flags)
return -EINVAL;
 
+   /* zero-length array is only for cdev opened devices */
+   if (!!hdr.count == vfio_device_cdev_opened(>vdev))
+   return -EINVAL;
+
/* Can we do a slot or bus reset or neither? */
if (!pci_probe_reset_slot(vdev->pdev->slot))
slot = true;
else if (pci_probe_reset_bus(vdev->pdev->bus))
return -ENODEV;
 
-   return vfio_pci_ioctl_pci_hot_reset_groups(vdev, hdr.count, slot, arg);
+   if (hdr.count)
+   return vfio_pci_ioctl_pci_hot_reset_groups(vdev, hdr.count, 
slot, arg);
+
+   return vfio_pci_dev_set_hot_reset(vdev->vdev.dev_set, NULL,
+ 
vfio_iommufd_device_ictx(>vdev));
 }
 
 static int vfio_pci_ioctl_ioeventfd(struct vfio_pci_core_device *vdev,
@@ -2376,13 +2384,16 @@ const struct pci_error_handlers 
vfio_pci_core_err_handlers = {
 };
 EXPORT_SYMBOL_GPL(vfio_pci_core_err_handlers);
 
-static bool vfio_dev_in_groups(struct vfio_pci_core_device *vdev,
+static bool vfio_dev_in_groups(struct vfio_device *vdev,
   struct vfio_pci_group_info *groups)
 {
unsigned int i;
 
+   if (!groups)
+   return false;
+
for (i = 0; i < groups->count; i++)
-   if (vfio_file_has_dev(groups->files[i], >vdev))
+   if (vfio_file_has_dev(groups->files[i], vdev))
return true;
return false;
 }
@@ -2458,7 +2469,8 @@ static int vfio_pci_dev_set_pm_runtime_get(struct 
vfio_device_set *dev_set)
  * get each memory_lock.
  */
 static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
- struct vfio_pci_group_info *groups)
+ struct vfio_pci_group_info *groups,
+ struct iommufd_ctx *iommufd_ctx)
 {
struct vfio_pci_core_device *cur_mem;
struct vfio_pci_core_device *cur_vma;
@@ -2488,11 +2500,38 @@ static int vfio_pci_dev_set_hot_reset(struct 
vfio_device_set *dev_set,
goto err_unlock;
 
list_for_each_entry(cur_vma, _set->device_list, vdev.dev_set_list) {
+   bool owned;
+
/*
-* Test whether all the affected devices are contained by the
-* set of groups provided by the user.
+* Test whether all the affected devices can be reset by the
+* user.
+*
+* If called from a group opened device and the user provides
+* a set of groups, all the devices in the dev_set should be
+* contained by the set of groups provided by the user.
+

[Intel-gfx] [PATCH v10 07/10] vfio: Add helper to search vfio_device in a dev_set

2023-07-18 Thread Yi Liu
There are drivers that need to search vfio_device within a given dev_set.
e.g. vfio-pci. So add a helper.

vfio_pci_is_device_in_set() now returns -EBUSY in commit a882c16a2b7e
("vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set") where
it was trying to preserve the return of vfio_pci_try_zap_and_vma_lock_cb().
However, it makes more sense to return -ENODEV.

Suggested-by: Alex Williamson 
Reviewed-by: Jason Gunthorpe 
Tested-by: Yanting Jiang 
Tested-by: Terrence Xu 
Tested-by: Zhenzhong Duan 
Signed-off-by: Yi Liu 
---
 drivers/vfio/pci/vfio_pci_core.c |  6 +-
 drivers/vfio/vfio_main.c | 15 +++
 include/linux/vfio.h |  3 +++
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 3d595ad2ed0a..5b5316a5484a 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -2377,12 +2377,8 @@ static bool vfio_dev_in_groups(struct 
vfio_pci_core_device *vdev,
 static int vfio_pci_is_device_in_set(struct pci_dev *pdev, void *data)
 {
struct vfio_device_set *dev_set = data;
-   struct vfio_device *cur;
 
-   list_for_each_entry(cur, _set->device_list, dev_set_list)
-   if (cur->dev == >dev)
-   return 0;
-   return -EBUSY;
+   return vfio_find_device_in_devset(dev_set, >dev) ? 0 : -ENODEV;
 }
 
 /*
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index f0ca33b2e1df..ab4f3a794f78 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -141,6 +141,21 @@ unsigned int vfio_device_set_open_count(struct 
vfio_device_set *dev_set)
 }
 EXPORT_SYMBOL_GPL(vfio_device_set_open_count);
 
+struct vfio_device *
+vfio_find_device_in_devset(struct vfio_device_set *dev_set,
+  struct device *dev)
+{
+   struct vfio_device *cur;
+
+   lockdep_assert_held(_set->lock);
+
+   list_for_each_entry(cur, _set->device_list, dev_set_list)
+   if (cur->dev == dev)
+   return cur;
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(vfio_find_device_in_devset);
+
 /*
  * Device objects - create, release, get, put, search
  */
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 2a45853773a6..ee120d2d530b 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -244,6 +244,9 @@ void vfio_unregister_group_dev(struct vfio_device *device);
 
 int vfio_assign_device_set(struct vfio_device *device, void *set_id);
 unsigned int vfio_device_set_open_count(struct vfio_device_set *dev_set);
+struct vfio_device *
+vfio_find_device_in_devset(struct vfio_device_set *dev_set,
+  struct device *dev);
 
 int vfio_mig_get_next_state(struct vfio_device *device,
enum vfio_device_mig_state cur_fsm,
-- 
2.34.1



  1   2   >