Re: [Intel-gfx] refactor the i915 GVT support and move to the modern mdev API v3

[Christoph Hellwig]

On Thu, Apr 14, 2022 at 11:38:59AM -0300, Jason Gunthorpe wrote:
> pull requests can flow through more than one tree concurrently. The
> purpose of the topic branch is to allow all the commits to be in all
> the trees they need to be in at once.
> 
> So you should send this branch as a PR to the next logical upstream
> tree gvt patches normally go through, in the usual way that you send
> PRs. Especially in this case where there is a small merge conflict
> internal to DRM to resolve. I'm assuming this is the drm-intel-next
> tree?
> 
> Once DRM is internally happy then VFIO can merge it as well. You can
> view VFIO as the secondary path to Linus, DRM as primary. Alex will
> mention in his pull request that VFIO has a 'shared branch with DRM
> for gvt'.

Where do we stand here?  The (somewhat misnamed) topic/for-christoph
branch looks fine to me now except for the mіssing "static inline" on
the intel_gvt_iterate_mmio_table stub.

When can we expect it in the i915 tree and linux-next?

Re: [Intel-gfx] refactor the i915 GVT support and move to the modern mdev API v3

[Wang, Zhi A]

On 4/20/22 7:08 AM, Christoph Hellwig wrote:
> On Thu, Apr 14, 2022 at 11:38:59AM -0300, Jason Gunthorpe wrote:
>> pull requests can flow through more than one tree concurrently. The
>> purpose of the topic branch is to allow all the commits to be in all
>> the trees they need to be in at once.
>>
>> So you should send this branch as a PR to the next logical upstream
>> tree gvt patches normally go through, in the usual way that you send
>> PRs. Especially in this case where there is a small merge conflict
>> internal to DRM to resolve. I'm assuming this is the drm-intel-next
>> tree?
>>
>> Once DRM is internally happy then VFIO can merge it as well. You can
>> view VFIO as the secondary path to Linus, DRM as primary. Alex will
>> mention in his pull request that VFIO has a 'shared branch with DRM
>> for gvt'.
> 
> Where do we stand here?  The (somewhat misnamed) topic/for-christoph
> branch looks fine to me now except for the mіssing "static inline" on
> the intel_gvt_iterate_mmio_table stub.
> 
> When can we expect it in the i915 tree and linux-next?
> 
Qur QA finished the test yesterday and I just made a tag. The pull
request is going to be sent today. Yes, I will fix that.

Thanks,
Zhi.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/102665/
State : warning

== Summary ==

Error: dim checkpatch failed
2993d1f47961 drm/i915: Introduce has_media_ratio_mode
bce07f6f7b01 drm/i915/gt: Add media freq factor to per-gt sysfs
98c49b8e21f0 drm/i915/pcode: Extend pcode functions for multiple gt's
f8fab08799a7 drm/i915/gt: Convert callers to user per-gt pcode functions
6bd0711a3b41 drm/i915/pcode: Add a couple of pcode helpers
c05fb6b721be drm/i915/gt: Add media RP0/RPn to per-gt sysfs
-:80: CHECK:CAMELCASE: Avoid CamelCase: 
#80: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:719:
+static DEVICE_ATTR_RO(media_RPn_freq_mhz);

-:86: CHECK:CAMELCASE: Avoid CamelCase: 
#86: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:725:
+   &dev_attr_media_RPn_freq_mhz.attr,

total: 0 errors, 0 warnings, 2 checks, 87 lines checked
5baf8f9db7ad drm/i915/gt: Fix memory leaks in per-gt sysfs
02c0e57e2478 drm/i915/gt: Expose per-gt RPS defaults in sysfs
acef7774effa drm/i915/gt: Expose default value for media_freq_factor in per-gt 
sysfs

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/102665/
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.BAT: failure for drm/i915: Media freq factor and per-gt enhancements/fixes (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/102665/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11523 -> Patchwork_102665v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102665v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102665v2, 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_102665v2/index.html

Participating hosts (47 -> 45)
--

  Additional (3): bat-adlm-1 fi-rkl-11600 fi-hsw-4770 
  Missing(5): fi-bdw-5557u fi-hsw-4200u fi-bsw-cyan fi-snb-2520m 
fi-ctg-p8600 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@slpc:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/bat-dg1-5/igt@i915_selftest@l...@slpc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][2] ([i915#5127])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-hsw-4770/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2:  [PASS][6] -> [DMESG-WARN][7] ([i915#402])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11523/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-hsw-4770/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1072]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-hsw-4770/igt@kms_psr@primary_mmap_gtt.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-adl-ddr5:[DMESG-WARN][10] -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11523/fi-adl-ddr5/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-adl-ddr5/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6:  [DMESG-FAIL][12] ([i915#4494] / [i915#4957]) -> 
[PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11523/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [DMESG-WARN][14] ([i915#4269]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11523/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [INCOMPLETE][16] -> [DMESG-FAIL][17] ([i915#4494] / 
[i915#4957])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11523/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v2/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedes

[Intel-gfx] [PULL] gvt-next

[Wang, Zhi A]

Hi folks:

Here is the PR of gvt-next.

Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the 
GVT-g with the
new MDEV interfaces:

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)

Thanks so much for making this happen.

This PR has been tested as following and no problem shows up:

$dim update-branches
$dim apply-pull drm-intel-next < this_email.eml

The following changes since commit b39d2c6202426b560641e5800c5523851b5db586:

  drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush 
(2022-04-13 17:20:49 +0300)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20

for you to fetch changes up to 888471711a80b22c53547f3a625f20f487714f28:

  vfio/mdev: Remove mdev drvdata (2022-04-20 03:20:16 -0400)


gvt-next-2022-04-20

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)


Christoph Hellwig (27):
  drm/i915/gvt: remove module refcounting in 
intel_gvt_{,un}register_hypervisor
  drm/i915/gvt: remove enum hypervisor_type
  drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
  drm/i915/gvt: move the gvt code into kvmgt.ko
  drm/i915/gvt: remove intel_gvt_ops
  drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
  drm/i915/gvt: remove the unused from_virt_to_mfn op
  drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
  drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
  drm/i915/gvt: remove vgpu->handle
  drm/i915/gvt: devirtualize ->{read,write}_gpa
  drm/i915/gvt: devirtualize ->{get,put}_vfio_device
  drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
  drm/i915/gvt: devirtualize ->detach_vgpu
  drm/i915/gvt: devirtualize ->inject_msi
  drm/i915/gvt: devirtualize ->is_valid_gfn
  drm/i915/gvt: devirtualize ->gfn_to_mfn
  drm/i915/gvt: devirtualize ->{enable,disable}_page_track
  drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
  drm/i915/gvt: devirtualize dma_pin_guest_page
  drm/i915/gvt: remove struct intel_gvt_mpt
  drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
  drm/i915/gvt: streamline intel_vgpu_create
  drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
  drm/i915/gvt: remove kvmgt_guest_{init,exit}
  drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
  drm/i915/gvt: merge gvt.c into kvmgvt.c

Jani Nikula (2):
  drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
  drm/i915/gvt: better align the Makefile with i915 Makefile

Jason Gunthorpe (5):
  vfio/mdev: Remove vfio_mdev.c
  vfio/mdev: Remove mdev_parent_ops dev_attr_groups
  vfio/mdev: Remove mdev_parent_ops
  vfio/mdev: Use the driver core to create the 'remove' file
  vfio/mdev: Remove mdev drvdata

Zhi Wang (3):
  i915/gvt: Separate the MMIO tracking table from GVT-g
  i915/gvt: Save the initial HW state snapshot in i915
  i915/gvt: Use the initial HW state snapshot saved in i915

 Documentation/driver-api/vfio-mediated-device.rst |   27 +-
 drivers/gpu/drm/i915/Kconfig  |   36 +-
 drivers/gpu/drm/i915/Makefile |8 +-
 drivers/gpu/drm/i915/gvt/Makefile |   30 +-
 drivers/gpu/drm/i915/gvt/cfg_space.c  |   89 +-
 drivers/gpu/drm/i915/gvt/cmd_parser.c |4 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c |   36 +-
 drivers/gpu/drm/i915/gvt/execlist.c   |   12 +-
 drivers/gpu/drm/i915/gvt/firmware.c   |   25 +-
 drivers/gpu/drm/i915/gvt/gtt.c|   55 +-
 drivers/gpu/drm/i915/gvt/gvt.c|  340 --
 drivers/gpu/drm/i915/gvt/gvt.h|  128 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 1033 +++-
 drivers/gpu/drm/i915/gvt/hypercall.h  |   82 --
 drivers/gpu/drm/i915/gvt/interrupt.c  |   40 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 1097 +
 drivers/gpu/drm/i915/gvt/mmio.c   |4 +-
 drivers/gpu/drm/i915/gvt/mmio.h   |1 -
 drivers/gpu/drm/i915/gvt/mpt.h|  400 ---
 drivers/gpu/drm/i915/gvt/opregion.c   |  148 +--
 drivers/gpu/drm/i915/gvt/page_track.c |8 +-
 drivers/gpu/drm/i915/gvt/reg.h|9 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |   37 +-
 drivers/gpu/drm/i915/gvt/trace.h  |2 +-
 drivers/gpu/drm/i915/gvt/vgpu.c   |   22 +-
 drivers/gpu/drm/i915/i915_driver.c|7 -
 drivers/gpu/drm/i9

Re: [Intel-gfx] [PATCH] drm/i915: Fix race in __i915_vma_remove_closed

[kernel test robot]

Hi Karol,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on linus/master v5.18-rc3 next-20220419]
[cannot apply to drm-intel/for-linux-next linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/intel-lab-lkp/linux/commits/Karol-Herbst/drm-i915-Fix-race-in-__i915_vma_remove_closed/20220420-074525
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a013 
(https://download.01.org/0day-ci/archive/20220420/202204201724.hgr7l8yu-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
bac6cd5bf85669e3376610cfc4c4f9ca015e7b9b)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/50a17180127b7d2527ee9a8f5c9e8207e158afb6
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Karol-Herbst/drm-i915-Fix-race-in-__i915_vma_remove_closed/20220420-074525
git checkout 50a17180127b7d2527ee9a8f5c9e8207e158afb6
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/i915_vma.c:1654:19: warning: mixing declarations and 
>> code is incompatible with standards before C99 
>> [-Wdeclaration-after-statement]
   struct intel_gt *gt = vma->vm->gt;
^
   1 warning generated.


vim +1654 drivers/gpu/drm/i915/i915_vma.c

  1640  
  1641  static void release_references(struct i915_vma *vma, bool vm_ddestroy)
  1642  {
  1643  struct drm_i915_gem_object *obj = vma->obj;
  1644  
  1645  GEM_BUG_ON(i915_vma_is_active(vma));
  1646  
  1647  spin_lock(&obj->vma.lock);
  1648  list_del(&vma->obj_link);
  1649  if (!RB_EMPTY_NODE(&vma->obj_node))
  1650  rb_erase(&vma->obj_node, &obj->vma.tree);
  1651  
  1652  spin_unlock(&obj->vma.lock);
  1653  
> 1654  struct intel_gt *gt = vma->vm->gt;
  1655  
  1656  spin_lock_irq(>->closed_lock);
  1657  __i915_vma_remove_closed(vma);
  1658  spin_unlock_irq(>->closed_lock);
  1659  
  1660  if (vm_ddestroy)
  1661  i915_vm_resv_put(vma->vm);
  1662  
  1663  i915_active_fini(&vma->active);
  1664  GEM_WARN_ON(vma->resource);
  1665  i915_vma_free(vma);
  1666  }
  1667  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

[Intel-gfx] [PATCH v2] drm/i915: Fix race in __i915_vma_remove_closed

[Karol Herbst]

i915_vma_reopen checked if the vma is closed before without taking the
lock. So multiple threads could attempt removing the vma.

Instead the lock needs to be taken before actually checking.

v2: move struct declaration

Cc: Chris Wilson 
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5732
Signed-off-by: Karol Herbst 
---
 drivers/gpu/drm/i915/i915_vma.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 162e8d83691b..2efdad2b43fa 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1615,17 +1615,17 @@ void i915_vma_close(struct i915_vma *vma)
 
 static void __i915_vma_remove_closed(struct i915_vma *vma)
 {
-   struct intel_gt *gt = vma->vm->gt;
-
-   spin_lock_irq(>->closed_lock);
list_del_init(&vma->closed_link);
-   spin_unlock_irq(>->closed_lock);
 }
 
 void i915_vma_reopen(struct i915_vma *vma)
 {
+   struct intel_gt *gt = vma->vm->gt;
+
+   spin_lock_irq(>->closed_lock);
if (i915_vma_is_closed(vma))
__i915_vma_remove_closed(vma);
+   spin_unlock_irq(>->closed_lock);
 }
 
 static void force_unbind(struct i915_vma *vma)
@@ -1641,6 +1641,7 @@ static void force_unbind(struct i915_vma *vma)
 static void release_references(struct i915_vma *vma, bool vm_ddestroy)
 {
struct drm_i915_gem_object *obj = vma->obj;
+   struct intel_gt *gt = vma->vm->gt;
 
GEM_BUG_ON(i915_vma_is_active(vma));
 
@@ -1651,7 +1652,9 @@ static void release_references(struct i915_vma *vma, bool 
vm_ddestroy)
 
spin_unlock(&obj->vma.lock);
 
+   spin_lock_irq(>->closed_lock);
__i915_vma_remove_closed(vma);
+   spin_unlock_irq(>->closed_lock);
 
if (vm_ddestroy)
i915_vm_resv_put(vma->vm);
-- 
2.35.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix race in __i915_vma_remove_closed (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix race in __i915_vma_remove_closed (rev2)
URL   : https://patchwork.freedesktop.org/series/102845/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11526 -> Patchwork_102845v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (51 -> 46)
--

  Missing(5): fi-cml-u2 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-6:  [PASS][1] -> [INCOMPLETE][2] ([i915#4418])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/bat-dg1-6/igt@i915_selftest@live@gt_engines.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u:   [PASS][3] -> [DMESG-WARN][4] ([i915#5341] / [i915#62])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u:   [PASS][5] -> [DMESG-WARN][6] ([i915#62]) +11 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html

  * igt@runner@aborted:
- bat-dg1-6:  NOTRUN -> [FAIL][7] ([i915#4312] / [i915#5257])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/bat-dg1-6/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-5:  [INCOMPLETE][8] ([i915#4418]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/bat-dg1-5/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [INCOMPLETE][10] ([i915#4785]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@reset:
- {bat-adlp-6}:   [DMESG-FAIL][12] ([i915#4983]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/bat-adlp-6/igt@i915_selftest@l...@reset.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/bat-adlp-6/igt@i915_selftest@l...@reset.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN][14] ([i915#3576]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/bat-adlp-6/igt@kms_busy@ba...@flip.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/bat-adlp-6/igt@kms_busy@ba...@flip.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
  [i915#5722]: https://gitlab.freedesktop.org/drm/intel/issues/5722
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62


Build changes
-

  * Linux: CI_DRM_11526 -> Patchwork_102845v2

  CI-20190529: 20190529
  CI_DRM_11526: 6094ebd5db15c51e89ce9960d782613f8df57c63 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6440: 04262fc75ff3ec42f4db0c929d46b7cd5083911f @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_102845v2: 6094ebd5db15c51e89ce9960d782613f8df57c63 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

73275f6b3638 drm/i915: Fix race in __i915_vma_remove_closed

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/index.html

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs

[Andrzej Hajda]

Hi Ashutosh,

On 20.04.2022 07:21, Ashutosh Dixit wrote:

All kmalloc'd kobjects need a kobject_put() to free memory. For example in
previous code, kobj_gt_release() never gets called. The requirement of
kobject_put() now results in a slightly different code organization.

Cc: Andi Shyti 
Cc: Andrzej Hajda 
Cc: Rodrigo Vivi 
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")
Signed-off-by: Ashutosh Dixit 
---
  drivers/gpu/drm/i915/gt/intel_gt.c   |  1 +
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 35 ++--
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  6 +---
  drivers/gpu/drm/i915/gt/intel_gt_types.h |  3 ++
  drivers/gpu/drm/i915/i915_sysfs.c|  2 ++
  5 files changed, 22 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f0014c5072c9..f0c56ca12c0b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -783,6 +783,7 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
  {
intel_wakeref_t wakeref;
  
+	intel_gt_sysfs_unregister(gt);

intel_rps_driver_unregister(>->rps);
  
  	intel_pxp_fini(>->pxp);

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index 8ec8bc660c8c..6f1b081ca5b7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -24,7 +24,7 @@ bool is_object_gt(struct kobject *kobj)
  
  static struct intel_gt *kobj_to_gt(struct kobject *kobj)

  {
-   return container_of(kobj, struct kobj_gt, base)->gt;
+   return container_of(kobj, struct intel_gt, sysfs_gtn);
  }
  
  struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,

@@ -72,21 +72,19 @@ static struct attribute *id_attrs[] = {
  };
  ATTRIBUTE_GROUPS(id);
  
-static void kobj_gt_release(struct kobject *kobj)

+/* A kobject needs a release() method even if it does nothing */
+static void kobj_gtn_release(struct kobject *kobj)
  {
-   kfree(kobj);
  }
  
-static struct kobj_type kobj_gt_type = {

-   .release = kobj_gt_release,
+static struct kobj_type kobj_gtn_type = {
+   .release = kobj_gtn_release,
.sysfs_ops = &kobj_sysfs_ops,
.default_groups = id_groups,
  };
  
  void intel_gt_sysfs_register(struct intel_gt *gt)

  {
-   struct kobj_gt *kg;
-
/*
 * We need to make things right with the
 * ABI compatibility. The files were originally
@@ -98,25 +96,22 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
if (gt_is_root(gt))
intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
  
-	kg = kzalloc(sizeof(*kg), GFP_KERNEL);

-   if (!kg)
+   /* init and xfer ownership to sysfs tree */
+   if (kobject_init_and_add(>->sysfs_gtn, &kobj_gtn_type,
+gt->i915->sysfs_gt, "gt%d", gt->info.id))
goto exit_fail;
  
-	kobject_init(&kg->base, &kobj_gt_type);

-   kg->gt = gt;
-
-   /* xfer ownership to sysfs tree */
-   if (kobject_add(&kg->base, gt->i915->sysfs_gt, "gt%d", gt->info.id))
-   goto exit_kobj_put;
-
-   intel_gt_sysfs_pm_init(gt, &kg->base);
+   intel_gt_sysfs_pm_init(gt, >->sysfs_gtn);
  
  	return;
  
-exit_kobj_put:

-   kobject_put(&kg->base);
-
  exit_fail:
+   kobject_put(>->sysfs_gtn);
drm_warn(>->i915->drm,
 "failed to initialize gt%d sysfs root\n", gt->info.id);
  }
+
+void intel_gt_sysfs_unregister(struct intel_gt *gt)
+{
+   kobject_put(>->sysfs_gtn);
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
index 9471b26752cf..a99aa7e8b01a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
@@ -13,11 +13,6 @@
  
  struct intel_gt;
  
-struct kobj_gt {

-   struct kobject base;
-   struct intel_gt *gt;
-};
-
  bool is_object_gt(struct kobject *kobj);
  
  struct drm_i915_private *kobj_to_i915(struct kobject *kobj);

@@ -28,6 +23,7 @@ intel_gt_create_kobj(struct intel_gt *gt,
 const char *name);
  
  void intel_gt_sysfs_register(struct intel_gt *gt);

+void intel_gt_sysfs_unregister(struct intel_gt *gt);
  struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
const char *name);
  
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h b/drivers/gpu/drm/i915/gt/intel_gt_types.h

index 937b2e1a305e..4c72b4f983a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -222,6 +222,9 @@ struct intel_gt {
} mocs;
  
  	struct intel_pxp pxp;

+
+   /* gt/gtN sysfs */
+   struct kobject sysfs_gtn;


If you put kobject as a part of intel_gt what assures you that lifetime 
of kobject is shorter than intel_gt? Ie its refcounter is 0 on removal 
of intel_gt?


Regards
Andrzej


  };
  
  enum intel_gt_scratch_field {

diff -

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix race in __i915_vma_remove_closed (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix race in __i915_vma_remove_closed (rev2)
URL   : https://patchwork.freedesktop.org/series/102845/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11526_full -> Patchwork_102845v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-glk9/igt@kms_plane_multi...@atomic-pipe-b-tiling-none.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-glk5/igt@kms_plane_multi...@atomic-pipe-b-tiling-none.html

  * igt@kms_rmfb@close-fd:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-tglb3/igt@kms_r...@close-fd.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-tglb8/igt@kms_r...@close-fd.html

  
 Suppressed 

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

  * igt@gem_exec_schedule@wide@rcs0:
- {shard-tglu}:   [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-tglu-5/igt@gem_exec_schedule@w...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-tglu-1/igt@gem_exec_schedule@w...@rcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2410])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-kbl:  NOTRUN -> [DMESG-WARN][9] ([i915#5076] / [i915#5614])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-kbl6/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-apl8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_flush@basic-uc-rw-default:
- shard-snb:  [PASS][14] -> [SKIP][15] ([fdo#109271]) +2 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-snb7/igt@gem_exec_fl...@basic-uc-rw-default.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-snb6/igt@gem_exec_fl...@basic-uc-rw-default.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk:  [PASS][16] -> [DMESG-WARN][17] ([i915#118])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-glk8/igt@gem_exec_whis...@basic-queues-forked-all.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html

  * igt@gem_media_vme:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271]) +62 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-skl6/igt@gem_media_vme.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#454])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-iclb8/igt@i915_pm...@dc6-psr.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v2/shard-iclb3/igt@i915_pm...@dc6-psr.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  [PASS][21] -> [INCOMPLETE][22] ([i915#3921])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-snb2/igt@i915_se

[Intel-gfx] [PULL] drm-intel-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

Here go drm-intel-fixes for v5.18-rc4.

Two display fixes: Disable VRR if user disables it from panel settings
and avoid claiming PSR2 is enabled when it is not supported by config.

Regards, Joonas

***

drm-intel-fixes-2022-04-20:

- Unset enable_psr2_sel_fetch if PSR2 detection fails
- Fix to detect when VRR is turned off from panel settings

The following changes since commit b2d229d4ddb17db541098b83524d901257e93845:

  Linux 5.18-rc3 (2022-04-17 13:57:31 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-20

for you to fetch changes up to bb02330408a7bde33b5f46aa14fd5d7bfe6093b7:

  drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in 
intel_psr2_config_valid() fails (2022-04-20 07:51:14 +0300)


- Unset enable_psr2_sel_fetch if PSR2 detection fails
- Fix to detect when VRR is turned off from panel settings


José Roberto de Souza (1):
  drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in 
intel_psr2_config_valid() fails

Manasi Navare (1):
  drm/i915/display/vrr: Reset VRR capable property on a long hpd

 drivers/gpu/drm/i915/display/intel_dp.c  | 17 +-
 drivers/gpu/drm/i915/display/intel_psr.c | 38 ++--
 2 files changed, 32 insertions(+), 23 deletions(-)

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/display: Add workaround 22014263786 (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/display: Add workaround 
22014263786 (rev3)
URL   : https://patchwork.freedesktop.org/series/102835/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH v4] drm/i915: program wm blocks to at least blocks required per line

[Ville Syrjälä]

On Sun, Apr 17, 2022 at 12:31:05PM +0300, Vinod Govindapillai wrote:
> In configurations with single DRAM channel, for usecases like
> 4K 60 Hz, FIFO underruns are observed quite frequently. Looks
> like the wm0 watermark values need to bumped up because the wm0
> memory latency calculations are probably not taking the DRAM
> channel's impact into account.
> 
> As per the Bspec 49325, if the ddb allocation can hold at least
> one plane_blocks_per_line we should have selected method2.
> Assuming that modern HW versions have enough dbuf to hold
> at least one line, set the wm blocks to equivalent to blocks
> per line.
> 
> v2: styling and comments changes (Ville)
> v3: Updated the reviewed-by tag
> v4: max_t to max and patch styling (Ville)
> 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/4321
> Cc: Ville Syrjälä 
> Cc: Stanislav Lisovskiy 
> Signed-off-by: Vinod Govindapillai 
> Reviewed-by: Stanislav Lisovskiy 

Thanks. Pushed to drm-intel-next.

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 594ab59e4991..ee0047fdc95d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5475,6 +5475,25 @@ static void skl_compute_plane_wm(const struct 
> intel_crtc_state *crtc_state,
>   }
>  
>   blocks = fixed16_to_u32_round_up(selected_result) + 1;
> + /*
> +  * Lets have blocks at minimum equivalent to plane_blocks_per_line
> +  * as there will be at minimum one line for lines configuration. This
> +  * is a work around for FIFO underruns observed with resolutions like
> +  * 4k 60 Hz in single channel DRAM configurations.
> +  *
> +  * As per the Bspec 49325, if the ddb allocation can hold at least
> +  * one plane_blocks_per_line, we should have selected method2 in
> +  * the above logic. Assuming that modern versions have enough dbuf
> +  * and method2 guarantees blocks equivalent to at least 1 line,
> +  * select the blocks as plane_blocks_per_line.
> +  *
> +  * TODO: Revisit the logic when we have better understanding on DRAM
> +  * channels' impact on the level 0 memory latency and the relevant
> +  * wm calculations.
> +  */
> + if (skl_wm_has_lines(dev_priv, level))
> + blocks = max(blocks,
> +  
> fixed16_to_u32_round_up(wp->plane_blocks_per_line));
>   lines = div_round_up_fixed16(selected_result,
>wp->plane_blocks_per_line);
>  
> -- 
> 2.25.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH] drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines

[Ville Syrjälä]

On Mon, Apr 18, 2022 at 05:09:36PM +0200, Hans de Goede wrote:
> Commit 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers")
> introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these
> their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16).
> 
> This breaks the primary display pane on at least pineview machines, fix
> the mask to fix the primary display pane only showing black.
> 
> Tested on an Acer One AO532h with an Intel N450 SoC.
> 
> Fixes: 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers")
> Cc: José Roberto de Souza 
> Cc: Ville Syrjälä 
> Signed-off-by: Hans de Goede 
> ---
> Note this fixes a regression in 5.18-rc# and I'm not entirely sure what
> the procedure is here. Once I get a Reviewed-by or Acked-by and I push
> this to drm-intel-next (where it also is necessary), should I then also
> push it to drm-intel-fixes or will the current drm-intel-fixes
> maintainer pick it up?
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 51f46fe45c72..5f1f38684d65 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4352,12 +4352,12 @@
>  #define _DSPAADDR0x70184
>  #define _DSPASTRIDE  0x70188
>  #define _DSPAPOS 0x7018C /* reserved */
> -#define   DISP_POS_Y_MASKREG_GENMASK(31, 0)
> +#define   DISP_POS_Y_MASKREG_GENMASK(31, 16)

Doh. I guess I only tested it on plane A where the plane gets its size
from PIPESRC instead. And looks like the failure mode is such that
the likes of kms_plane/pixel-formats still gets consistent looking CRCs
even with the misconfigured plane size :/

Thanks for the fix. Pushed to drm-intel-next.

>  #define   DISP_POS_Y(y)  REG_FIELD_PREP(DISP_POS_Y_MASK, 
> (y))
>  #define   DISP_POS_X_MASKREG_GENMASK(15, 0)
>  #define   DISP_POS_X(x)  REG_FIELD_PREP(DISP_POS_X_MASK, 
> (x))
>  #define _DSPASIZE0x70190
> -#define   DISP_HEIGHT_MASK   REG_GENMASK(31, 0)
> +#define   DISP_HEIGHT_MASK   REG_GENMASK(31, 16)
>  #define   DISP_HEIGHT(h) REG_FIELD_PREP(DISP_HEIGHT_MASK, (h))
>  #define   DISP_WIDTH_MASKREG_GENMASK(15, 0)
>  #define   DISP_WIDTH(w)  REG_FIELD_PREP(DISP_WIDTH_MASK, 
> (w))
> -- 
> 2.35.1

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/display: Add workaround 22014263786 (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/display: Add workaround 
22014263786 (rev3)
URL   : https://patchwork.freedesktop.org/series/102835/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11526 -> Patchwork_102835v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (51 -> 45)
--

  Missing(6): fi-kbl-soraka fi-hsw-4200u bat-adlm-1 fi-icl-u2 fi-bsw-cyan 
fi-ctg-p8600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][5] ([i915#5757])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#4070] / [i915#4103]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2:  [PASS][8] -> [DMESG-WARN][9] ([i915#402]) +1 similar 
issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([fdo#109285] / [i915#4098])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][11] -> [DMESG-WARN][12] ([i915#4269])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#4070] / [i915#533])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#3555] / [i915#4098])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#3301] / [i915#3708])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  * igt@prime_vgem@basic-write:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#3291] / [i915#3708]) +2 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-rkl-11600/igt@prime_v...@basic-write.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][18] ([i915#4312])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   [INCOMPLETE][19] ([i915#5127]) -> [PASS][20]
   [19]: 
https:/

Re: [Intel-gfx] [PULL] gvt-next

[Wang, Zhi A]

On 4/20/22 12:13 PM, Jason Gunthorpe wrote:
> On Wed, Apr 20, 2022 at 08:04:31AM +, Wang, Zhi A wrote:
>> Hi folks:
>>
>> Here is the PR of gvt-next.
>>
>> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting 
>> the GVT-g with the
>> new MDEV interfaces:
>>
>> - Separating the MMIO table from GVT-g. (Zhi)
>> - GVT-g re-factor. (Christoph)
>> - GVT-g mdev API cleanup. (Jason)
>> - GVT-g trace/makefile cleanup. (Jani)
>>
>> Thanks so much for making this happen.
>>
>> This PR has been tested as following and no problem shows up:
>>
>> $dim update-branches
>> $dim apply-pull drm-intel-next < this_email.eml
>>
>> The following changes since commit b39d2c6202426b560641e5800c5523851b5db586:
>>
>>   drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush 
>> (2022-04-13 17:20:49 +0300)
> 
> ??
> 
> Why did you rebase this again? It needs to be on a rc release tag as
> you had in your github, not whatever this is.
> 
Hi Jason:

Here is what I understand, the pull going to the drm-intel-next needs to be 
based on drm-intel-next from the branch gvt-next. The pull going to the VFIO 
needs to be based on -rc, the topic/for-christoph brnach. So I did a merge from 
topic/for-christoph to my gvt-next branch and sent this pull, so that our QA 
can test these bundle on the gvt-staging branch.

Sorry this is way too complicated to me. Let me prepare the new pull as what 
you ask. Shall I send the exact same pull to i915 and VFIO ?

Thanks,
Zhi.

> Jason
> 

Re: [Intel-gfx] [PATCH] drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines

[Hans de Goede]

Hi Ville,

On 4/20/22 16:03, Ville Syrjälä wrote:
> On Mon, Apr 18, 2022 at 05:09:36PM +0200, Hans de Goede wrote:
>> Commit 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers")
>> introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these
>> their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16).
>>
>> This breaks the primary display pane on at least pineview machines, fix
>> the mask to fix the primary display pane only showing black.
>>
>> Tested on an Acer One AO532h with an Intel N450 SoC.
>>
>> Fixes: 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers")
>> Cc: José Roberto de Souza 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Hans de Goede 
>> ---
>> Note this fixes a regression in 5.18-rc# and I'm not entirely sure what
>> the procedure is here. Once I get a Reviewed-by or Acked-by and I push
>> this to drm-intel-next (where it also is necessary), should I then also
>> push it to drm-intel-fixes or will the current drm-intel-fixes
>> maintainer pick it up?
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 51f46fe45c72..5f1f38684d65 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -4352,12 +4352,12 @@
>>  #define _DSPAADDR   0x70184
>>  #define _DSPASTRIDE 0x70188
>>  #define _DSPAPOS0x7018C /* reserved */
>> -#define   DISP_POS_Y_MASK   REG_GENMASK(31, 0)
>> +#define   DISP_POS_Y_MASK   REG_GENMASK(31, 16)
> 
> Doh. I guess I only tested it on plane A where the plane gets its size
> from PIPESRC instead. And looks like the failure mode is such that
> the likes of kms_plane/pixel-formats still gets consistent looking CRCs
> even with the misconfigured plane size :/
> 
> Thanks for the fix. Pushed to drm-intel-next.

Thank you pushing this out, will you (or someone else from Intel)
also take care of getting this on its way to 5.18-rc# ?

Regards,

Hans



> 
>>  #define   DISP_POS_Y(y) REG_FIELD_PREP(DISP_POS_Y_MASK, 
>> (y))
>>  #define   DISP_POS_X_MASK   REG_GENMASK(15, 0)
>>  #define   DISP_POS_X(x) REG_FIELD_PREP(DISP_POS_X_MASK, 
>> (x))
>>  #define _DSPASIZE   0x70190
>> -#define   DISP_HEIGHT_MASK  REG_GENMASK(31, 0)
>> +#define   DISP_HEIGHT_MASK  REG_GENMASK(31, 16)
>>  #define   DISP_HEIGHT(h)REG_FIELD_PREP(DISP_HEIGHT_MASK, (h))
>>  #define   DISP_WIDTH_MASK   REG_GENMASK(15, 0)
>>  #define   DISP_WIDTH(w) REG_FIELD_PREP(DISP_WIDTH_MASK, 
>> (w))
>> -- 
>> 2.35.1
> 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/display: Add workaround 22014263786 (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/display: Add workaround 
22014263786 (rev3)
URL   : https://patchwork.freedesktop.org/series/102835/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11526_full -> Patchwork_102835v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-dg1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-contexts-1us:
- shard-iclb: [PASS][1] -> [TIMEOUT][2] ([i915#3070])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-iclb3/igt@gem_...@in-flight-contexts-1us.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-iclb8/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-kbl:  NOTRUN -> [DMESG-WARN][3] ([i915#5076] / [i915#5614])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-kbl3/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [PASS][4] -> [FAIL][5] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_lmem_swapping@parallel-random-verify:
- shard-skl:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-skl4/igt@gem_lmem_swapp...@parallel-random-verify.html

  * igt@gem_lmem_swapping@verify-random:
- shard-iclb: NOTRUN -> [SKIP][9] ([i915#4613])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-iclb7/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted:
- shard-iclb: NOTRUN -> [SKIP][10] ([i915#4270])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-iclb7/igt@gem_...@dmabuf-shared-protected-dst-is-context-refcounted.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +4 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-apl7/igt@gem_workarou...@suspend-resume-context.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-apl8/igt@gem_workarou...@suspend-resume-context.html

  * igt@gen9_exec_parse@unaligned-access:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#2856])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-iclb7/igt@gen9_exec_pa...@unaligned-access.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  [PASS][14] -> [INCOMPLETE][15] ([i915#3921])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11526/shard-snb2/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-snb7/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_big_fb@4-tiled-64bpp-rotate-90:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#5286])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-tglb3/igt@kms_big...@4-tiled-64bpp-rotate-90.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-90:
- shard-apl:  NOTRUN -> [SKIP][17] ([fdo#109271]) +25 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-apl6/igt@kms_big...@y-tiled-64bpp-rotate-90.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-kbl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3777])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-kbl6/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3777])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-apl2/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html

  * igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][20] ([i915#3689] / [i915#3886])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/shard-tglb5/igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs.html
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3886]) +1 
similar

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs

[Dixit, Ashutosh]

On Wed, 20 Apr 2022 05:17:57 -0700, Andrzej Hajda wrote:
>
> Hi Ashutosh,

Hi Andrzej,

> On 20.04.2022 07:21, Ashutosh Dixit wrote:
> > All kmalloc'd kobjects need a kobject_put() to free memory. For example in
> > previous code, kobj_gt_release() never gets called. The requirement of
> > kobject_put() now results in a slightly different code organization.
> >
> > Cc: Andi Shyti 
> > Cc: Andrzej Hajda 
> > Cc: Rodrigo Vivi 
> > Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")

/snip/

> > +void intel_gt_sysfs_unregister(struct intel_gt *gt)
> > +{
> > +   kobject_put(>->sysfs_gtn);
> > +}
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> > index 9471b26752cf..a99aa7e8b01a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> > @@ -13,11 +13,6 @@
> > struct intel_gt;
> >   -struct kobj_gt {
> > -   struct kobject base;
> > -   struct intel_gt *gt;
> > -};
> > -
> >   bool is_object_gt(struct kobject *kobj);
> > struct drm_i915_private *kobj_to_i915(struct kobject *kobj);
> > @@ -28,6 +23,7 @@ intel_gt_create_kobj(struct intel_gt *gt,
> >  const char *name);
> > void intel_gt_sysfs_register(struct intel_gt *gt);
> > +void intel_gt_sysfs_unregister(struct intel_gt *gt);
> >   struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
> > const char *name);
> >   diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > index 937b2e1a305e..4c72b4f983a6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > @@ -222,6 +222,9 @@ struct intel_gt {
> > } mocs;
> > struct intel_pxp pxp;
> > +
> > +   /* gt/gtN sysfs */
> > +   struct kobject sysfs_gtn;
>
> If you put kobject as a part of intel_gt what assures you that lifetime of
> kobject is shorter than intel_gt? Ie its refcounter is 0 on removal of
> intel_gt?

Because we are explicitly doing a kobject_put() in
intel_gt_sysfs_unregister(). Which is exactly what we are *not* doing in
the previous code.

Let me explain a bit about the previous code (but feel free to skip since
the patch should speak for itself):
* Previously we kzalloc a 'struct kobj_gt'
* But we don't save a pointer to the 'struct kobj_gt' so we don't have the
  pointer to the kobject to be able to do a kobject_put() on it later
* Therefore we need to store the pointer in 'struct intel_gt'
* But if we have to put the pointer in 'struct intel_gt' we might as well
  put the kobject as part of 'struct intel_gt' and that also removes the
  need to have a 'struct kobj_gt' (kobj_to_gt() can just use container_of()
  to get gt from kobj).
* So I think this patch simpler/cleaner than the original code if you take
  the requirement for kobject_put() into account.

Thanks.
--
Ashutosh

Re: [Intel-gfx] [PULL] gvt-next

[Wang, Zhi A]

On 4/20/22 3:02 PM, Jason Gunthorpe wrote:
> On Wed, Apr 20, 2022 at 02:41:04PM +, Wang, Zhi A wrote:
>> On 4/20/22 12:13 PM, Jason Gunthorpe wrote:
>>> On Wed, Apr 20, 2022 at 08:04:31AM +, Wang, Zhi A wrote:
 Hi folks:

 Here is the PR of gvt-next.

 Mostly it includes the patch bundle of GVT-g re-factor patches for 
 adapting the GVT-g with the
 new MDEV interfaces:

 - Separating the MMIO table from GVT-g. (Zhi)
 - GVT-g re-factor. (Christoph)
 - GVT-g mdev API cleanup. (Jason)
 - GVT-g trace/makefile cleanup. (Jani)

 Thanks so much for making this happen.

 This PR has been tested as following and no problem shows up:

 $dim update-branches
 $dim apply-pull drm-intel-next < this_email.eml

 The following changes since commit 
 b39d2c6202426b560641e5800c5523851b5db586:

   drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush 
 (2022-04-13 17:20:49 +0300)
>>>
>>> ??
>>>
>>> Why did you rebase this again? It needs to be on a rc release tag as
>>> you had in your github, not whatever this is.
>>>
>> Hi Jason:
>>
>> Here is what I understand, the pull going to the drm-intel-next
>> needs to be based on drm-intel-next from the branch gvt-next. 
> 
> No, there cannot be two pulls, as I explained when using topic
> branches you must never rebase.
> 
>> The pull going to the VFIO needs to be based on -rc, the
>> topic/for-christoph brnach.
> 
> Yes, so what you need to do is:
> 
> # Get a clean tree on drm-intel-next
> $ git worktree add /tmp/gvt-next
> Preparing worktree (new branch 'gvt-next')
> $ cd /tmp/gvt-next
> $ git reset --hard b39d2c6202426b560641e5800c5523851b5db586  # drm-intel-next 
> commit you tested
> 
> # Merge Christoph's topic:
> $ git fetch https://github.com/intel/gvt-linux.git topic/for-christoph
> $ git merge FETCH_HEAD
> Auto-merging drivers/gpu/drm/i915/Makefile
> Auto-merging drivers/gpu/drm/i915/gvt/handlers.c
> Auto-merging drivers/gpu/drm/i915/i915_driver.c
> Auto-merging drivers/gpu/drm/i915/i915_drv.h
> Merge made by the 'ort' strategy.
> 
Exactly what I did on my branch except that I sent the pull request based on my 
gvt-next. :(
> [..
> Merge branch 'topic/for-christoph' of https://github.com/intel/gvt-linux into 
> gvt-next
> 
> # By Christoph Hellwig (27) and others
> # Via Zhi Wang
> * 'topic/for-christoph' of https://github.com/intel/gvt-linux: (37 commits)
> ]
> 
> And then check it against what you prepared in this PR here:
> 
> $ git diff HEAD 888471711a80b22c53547f3a625f20f487714f28
> [empty]
> 
> *do not rebase a topic branch* this is very important.
> 
> Now - given that we can see there is no merge conflict you don't need
> to do anything! Just send topic/for-christoph, exactly as-it-is to
> drm-intel-next as a PR and that is all.
> 
>> Sorry this is way too complicated to me. Let me prepare the new pull
>> as what you ask. Shall I send the exact same pull to i915 and VFIO ?
> 
> Yes, exact same, this is important.
> 
> You were very close before, the only issue was rebasing
> topic/for-christoph instead of merging.
>
I will send it by the end of the day. Thanks so much for your patience.
 
> Jason
> 

Re: [Intel-gfx] [PATCH] drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines

[Ville Syrjälä]

On Wed, Apr 20, 2022 at 05:32:43PM +0200, Hans de Goede wrote:
> Hi Ville,
> 
> On 4/20/22 16:03, Ville Syrjälä wrote:
> > On Mon, Apr 18, 2022 at 05:09:36PM +0200, Hans de Goede wrote:
> >> Commit 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers")
> >> introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these
> >> their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16).
> >>
> >> This breaks the primary display pane on at least pineview machines, fix
> >> the mask to fix the primary display pane only showing black.
> >>
> >> Tested on an Acer One AO532h with an Intel N450 SoC.
> >>
> >> Fixes: 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers")
> >> Cc: José Roberto de Souza 
> >> Cc: Ville Syrjälä 
> >> Signed-off-by: Hans de Goede 
> >> ---
> >> Note this fixes a regression in 5.18-rc# and I'm not entirely sure what
> >> the procedure is here. Once I get a Reviewed-by or Acked-by and I push
> >> this to drm-intel-next (where it also is necessary), should I then also
> >> push it to drm-intel-fixes or will the current drm-intel-fixes
> >> maintainer pick it up?
> >> ---
> >>  drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 51f46fe45c72..5f1f38684d65 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -4352,12 +4352,12 @@
> >>  #define _DSPAADDR 0x70184
> >>  #define _DSPASTRIDE   0x70188
> >>  #define _DSPAPOS  0x7018C /* reserved */
> >> -#define   DISP_POS_Y_MASK REG_GENMASK(31, 0)
> >> +#define   DISP_POS_Y_MASK REG_GENMASK(31, 16)
> > 
> > Doh. I guess I only tested it on plane A where the plane gets its size
> > from PIPESRC instead. And looks like the failure mode is such that
> > the likes of kms_plane/pixel-formats still gets consistent looking CRCs
> > even with the misconfigured plane size :/
> > 
> > Thanks for the fix. Pushed to drm-intel-next.
> 
> Thank you pushing this out, will you (or someone else from Intel)
> also take care of getting this on its way to 5.18-rc# ?

It has a fixes tag so it should get cherry-picked for fixes.

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs

[Dixit, Ashutosh]

On Wed, 20 Apr 2022 05:17:57 -0700, Andrzej Hajda wrote:
>
> Hi Ashutosh,

Hi Andrzej,

> On 20.04.2022 07:21, Ashutosh Dixit wrote:
> > All kmalloc'd kobjects need a kobject_put() to free memory. For example in
> > previous code, kobj_gt_release() never gets called. The requirement of
> > kobject_put() now results in a slightly different code organization.
> >
> > Cc: Andi Shyti 
> > Cc: Andrzej Hajda 
> > Cc: Rodrigo Vivi 
> > Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")

/snip/

> > +void intel_gt_sysfs_unregister(struct intel_gt *gt)
> > +{
> > +   kobject_put(>->sysfs_gtn);
> > +}
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> > index 9471b26752cf..a99aa7e8b01a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
> > @@ -13,11 +13,6 @@
> > struct intel_gt;
> >   -struct kobj_gt {
> > -   struct kobject base;
> > -   struct intel_gt *gt;
> > -};
> > -
> >   bool is_object_gt(struct kobject *kobj);
> > struct drm_i915_private *kobj_to_i915(struct kobject *kobj);
> > @@ -28,6 +23,7 @@ intel_gt_create_kobj(struct intel_gt *gt,
> >  const char *name);
> > void intel_gt_sysfs_register(struct intel_gt *gt);
> > +void intel_gt_sysfs_unregister(struct intel_gt *gt);
> >   struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
> > const char *name);
> >   diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > index 937b2e1a305e..4c72b4f983a6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > @@ -222,6 +222,9 @@ struct intel_gt {
> > } mocs;
> > struct intel_pxp pxp;
> > +
> > +   /* gt/gtN sysfs */
> > +   struct kobject sysfs_gtn;
>
> If you put kobject as a part of intel_gt what assures you that lifetime of
> kobject is shorter than intel_gt? Ie its refcounter is 0 on removal of
> intel_gt?

Because we are explicitly doing a kobject_put() in
intel_gt_sysfs_unregister(). Which is exactly what we are *not* doing in
the previous code.

Let me explain a bit about the previous code (but feel free to skip since
the patch should speak for itself):
* Previously we kzalloc a 'struct kobj_gt'
* But we don't save a pointer to the 'struct kobj_gt' so we don't have the
  pointer to the kobject to be able to do a kobject_put() on it later
* Therefore we need to store the pointer in 'struct intel_gt'
* But if we have to put the pointer in 'struct intel_gt' we might as well
  put the kobject as part of 'struct intel_gt' and that also removes the
  need to have a 'struct kobj_gt' (kobj_to_gt() can just use container_of()
  to get gt from kobj).
* So I think this patch simpler/cleaner than the original code if you take
  the requirement for kobject_put() into account.

Thanks.
--
Ashutosh

Re: [Intel-gfx] [PATCH 3/8] drm/i915/pcode: Extend pcode functions for multiple gt's

[Vivi, Rodrigo]

On Tue, 2022-04-19 at 22:54 -0700, Dixit, Ashutosh wrote:
> On Fri, 15 Apr 2022 03:21:26 -0700, Rodrigo Vivi wrote:
> > On Thu, Apr 14, 2022 at 03:31:07PM -0700, Dixit, Ashutosh wrote:
> > > On Thu, 14 Apr 2022 06:28:57 -0700, Jani Nikula wrote:
> > > > 
> > > > On Wed, 13 Apr 2022, Ashutosh Dixit 
> > > > wrote:
> > > > > Each gt contains an independent instance of pcode. Extend
> > > > > pcode functions
> > > > > to interface with pcode on different gt's. Previous (GT0)
> > > > > pcode read/write
> > > > > interfaces are preserved.
> > > > 
> > > > The big problem here is that this hard couples display code to
> > > > gt code,
> > > > while we're trying hard to go the opposite direction. It
> > > > doesn't matter
> > > > that the existing interfaces are preserved as wrappers when it
> > > > relies on
> > > > an intel_gt being available (via i915->gt0).
> > 
> > I don't believe there is a big problem in here...
> > 
> > please note the intel_pcode.h is keeping the abstraction for
> > display
> > 
> > #define snb_pcode_write_timeout(i915, mbox, val, fast_timeout_us,
> > slow_timeout_ms) \
> >     intel_gt_pcode_write_timeout(&(i915)->gt0, mbox, val,
> > fast_timeout_us, slow_timeout_ms)
> > 
> > #define snb_pcode_write(i915, mbox, val) \
> >     snb_pcode_write_timeout(i915, mbox, val, 500, 0)
> > 
> > display only uses these macros that Ashutosh didn't touch.
> > 
> > > > 
> > > > Note how 'git grep intel_gt -- drivers/gpu/drm/i915/display/'
> > > > matches
> > > > only 1 line.
> > 
> > As well with the patches applied:
> > 
> > $ git log --oneline -1
> > 1f58f1195478 (HEAD -> drm-tip) drm/i915/gt: Expose per-gt RPS
> > defaults in sysfs
> > 
> > $ git grep intel_gt -- drivers/gpu/drm/i915/display/
> > drivers/gpu/drm/i915/display/intel_display.c:  
> > intel_gt_set_wedged(to_gt(dev_priv));
> > 
> > > 
> > > Hi Jani, would you have suggestions about how to do this (handle
> > > pcode on
> > > multiple gt's)? The thinking was this patch would be a
> > > straightforward way
> > > to avoid code duplication. Also:
> > 
> > Maybe it is just a matter of renaming the macros used by display
> > in intel_pcode.h to reflect that it should be used by display only?
> 
> In v2 I have added a patch ([PATCH 4/9] drm/i915/gt: Convert callers
> to
> user per-gt pcode functions) which correctly calls per-gt pcode
> functions
> where this is required. With this patch only display functions (and
> one
> other caller) are left calling the "global scope"
> snb_pcode_read/write*
> functions. So the legacy snb_pcode_read/write* are now basically
> being used
> only by display. Let's see if Jani is ok with this. Thanks.

Jani is not happy with this abstraction because it still creates some
dependency and also no with the name intel_gt_pcode_ in the
functions...

He has some valid points.

I believe the right way to do this is to keep intel_pcode totally clean
from intel_gt and only receive intel_uncore as the argument. Then, if
needed we create display/intel_display_pcode and/or gt/intel_gt_pcode
with the needed abstractions... but better with none I'd say.

[Intel-gfx] [PULL v2] gvt-next

[Wang, Zhi A]

Hi folks:

Here is the PR of gvt-next. Thanks so much for the patience.

Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the 
GVT-g with the
new MDEV interfaces:

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)

Thanks so much for making this happen.

This PR has been tested as following and no problem shows up:

$dim update-branches
$dim apply-pull drm-intel-next < this_email.eml

The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:

  Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph

for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e:

  vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400)


gvt-next-2022-04-22-for-christoph

- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup. (Jason)
- GVT-g trace/makefile cleanup. (Jani)


Christoph Hellwig (27):
  drm/i915/gvt: remove module refcounting in 
intel_gvt_{,un}register_hypervisor
  drm/i915/gvt: remove enum hypervisor_type
  drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
  drm/i915/gvt: move the gvt code into kvmgt.ko
  drm/i915/gvt: remove intel_gvt_ops
  drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
  drm/i915/gvt: remove the unused from_virt_to_mfn op
  drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
  drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
  drm/i915/gvt: remove vgpu->handle
  drm/i915/gvt: devirtualize ->{read,write}_gpa
  drm/i915/gvt: devirtualize ->{get,put}_vfio_device
  drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
  drm/i915/gvt: devirtualize ->detach_vgpu
  drm/i915/gvt: devirtualize ->inject_msi
  drm/i915/gvt: devirtualize ->is_valid_gfn
  drm/i915/gvt: devirtualize ->gfn_to_mfn
  drm/i915/gvt: devirtualize ->{enable,disable}_page_track
  drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
  drm/i915/gvt: devirtualize dma_pin_guest_page
  drm/i915/gvt: remove struct intel_gvt_mpt
  drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
  drm/i915/gvt: streamline intel_vgpu_create
  drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
  drm/i915/gvt: remove kvmgt_guest_{init,exit}
  drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
  drm/i915/gvt: merge gvt.c into kvmgvt.c

Jani Nikula (2):
  drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
  drm/i915/gvt: better align the Makefile with i915 Makefile

Jason Gunthorpe (5):
  vfio/mdev: Remove vfio_mdev.c
  vfio/mdev: Remove mdev_parent_ops dev_attr_groups
  vfio/mdev: Remove mdev_parent_ops
  vfio/mdev: Use the driver core to create the 'remove' file
  vfio/mdev: Remove mdev drvdata

Zhi Wang (3):
  i915/gvt: Separate the MMIO tracking table from GVT-g
  i915/gvt: Save the initial HW state snapshot in i915
  i915/gvt: Use the initial HW state snapshot saved in i915

 Documentation/driver-api/vfio-mediated-device.rst |   27 +-
 drivers/gpu/drm/i915/Kconfig  |   36 +-
 drivers/gpu/drm/i915/Makefile |8 +-
 drivers/gpu/drm/i915/gvt/Makefile |   30 +-
 drivers/gpu/drm/i915/gvt/cfg_space.c  |   89 +-
 drivers/gpu/drm/i915/gvt/cmd_parser.c |4 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c |   36 +-
 drivers/gpu/drm/i915/gvt/execlist.c   |   12 +-
 drivers/gpu/drm/i915/gvt/firmware.c   |   25 +-
 drivers/gpu/drm/i915/gvt/gtt.c|   55 +-
 drivers/gpu/drm/i915/gvt/gvt.c|  340 --
 drivers/gpu/drm/i915/gvt/gvt.h|  128 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 1033 +++-
 drivers/gpu/drm/i915/gvt/hypercall.h  |   82 --
 drivers/gpu/drm/i915/gvt/interrupt.c  |   40 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 1097 +
 drivers/gpu/drm/i915/gvt/mmio.c   |4 +-
 drivers/gpu/drm/i915/gvt/mmio.h   |1 -
 drivers/gpu/drm/i915/gvt/mpt.h|  400 ---
 drivers/gpu/drm/i915/gvt/opregion.c   |  148 +--
 drivers/gpu/drm/i915/gvt/page_track.c |8 +-
 drivers/gpu/drm/i915/gvt/reg.h|9 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |   37 +-
 drivers/gpu/drm/i915/gvt/trace.h  |2 +-
 drivers/gpu/drm/i915/gvt/vgpu.c   |   22 +-
 drivers/gpu/drm/i915/i915_driver.c|7 -
 drivers/gpu/drm

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/display: Add workaround 22014263786 (rev3)

[Souza, Jose]

On Wed, 2022-04-20 at 15:49 +, Patchwork wrote:
Patch Details
Series: series starting with [v2,1/2] drm/i915/display: Add workaround 
22014263786 (rev3)
URL:https://patchwork.freedesktop.org/series/102835/
State:  success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102835v3/index.html
CI Bug Log - changes from CI_DRM_11526_full -> Patchwork_102835v3_full
Summary

SUCCESS

No regressions found.

First patch pushed drm-intel-next and second one to drm-intel-gt-next.

Thanks for the reviews MattR.


Participating hosts (12 -> 11)

Missing (1): shard-dg1

Known issues

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

IGT changes
Issues hit

  *   igt@gem_eio@in-flight-contexts-1us:

 *   shard-iclb: 
PASS
 -> 
TIMEOUT
 (i915#3070)
  *   igt@gem_exec_balancer@parallel-contexts:

 *   shard-kbl: NOTRUN -> 
DMESG-WARN
 (i915#5076 / 
i915#5614)
  *   igt@gem_exec_fair@basic-pace-solo@rcs0:

 *   shard-apl: 
PASS
 -> 
FAIL
 (i915#2842)
  *   igt@gem_exec_fair@basic-pace@vecs0:

 *   shard-kbl: 
PASS
 -> 
FAIL
 (i915#2842)
  *   igt@gem_lmem_swapping@parallel-random-verify:

 *   shard-skl: NOTRUN -> 
SKIP
 (fdo#109271 / 
i915#4613)
  *   igt@gem_lmem_swapping@verify-random:

 *   shard-iclb: NOTRUN -> 
SKIP
 (i915#4613)
  *   igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted:

 *   shard-iclb: NOTRUN -> 
SKIP
 (i915#4270)
  *   igt@gem_workarounds@suspend-resume-context:

 *   shard-apl: 
PASS
 -> 
DMESG-WARN
 (i915#180) +4 similar 
issues
  *   igt@gen9_exec_parse@unaligned-access:

 *   shard-iclb: NOTRUN -> 
SKIP
 (i915#2856)
  *   igt@i915_selftest@live@hangcheck:

 *   shard-snb: 
PASS
 -> 
INCOMPLETE
 (i915#3921)
  *   igt@kms_big_fb@4-tiled-64bpp-rotate-90:

 *   shard-tglb: NOTRUN -> 
SKIP
 (i915#5286)
  *   igt@kms_big_fb@y-tiled-64bpp-rotate-90:

 *   shard-apl: NOTRUN -> 
SKIP
 (fdo#109271) +25 similar 
issues
  *   igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:

 *   shard-kbl: NOTRUN -> 
SKIP
 (fdo#109271 / 
i915#3777

[Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Matthew Auld]

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
  - Some spelling fixes and other small tweaks. (Akeem & Thomas)
  - Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
  - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
 Documentation/gpu/rfc/i915_small_bar.h   | 190 +++
 Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
 Documentation/gpu/rfc/index.rst  |   4 +
 3 files changed, 252 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
 create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+   /** @region: The class:instance pair encoding */
+   struct drm_i915_gem_memory_class_instance region;
+
+   /** @rsvd0: MBZ */
+   __u32 rsvd0;
+
+   /** @probed_size: Memory probed by the driver (-1 = unknown) */
+   __u64 probed_size;
+
+   /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+   __u64 unallocated_size;
+
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+   struct {
+   /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible. (-1 = unknown).
+*
+* This will be always be <= @probed_size, and the
+* remainder(if there is any) will not be CPU
+* accessible.
+*/
+   __u64 probed_cpu_visible_size;
+   };
+   };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the stuff that
+ * is immutable. Previously we would have two ioctls, one to create the object
+ * with gem_create, and another to apply various parameters, however this
+ * creates some ambiguity for the params which are considered immutable. Also 
in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+   /**
+* @size: Requested size for the object.
+*
+* The (page-aligned) allocated size for the object will be returned.
+*
+* Note that for some devices we have might have further minimum
+* page-size restrictions(larger than 4K), like for device local-memory.
+* However in general the final size here should always reflect any
+* rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+* extension to place the object in device local-memory.
+*/
+   __u64 size;
+   /**
+* @handle: Returned handle for the object.
+*
+* Object handles are nonzero.
+*/
+   __u32 handle;
+   /**
+* @flags: Optional flags.
+*
+* Supported values:
+*
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the kernel that
+* the object will need to be accessed via the CPU.
+*
+* Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and
+* only strictly required on platforms where only some of the device
+* memory is directly visible or mappable through the CPU, like on DG2+.
+*
+* One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+* ensure we can always spill the allocation to system memory, if we
+* can't place the object in the mappable part of
+* I915_MEMORY_CLASS_DEVICE.
+*
+* Note that since the kernel only supports flat-CCS on objects that can
+* *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore don't
+* support I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS together with
+* flat-CCS.
+*
+* Without this hint, the kernel will assume that non-mappable
+* I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the
+* kernel can still migrate the object to the mappable part, as a last
+* resort, if userspace ever CPU fau

Re: [Intel-gfx] [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

[Zack Rusin]

On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:
> ⚠ External Email
> 
> Hi Zack,
> 
> Am 20.04.22 um 05:56 schrieb Zack Rusin:
> > On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:
> > > Rework the internals of the dma_resv object to allow adding more
> > > than
> > > one
> > > write fence and remember for each fence what purpose it had.
> > > 
> > > This allows removing the workaround from amdgpu which used a
> > > container
> > > for
> > > this instead.
> > > 
> > > Signed-off-by: Christian König 
> > > Reviewed-by: Daniel Vetter 
> > > Cc: amd-...@lists.freedesktop.org
> > 
> > afaict this change broke vmwgfx which now kernel oops right after
> > boot.
> > I haven't had the time to look into it yet, so I'm not sure what's
> > the
> > problem. I'll look at this tomorrow, but just in case you have some
> > clues, the backtrace follows:
> 
> that's a known issue and should already be fixed with:
> 
> commit d72dcbe9fce505228dae43bef9da8f2b707d1b3d
> Author: Christian König 
> Date:   Mon Apr 11 15:21:59 2022 +0200

Unfortunately that doesn't seem to be it. The backtrace is from the
current (as of the time of sending of this email) drm-misc-next, which
has this change, so it's something else.

z

Re: [Intel-gfx] [PULL v2] gvt-next

[Alex Williamson]

On Wed, 20 Apr 2022 13:43:51 -0300
Jason Gunthorpe  wrote:

> On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> > Hi folks:
> > 
> > Here is the PR of gvt-next. Thanks so much for the patience.
> > 
> > Mostly it includes the patch bundle of GVT-g re-factor patches for adapting 
> > the GVT-g with the
> > new MDEV interfaces:
> > 
> > - Separating the MMIO table from GVT-g. (Zhi)
> > - GVT-g re-factor. (Christoph)
> > - GVT-g mdev API cleanup. (Jason)
> > - GVT-g trace/makefile cleanup. (Jani)
> > 
> > Thanks so much for making this happen.
> > 
> > This PR has been tested as following and no problem shows up:
> > 
> > $dim update-branches
> > $dim apply-pull drm-intel-next < this_email.eml
> > 
> > The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
> > 
> >   Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
> > 
> > are available in the Git repository at:
> > 
> >   https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph
> > 
> > for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e:
> > 
> >   vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400)  
> 
> This looks well constructed now! thanks
> 
> Alex you can pull this for VFIO after Jani&co grab it
> 
> I'll respin my vfio_group series on top of this branch

Sure, so just to confirm tags/gvt-next-2022-04-20-for-christoph is
pruned down to exactly the commits we're looking for now?  Thanks,

Alex

[Intel-gfx] [CI 1/4] drm/i915: consider min_page_size when migrating

[Matthew Auld]

We can only force migrate an object if the existing object size is
compatible with the new destinations min_page_size for the region.
Currently we blow up with something like:

[ 2857.497462] kernel BUG at drivers/gpu/drm/i915/gt/intel_migrate.c:431!
[ 2857.497497] invalid opcode:  [#1] PREEMPT SMP NOPTI
[ 2857.497502] CPU: 1 PID: 8921 Comm: i915_selftest Tainted: G U  W 
5.18.0-rc1-drm-tip+ #27
[ 2857.497513] RIP: 0010:emit_pte.cold+0x11a/0x17e [i915]
[ 2857.497646] Code: 00 48 c7 c2 f0 cd c1 a0 48 c7 c7 e9 99 bd a0 e8 d2 77 5d 
e0 bf 01 00 00 00 e8 08 47 5d e0 31 f6 bf 09 00 00 00 e8 3c 7b 4d e0 <0f> 0b 48 
c7 c1 e0 2a c5 a0 ba 34 00 00 00 48 c7 c6 00 ce c1 a0 48
[ 2857.497654] RSP: 0018:c90f7748 EFLAGS: 00010246
[ 2857.497658] RAX:  RBX: c90f77c8 RCX: 0006
[ 2857.497662] RDX:  RSI:  RDI: 0009
[ 2857.497665] RBP:  R08: 0001 R09: 0001
[ 2857.497668] R10: 00022302 R11: 88846dea08f0 R12: 0001
[ 2857.497672] R13: 0188 R14: 081b R15: 888106b7c040
[ 2857.497675] FS:  7f0d4c4e0600() GS:88845da8() 
knlGS:
[ 2857.497679] CS:  0010 DS:  ES:  CR0: 80050033
[ 2857.497682] CR2: 7f113966c088 CR3: 000211e60003 CR4: 003706e0
[ 2857.497686] DR0:  DR1:  DR2: 
[ 2857.497689] DR3:  DR6: fffe0ff0 DR7: 0400
[ 2857.497692] Call Trace:
[ 2857.497694]  
[ 2857.497697]  intel_context_migrate_copy+0x1e5/0x4f0 [i915]

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Nirmoy Das 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 +++
 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 747ac65e060f..06b1b188ce5a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -606,6 +606,9 @@ bool i915_gem_object_can_migrate(struct drm_i915_gem_object 
*obj,
if (!mr)
return false;
 
+   if (!IS_ALIGNED(obj->base.size, mr->min_page_size))
+   return false;
+
if (obj->mm.region == mr)
return true;
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
index 6bd61b1f839c..801af51aff62 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
@@ -47,14 +47,16 @@ static int igt_create_migrate(struct intel_gt *gt, enum 
intel_region_id src,
 {
struct drm_i915_private *i915 = gt->i915;
struct intel_memory_region *src_mr = i915->mm.regions[src];
+   struct intel_memory_region *dst_mr = i915->mm.regions[dst];
struct drm_i915_gem_object *obj;
struct i915_gem_ww_ctx ww;
int err = 0;
 
GEM_BUG_ON(!src_mr);
+   GEM_BUG_ON(!dst_mr);
 
/* Switch object backing-store on create */
-   obj = i915_gem_object_create_region(src_mr, PAGE_SIZE, 0, 0);
+   obj = i915_gem_object_create_region(src_mr, dst_mr->min_page_size, 0, 
0);
if (IS_ERR(obj))
return PTR_ERR(obj);
 
-- 
2.34.1

[Intel-gfx] [CI 2/4] drm/i915/buddy: sanity check the size

[Matthew Auld]

Ensure we check that the size is compatible with the requested
page_size. For tiny objects that are automatically annotated with
TTM_PL_FLAG_CONTIGUOUS(since they fit within a single page), we
currently end up silently overriding the min_page_size, which ends up
hiding bugs elsewhere.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Nirmoy Das 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c 
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 8e4e3f72c1ef..a5109548abc0 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -70,6 +70,7 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
min_page_size = bo->page_alignment << PAGE_SHIFT;
 
GEM_BUG_ON(min_page_size < mm->chunk_size);
+   GEM_BUG_ON(!IS_ALIGNED(size, min_page_size));
 
if (place->fpfn + bman_res->base.num_pages != place->lpfn &&
place->flags & TTM_PL_FLAG_CONTIGUOUS) {
-- 
2.34.1

[Intel-gfx] [CI 4/4] drm/i915/selftests: tweak the misaligned_case

[Matthew Auld]

The compact-pt layout restrictions should only apply to the ppGTT. Also
make this play nice on platforms that only have the 64K GTT restriction,
and not the compact-pt thing.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Nirmoy Das 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index bccc49a8ab5e..8633bec18fa7 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1112,10 +1112,16 @@ static int misaligned_case(struct i915_address_space 
*vm, struct intel_memory_re
expected_vma_size = round_up(size, 1 << 
(ffs(vma->resource->page_sizes_gtt) - 1));
expected_node_size = expected_vma_size;
 
-   if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
-   /* compact-pt should expand lmem node to 2MB */
+   if (HAS_64K_PAGES(vm->i915) && i915_gem_object_is_lmem(obj)) {
+   /*
+* The compact-pt should expand lmem node to 2MB for the ppGTT,
+* for all other cases we should only expect 64K.
+*/
expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
-   expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+   if (NEEDS_COMPACT_PT(vm->i915) && !i915_is_ggtt(vm))
+   expected_node_size = round_up(size, 
I915_GTT_PAGE_SIZE_2M);
+   else
+   expected_node_size = round_up(size, 
I915_GTT_PAGE_SIZE_64K);
}
 
if (vma->size != expected_vma_size || vma->node.size != 
expected_node_size) {
-- 
2.34.1

[Intel-gfx] [CI 3/4] drm/i915/selftests: fixup min_alignment usage

[Matthew Auld]

Trying to cast the region id into the region type doesn't work too well,
since the i915_vm_min_alignment() won't give us the correct value for
the stolen-lmem case.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Nirmoy Das 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 5c9bfa409ff5..bccc49a8ab5e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1150,7 +1150,7 @@ static int misaligned_pin(struct i915_address_space *vm,
flags |= PIN_GLOBAL;
 
for_each_memory_region(mr, vm->i915, id) {
-   u64 min_alignment = i915_vm_min_alignment(vm, (enum 
intel_memory_type)id);
+   u64 min_alignment = i915_vm_min_alignment(vm, mr->type);
u64 size = min_alignment;
u64 addr = round_down(hole_start + (hole_size / 2), 
min_alignment);
 
-- 
2.34.1

Re: [Intel-gfx] [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

[Zack Rusin]

On Wed, 2022-04-20 at 19:40 +0200, Christian König wrote:
> 
> Am 20.04.22 um 19:38 schrieb Zack Rusin:
> > On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:
> > > ⚠ External Email
> > > 
> > > Hi Zack,
> > > 
> > > Am 20.04.22 um 05:56 schrieb Zack Rusin:
> > > > On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:
> > > > > Rework the internals of the dma_resv object to allow adding
> > > > > more
> > > > > than
> > > > > one
> > > > > write fence and remember for each fence what purpose it had.
> > > > > 
> > > > > This allows removing the workaround from amdgpu which used a
> > > > > container
> > > > > for
> > > > > this instead.
> > > > > 
> > > > > Signed-off-by: Christian König 
> > > > > Reviewed-by: Daniel Vetter 
> > > > > Cc: amd-...@lists.freedesktop.org
> > > > afaict this change broke vmwgfx which now kernel oops right
> > > > after
> > > > boot.
> > > > I haven't had the time to look into it yet, so I'm not sure
> > > > what's
> > > > the
> > > > problem. I'll look at this tomorrow, but just in case you have
> > > > some
> > > > clues, the backtrace follows:
> > > that's a known issue and should already be fixed with:
> > > 
> > > commit d72dcbe9fce505228dae43bef9da8f2b707d1b3d
> > > Author: Christian König 
> > > Date:   Mon Apr 11 15:21:59 2022 +0200
> > Unfortunately that doesn't seem to be it. The backtrace is from the
> > current (as of the time of sending of this email) drm-misc-next,
> > which
> > has this change, so it's something else.
> 
> Ok, that's strange. In this case I need to investigate further.
> 
> Maybe VMWGFX is adding more than one fence and we actually need to
> reserve multiple slots.

This might be helper code issue with CONFIG_DEBUG_MUTEXES set. On that config
dma_resv_reset_max_fences does: 
   fences->max_fences = fences->num_fences;
For some objects num_fences is 0 and so after max_fences and num_fences are 
both 0.
And then BUG_ON(num_fences >= max_fences) is triggered.

z

[Intel-gfx] [PATCH] drm/i915: Disable DC5 before going to DC9

[Rodrigo Vivi]

According to BSPec:
Sequence to Allow DC9:
1. Follow Sequence to Disallow DC5.

which is:
Sequence to Disallow DC5 and DC6
Set DC_STATE_EN Dynamic DC State Enable = "Disable".

I understand that we haven't had any issue so far. But since
DC9 is a software thing, it is better to disable DC5 before
to avoid any conflict. And respect the spec to avoid potential
future issues.

Cc: Imre Deak 
Cc: Anshuman Gupta 
Cc: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 6a5695008f7c..b3cf5182044f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -883,6 +883,9 @@ static void bxt_enable_dc9(struct drm_i915_private 
*dev_priv)
 {
assert_can_enable_dc9(dev_priv);
 
+   /* Disable DC5 before enabling DC9 */
+   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+
drm_dbg_kms(&dev_priv->drm, "Enabling DC9\n");
/*
 * Power sequencer reset is not needed on
-- 
2.34.1

Re: [Intel-gfx] [PATCH] drm/i915: Disable DC5 before going to DC9

[Srivatsa, Anusha]

> -Original Message-
> From: Vivi, Rodrigo 
> Sent: Wednesday, April 20, 2022 12:09 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vivi, Rodrigo ; Deak, Imre
> ; Gupta, Anshuman ;
> Srivatsa, Anusha 
> Subject: [PATCH] drm/i915: Disable DC5 before going to DC9
> 
> According to BSPec:
>   Sequence to Allow DC9:
>   1. Follow Sequence to Disallow DC5.
> 
> which is:
>   Sequence to Disallow DC5 and DC6
>   Set DC_STATE_EN Dynamic DC State Enable = "Disable".
> 
> I understand that we haven't had any issue so far. But since
> DC9 is a software thing, it is better to disable DC5 before to avoid any 
> conflict.
> And respect the spec to avoid potential future issues.
> 
> Cc: Imre Deak 
> Cc: Anshuman Gupta 
> Cc: Anusha Srivatsa 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 6a5695008f7c..b3cf5182044f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -883,6 +883,9 @@ static void bxt_enable_dc9(struct drm_i915_private
> *dev_priv)  {
>   assert_can_enable_dc9(dev_priv);

^ We are already checking if DC5 is enabled. If enabled then don't enable DC9. 
SO the change should be- if driver cannot enableDC9 because DC5 is enabled then 
go ahead and disable DC5.

Anusha 
> + /* Disable DC5 before enabling DC9 */
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> +
>   drm_dbg_kms(&dev_priv->drm, "Enabling DC9\n");
>   /*
>* Power sequencer reset is not needed on
> --
> 2.34.1

Re: [Intel-gfx] [PATCH] drm/i915: Disable DC5 before going to DC9

[Imre Deak]

On Wed, Apr 20, 2022 at 03:09:21PM -0400, Rodrigo Vivi wrote:
> According to BSPec:
>   Sequence to Allow DC9:
>   1. Follow Sequence to Disallow DC5.
> 
> which is:
>   Sequence to Disallow DC5 and DC6
>   Set DC_STATE_EN Dynamic DC State Enable = "Disable".
> 
> I understand that we haven't had any issue so far. But since
> DC9 is a software thing, it is better to disable DC5 before
> to avoid any conflict. And respect the spec to avoid potential
> future issues.
> 
> Cc: Imre Deak 
> Cc: Anshuman Gupta 
> Cc: Anusha Srivatsa 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 6a5695008f7c..b3cf5182044f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -883,6 +883,9 @@ static void bxt_enable_dc9(struct drm_i915_private 
> *dev_priv)
>  {
>   assert_can_enable_dc9(dev_priv);
>  
> + /* Disable DC5 before enabling DC9 */
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);

For DC9 DMC should be disabled already, along with DC states and other
dependencies like power well 1, etc. That happens in
bxt/icl_display_core_uninit().

> +
>   drm_dbg_kms(&dev_priv->drm, "Enabling DC9\n");
>   /*
>* Power sequencer reset is not needed on
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH] drm/i915: Disable DC5 before going to DC9

[Rodrigo Vivi]

On Wed, Apr 20, 2022 at 10:21:19PM +0300, Imre Deak wrote:
> On Wed, Apr 20, 2022 at 03:09:21PM -0400, Rodrigo Vivi wrote:
> > According to BSPec:
> > Sequence to Allow DC9:
> > 1. Follow Sequence to Disallow DC5.
> > 
> > which is:
> > Sequence to Disallow DC5 and DC6
> > Set DC_STATE_EN Dynamic DC State Enable = "Disable".
> > 
> > I understand that we haven't had any issue so far. But since
> > DC9 is a software thing, it is better to disable DC5 before
> > to avoid any conflict. And respect the spec to avoid potential
> > future issues.
> > 
> > Cc: Imre Deak 
> > Cc: Anshuman Gupta 
> > Cc: Anusha Srivatsa 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 6a5695008f7c..b3cf5182044f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -883,6 +883,9 @@ static void bxt_enable_dc9(struct drm_i915_private 
> > *dev_priv)
> >  {
> > assert_can_enable_dc9(dev_priv);
> >  
> > +   /* Disable DC5 before enabling DC9 */
> > +   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> 
> For DC9 DMC should be disabled already, along with DC states and other
> dependencies like power well 1, etc. That happens in
> bxt/icl_display_core_uninit().

but that wasn't on the suspend_late path... but Anusha is right and
probably the check in the assert is already enough for now... if we
notice that assert is coming we do something else...

I was willing to avoid indirection and the risk of changing something
and this dc5 disable getting forgotten, but with the assert we are
probably good...

let's just ignore this patch...

> 
> > +
> > drm_dbg_kms(&dev_priv->drm, "Enabling DC9\n");
> > /*
> >  * Power sequencer reset is not needed on
> > -- 
> > 2.34.1
> > 

Re: [Intel-gfx] [PATCH 03/15] dma-buf & drm/amdgpu: remove dma_resv workaround

[Zack Rusin]

On Wed, 2022-04-20 at 20:56 +0200, Christian König wrote:
> ⚠ External Email
> 
> Am 20.04.22 um 20:49 schrieb Christian König:
> > Am 20.04.22 um 20:41 schrieb Zack Rusin:
> > > On Wed, 2022-04-20 at 19:40 +0200, Christian König wrote:
> > > > Am 20.04.22 um 19:38 schrieb Zack Rusin:
> > > > > On Wed, 2022-04-20 at 09:37 +0200, Christian König wrote:
> > > > > > ⚠ External Email
> > > > > > 
> > > > > > Hi Zack,
> > > > > > 
> > > > > > Am 20.04.22 um 05:56 schrieb Zack Rusin:
> > > > > > > On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:
> > > > > > > > Rework the internals of the dma_resv object to allow
> > > > > > > > adding
> > > > > > > > more
> > > > > > > > than
> > > > > > > > one
> > > > > > > > write fence and remember for each fence what purpose it
> > > > > > > > had.
> > > > > > > > 
> > > > > > > > This allows removing the workaround from amdgpu which
> > > > > > > > used a
> > > > > > > > container
> > > > > > > > for
> > > > > > > > this instead.
> > > > > > > > 
> > > > > > > > Signed-off-by: Christian König
> > > > > > > > 
> > > > > > > > Reviewed-by: Daniel Vetter 
> > > > > > > > Cc: amd-...@lists.freedesktop.org
> > > > > > > afaict this change broke vmwgfx which now kernel oops
> > > > > > > right
> > > > > > > after
> > > > > > > boot.
> > > > > > > I haven't had the time to look into it yet, so I'm not
> > > > > > > sure
> > > > > > > what's
> > > > > > > the
> > > > > > > problem. I'll look at this tomorrow, but just in case you
> > > > > > > have
> > > > > > > some
> > > > > > > clues, the backtrace follows:
> > > > > > that's a known issue and should already be fixed with:
> > > > > > 
> > > > > > commit d72dcbe9fce505228dae43bef9da8f2b707d1b3d
> > > > > > Author: Christian König 
> > > > > > Date:   Mon Apr 11 15:21:59 2022 +0200
> > > > > Unfortunately that doesn't seem to be it. The backtrace is
> > > > > from the
> > > > > current (as of the time of sending of this email) drm-misc-
> > > > > next,
> > > > > which
> > > > > has this change, so it's something else.
> > > > Ok, that's strange. In this case I need to investigate further.
> > > > 
> > > > Maybe VMWGFX is adding more than one fence and we actually need
> > > > to
> > > > reserve multiple slots.
> > > This might be helper code issue with CONFIG_DEBUG_MUTEXES set. On
> > > that config
> > > dma_resv_reset_max_fences does:
> > >     fences->max_fences = fences->num_fences;
> > > For some objects num_fences is 0 and so after max_fences and
> > > num_fences are both 0.
> > > And then BUG_ON(num_fences >= max_fences) is triggered.
> > 
> > Yeah, but that's expected behavior.
> > 
> > What's not expected is that max_fences is still 0 (or equal to old
> > num_fences) when VMWGFX tries to add a new fence. The function
> > ttm_eu_reserve_buffers() should have reserved at least one fence
> > slot.
> > 
> > So the underlying problem is that either ttm_eu_reserve_buffers()
> > was
> > never called or VMWGFX tried to add more than one fence.
> 
> 
> To figure out what it is could you try the following code fragment:
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> index f46891012be3..a36f89d3f36d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> @@ -288,7 +288,7 @@ int vmw_validation_add_bo(struct
> vmw_validation_context *ctx,
>  val_buf->bo = ttm_bo_get_unless_zero(&vbo->base);
>  if (!val_buf->bo)
>  return -ESRCH;
> -   val_buf->num_shared = 0;
> +   val_buf->num_shared = 16;
>  list_add_tail(&val_buf->head, &ctx->bo_list);
>  bo_node->as_mob = as_mob;
>  bo_node->cpu_blit = cpu_blit;

Fails the same BUG_ON with num_fences and max_fences == 0.

z

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs

[Andrzej Hajda]

On 20.04.2022 18:12, Dixit, Ashutosh wrote:

On Wed, 20 Apr 2022 05:17:57 -0700, Andrzej Hajda wrote:

Hi Ashutosh,

Hi Andrzej,


On 20.04.2022 07:21, Ashutosh Dixit wrote:

All kmalloc'd kobjects need a kobject_put() to free memory. For example in
previous code, kobj_gt_release() never gets called. The requirement of
kobject_put() now results in a slightly different code organization.

Cc: Andi Shyti 
Cc: Andrzej Hajda 
Cc: Rodrigo Vivi 
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")

/snip/


+void intel_gt_sysfs_unregister(struct intel_gt *gt)
+{
+   kobject_put(>->sysfs_gtn);
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
index 9471b26752cf..a99aa7e8b01a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
@@ -13,11 +13,6 @@
 struct intel_gt;
   -struct kobj_gt {
-   struct kobject base;
-   struct intel_gt *gt;
-};
-
   bool is_object_gt(struct kobject *kobj);
 struct drm_i915_private *kobj_to_i915(struct kobject *kobj);
@@ -28,6 +23,7 @@ intel_gt_create_kobj(struct intel_gt *gt,
 const char *name);
 void intel_gt_sysfs_register(struct intel_gt *gt);
+void intel_gt_sysfs_unregister(struct intel_gt *gt);
   struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
const char *name);
   diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 937b2e1a305e..4c72b4f983a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -222,6 +222,9 @@ struct intel_gt {
} mocs;
struct intel_pxp pxp;
+
+   /* gt/gtN sysfs */
+   struct kobject sysfs_gtn;

If you put kobject as a part of intel_gt what assures you that lifetime of
kobject is shorter than intel_gt? Ie its refcounter is 0 on removal of
intel_gt?

Because we are explicitly doing a kobject_put() in
intel_gt_sysfs_unregister(). Which is exactly what we are *not* doing in
the previous code.

Let me explain a bit about the previous code (but feel free to skip since
the patch should speak for itself):
* Previously we kzalloc a 'struct kobj_gt'
* But we don't save a pointer to the 'struct kobj_gt' so we don't have the
   pointer to the kobject to be able to do a kobject_put() on it later
* Therefore we need to store the pointer in 'struct intel_gt'
* But if we have to put the pointer in 'struct intel_gt' we might as well
   put the kobject as part of 'struct intel_gt' and that also removes the
   need to have a 'struct kobj_gt' (kobj_to_gt() can just use container_of()
   to get gt from kobj).
* So I think this patch simpler/cleaner than the original code if you take
   the requirement for kobject_put() into account.


I fully agree that previous code is incorrect but I am not convinced 
current code is correct.
If some objects are kref-counted it means usually they can have multiple 
concurrent users and kobject_put does not work as traditional 
destructor/cleanup/unregister.
So in this particular case after calling kobject_init_and_add sysfs core 
can get multiple references on the object. Later, during driver 
unregistration kobject_put is called, but if the object is still in use 
by sysfs core, the object will not be destroyed/released. If the driver 
unregistration continues memory will be freed, leaving sysfs-core (or 
other users) with dangling pointers. Unless there is some additional 
synchronization mechanism I am not aware of.


Regards
Andrzej


Thanks.
--
Ashutosh

Re: [Intel-gfx] [RFC v2 2/2] drm/doc/rfc: VM_BIND uapi definition

[Niranjana Vishwanathapura]

On Wed, Mar 30, 2022 at 02:51:41PM +0200, Daniel Vetter wrote:

On Mon, Mar 07, 2022 at 12:31:46PM -0800, Niranjana Vishwanathapura wrote:

VM_BIND und related uapi definitions

Signed-off-by: Niranjana Vishwanathapura 
---
 Documentation/gpu/rfc/i915_vm_bind.h | 176 +++


Maybe as the top level comment: The point of documenting uapi isn't to
just spell out all the fields, but to define _how_ and _why_ things work.
This part is completely missing from these docs here.



Thanks Daniel,

Some of the documentation is in the rst file.
Ok, will add documentation here on _how and _why_.


 1 file changed, 176 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h 
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..80f00ee6c8a1
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h


You need to incldue this somewhere so it's rendered, see the previous
examples.


Looking at previous examples, my understanding is this is just a documentation
file at this point which goes into Documentation/gpu/rfc folder and will have to
remove it later once the actual uapi changes lands in 
include/uapi/drm/i915_drm.h.
Let me know if that is incorrect and needs change.




@@ -0,0 +1,176 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/* VM_BIND feature availability through drm_i915_getparam */
+#define I915_PARAM_HAS_VM_BIND 57


Needs to be kernel-docified, which means we need a prep patch that fixes
up the existing mess.



Ok on kernel-doc, but as mentioned above, I am not sure we need prep
patch that fixes up other existing fields at this point.


+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND   0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_WAIT_USER_FENCE   0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object/buffer mapping to [un]bind.


Both binding and unbinding need to specify in excruciating detail what
happens if there's overlaps (existing mappings, or unmapping a range which
has no mapping, or only partially full of maps or different objects) and
fun stuff like that.



Ok, will add those details.


+ */
+struct drm_i915_gem_vm_bind {
+   /** vm to [un]bind */
+   __u32 vm_id;
+
+   /**
+* BO handle or file descriptor.
+* 'fd' value of -1 is reserved for system pages (SVM)
+*/
+   union {
+   __u32 handle; /* For unbind, it is reserved and must be 0 */


I think it'd be a lot cleaner if we do a bind and an unbind struct for
these, instead of mixing it up.



Ok


Also I thought mesa requested to be able to unmap an object from a vm
without a range. Has that been dropped, and confirmed to not be needed.



Hmm...I think it was other way around. ie., to unmap with a range in vm
but without an object. We already support that.


+   __s32 fd;


If we don't need it right away then don't add it yet. If it's planned to
be used then it needs to be documented, but I kinda have no idea why you'd
need an fd for svm?



It is not required for SVM, it was intended for future expanstions and '-1'
was reserved for SVM.
Ok, will remove it for now.


+   }
+
+   /** VA start to [un]bind */
+   __u64 start;
+
+   /** Offset in object to [un]bind */
+   __u64 offset;
+
+   /** VA length to [un]bind */
+   __u64 length;
+
+   /** Flags */
+   __u64 flags;
+   /** Bind the mapping immediately instead of during next submission */


This aint kerneldoc.

Also this needs to specify in much more detail what exactly this means,
and also how it interacts with execbuf.



Ok


So the patch here probably needs to include the missing pieces on the
execbuf side of things. Like how does execbuf work when it's used with a
vm_bind managed vm? That means:
- document the pieces that are there
- then add a patch to document how that all changes with vm_bind


Hmm, I am bit confused. The current execbuff handling documentation is in
i915_gem_execbuffer.c. Not sure how to update it in this design RFC patch.
With VM_BIND support, we only support vm_bind vmas in the execbuff and
based on comments from other patch in this series, we probably should not
allow any execlist entries in vm_bind mode (no implicit syncing and use
an extension for the batch address). May be I can update the rst file
in this series for these information for now. Thoughts?



And do that for everything execbuf can do.


+#define I915_GEM_VM_BIND_IMMEDIATE   (1 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/doc: add rfc section for small BAR uapi

[Patchwork]

== Series Details ==

Series: drm/doc: add rfc section for small BAR uapi
URL   : https://patchwork.freedesktop.org/series/102875/
State : warning

== Summary ==

Error: dim checkpatch failed
778440992ee2 drm/doc: add rfc section for small BAR uapi
-:28: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#28: 
new file mode 100644

-:33: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#33: FILE: Documentation/gpu/rfc/i915_small_bar.h:1:
+/**

-:218: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#218: FILE: Documentation/gpu/rfc/i915_small_bar.h:186:
+#define DRM_I915_QUERY_VMA_INFO_CPU_VISIBLE (1<<0)
   ^

-:229: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#229: FILE: Documentation/gpu/rfc/i915_small_bar.rst:1:
+==

total: 0 errors, 3 warnings, 1 checks, 255 lines checked

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/doc: add rfc section for small BAR uapi

[Patchwork]

== Series Details ==

Series: drm/doc: add rfc section for small BAR uapi
URL   : https://patchwork.freedesktop.org/series/102875/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11528 -> Patchwork_102875v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102875v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102875v1, 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_102875v1/index.html

Participating hosts (46 -> 46)
--

  Additional (2): fi-cml-u2 fi-icl-u2 
  Missing(2): fi-bsw-cyan bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cml-u2:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-cml-u2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-cml-u2:  NOTRUN -> [SKIP][2] ([i915#1208]) +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][3] ([i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2:  NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#3282])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3012])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][12] -> [DMESG-FAIL][13] ([i915#4494] / 
[i915#4957])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-cml-u2:  NOTRUN -> [SKIP][15] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-cml-u2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  NOTRUN -> [SKIP][16] ([fdo#111827]) +8 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#4070] / [i915#4103]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-cml-u2:  NOTRUN -> [SKIP][18] ([fdo#109278]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: consider min_page_size when migrating

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915: consider min_page_size when 
migrating
URL   : https://patchwork.freedesktop.org/series/102879/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11528 -> Patchwork_102879v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (46 -> 44)
--

  Missing(2): fi-bsw-cyan bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] / 
[i915#4957])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#4070] / [i915#4103]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([fdo#109285] / [i915#4098])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#4070] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4098])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#3301] / [i915#3708])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  * igt@prime_vgem@basic-write:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#3291] / [i915#3708]) +2 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@prime_v...@basic-write.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   [INCOMPLETE][17] ([i915#5127]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_mocs:
- fi-rkl-guc: [DMESG-WARN][19] -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/fi-rkl-guc/igt@i915_selftest@live@gt_mocs.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/fi-rkl-guc/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@reset:

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Disable DC5 before going to DC9

[Patchwork]

== Series Details ==

Series: drm/i915: Disable DC5 before going to DC9
URL   : https://patchwork.freedesktop.org/series/102881/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/102881/revisions/1/mbox/ not 
applied
Applying: drm/i915: Disable DC5 before going to DC9
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_display_power.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_display_power.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/display/intel_display_power.c
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/i915: Disable DC5 before going to DC9
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".

Re: [Intel-gfx] [RFC v2 1/2] drm/doc/rfc: VM_BIND feature design document

[Niranjana Vishwanathapura]

On Thu, Mar 31, 2022 at 10:28:48AM +0200, Daniel Vetter wrote:

Adding a pile of people who've expressed interest in vm_bind for their
drivers.

Also note to the intel folks: This is largely written with me having my
subsystem co-maintainer hat on, i.e. what I think is the right thing to do
here for the subsystem at large. There is substantial rework involved
here, but it's not any different from i915 adopting ttm or i915 adpoting
drm/sched, and I do think this stuff needs to happen in one form or
another.

On Mon, Mar 07, 2022 at 12:31:45PM -0800, Niranjana Vishwanathapura wrote:

VM_BIND design document with description of intended use cases.

Signed-off-by: Niranjana Vishwanathapura 
---
 Documentation/gpu/rfc/i915_vm_bind.rst | 210 +
 Documentation/gpu/rfc/index.rst|   4 +
 2 files changed, 214 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst

diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
b/Documentation/gpu/rfc/i915_vm_bind.rst
new file mode 100644
index ..cdc6bb25b942
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.rst
@@ -0,0 +1,210 @@
+==
+I915 VM_BIND feature design and use cases
+==
+
+VM_BIND feature
+
+DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
+objects (BOs) or sections of a BOs at specified GPU virtual addresses on
+a specified address space (VM).
+
+These mappings (also referred to as persistent mappings) will be persistent
+across multiple GPU submissions (execbuff) issued by the UMD, without user
+having to provide a list of all required mappings during each submission
+(as required by older execbuff mode).
+
+VM_BIND ioctl deferes binding the mappings until next execbuff submission
+where it will be required, or immediately if I915_GEM_VM_BIND_IMMEDIATE
+flag is set (useful if mapping is required for an active context).


So this is a screw-up I've done, and for upstream I think we need to fix
it: Implicit sync is bad, and it's also still a bad idea for vm_bind, and
I was wrong suggesting we should do this a few years back when we kicked
this off internally :-(

What I think we need is just always VM_BIND_IMMEDIATE mode, and then a few
things on top:
- in and out fences, like with execbuf, to allow userspace to sync with
 execbuf as needed
- for compute-mode context this means userspace memory fences
- for legacy context this means a timeline syncobj in drm_syncobj

No sync_file or anything else like this at all. This means a bunch of
work, but also it'll have benefits because it means we should be able to
use exactly the same code paths and logic for both compute and for legacy
context, because drm_syncobj support future fence semantics.



Thanks Daniel,
Ok, will update


Also on the implementation side we still need to install dma_fence to the
various dma_resv, and for this we need the new dma_resv_usage series from
Christian König first. vm_bind fences can then use the USAGE_BOOKKEEPING
flag to make sure they never result in an oversync issue with execbuf. I
don't think trying to land vm_bind without that prep work in
dma_resv_usage makes sense.



Ok, but that is not a dependency for this VM_BIND design RFC patch right?
I will add this to the documentation here.


Also as soon as dma_resv_usage has landed there's a few cleanups we should
do in i915:
- ttm bo moving code should probably simplify a bit (and maybe more of the
 code should be pushed as helpers into ttm)
- clflush code should be moved over to using USAGE_KERNEL and the various
 hacks and special cases should be ditched. See df94fd05e69e ("drm/i915:
 expand on the kernel-doc for cache_dirty") for a bit more context

This is still not yet enough, since if a vm_bind races with an eviction we
might stall on the new buffers being readied first before the context can
continue. This needs some care to make sure that vma which aren't fully
bound yet are on a separate list, and vma which are marked for unbinding
are removed from the main working set list as soon as possible.

All of these things are relevant for the uapi semantics, which means
- they need to be documented in the uapi kerneldoc, ideally with example
 flows
- umd need to ack this



Ok


The other thing here is the async/nonblocking path. I think we still need
that one, but again it should not sync with anything going on in execbuf,
but simply execute the ioctl code in a kernel thread. The idea here is
that this works like a special gpu engine, so that compute and vk can
schedule bindings interleaved with rendering. This should be enough to get
a performant vk sparse binding/textures implementation.

But I'm not entirely sure on this one, so this definitely needs acks from
umds.


+VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND.
+User has to opt-in for VM_BIND mode of binding for an address space (VM)
+during VM creation time via I915_VM_CREATE

Re: [Intel-gfx] [RFC v2 1/2] drm/doc/rfc: VM_BIND feature design document

[Niranjana Vishwanathapura]

On Thu, Mar 31, 2022 at 01:37:08PM +0200, Daniel Vetter wrote:

One thing I've forgotten, since it's only hinted at here: If/when we
switch tlb flushing from the current dumb&synchronous implementation
we now have in i915 in upstream to one with batching using dma_fence,
then I think that should be something which is done with a small
helper library of shared code too. The batching is somewhat tricky,
and you need to make sure you put the fence into the right
dma_resv_usage slot, and the trick with replace the vm fence with a
tlb flush fence is also a good reason to share the code so we only
have it one.

Christian's recent work also has some prep work for this already with
the fence replacing trick.


Sure, but this optimization is not required for initial vm_bind support
to land right? We can look at it soon after that. Is that ok?
I have made a reference to this TLB flush batching work in the rst file.

Niranjana


-Daniel

On Thu, 31 Mar 2022 at 10:28, Daniel Vetter  wrote:

Adding a pile of people who've expressed interest in vm_bind for their
drivers.

Also note to the intel folks: This is largely written with me having my
subsystem co-maintainer hat on, i.e. what I think is the right thing to do
here for the subsystem at large. There is substantial rework involved
here, but it's not any different from i915 adopting ttm or i915 adpoting
drm/sched, and I do think this stuff needs to happen in one form or
another.

On Mon, Mar 07, 2022 at 12:31:45PM -0800, Niranjana Vishwanathapura wrote:
> VM_BIND design document with description of intended use cases.
>
> Signed-off-by: Niranjana Vishwanathapura 
> ---
>  Documentation/gpu/rfc/i915_vm_bind.rst | 210 +
>  Documentation/gpu/rfc/index.rst|   4 +
>  2 files changed, 214 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
>
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
b/Documentation/gpu/rfc/i915_vm_bind.rst
> new file mode 100644
> index ..cdc6bb25b942
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.rst
> @@ -0,0 +1,210 @@
> +==
> +I915 VM_BIND feature design and use cases
> +==
> +
> +VM_BIND feature
> +
> +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
> +objects (BOs) or sections of a BOs at specified GPU virtual addresses on
> +a specified address space (VM).
> +
> +These mappings (also referred to as persistent mappings) will be persistent
> +across multiple GPU submissions (execbuff) issued by the UMD, without user
> +having to provide a list of all required mappings during each submission
> +(as required by older execbuff mode).
> +
> +VM_BIND ioctl deferes binding the mappings until next execbuff submission
> +where it will be required, or immediately if I915_GEM_VM_BIND_IMMEDIATE
> +flag is set (useful if mapping is required for an active context).

So this is a screw-up I've done, and for upstream I think we need to fix
it: Implicit sync is bad, and it's also still a bad idea for vm_bind, and
I was wrong suggesting we should do this a few years back when we kicked
this off internally :-(

What I think we need is just always VM_BIND_IMMEDIATE mode, and then a few
things on top:
- in and out fences, like with execbuf, to allow userspace to sync with
  execbuf as needed
- for compute-mode context this means userspace memory fences
- for legacy context this means a timeline syncobj in drm_syncobj

No sync_file or anything else like this at all. This means a bunch of
work, but also it'll have benefits because it means we should be able to
use exactly the same code paths and logic for both compute and for legacy
context, because drm_syncobj support future fence semantics.

Also on the implementation side we still need to install dma_fence to the
various dma_resv, and for this we need the new dma_resv_usage series from
Christian König first. vm_bind fences can then use the USAGE_BOOKKEEPING
flag to make sure they never result in an oversync issue with execbuf. I
don't think trying to land vm_bind without that prep work in
dma_resv_usage makes sense.

Also as soon as dma_resv_usage has landed there's a few cleanups we should
do in i915:
- ttm bo moving code should probably simplify a bit (and maybe more of the
  code should be pushed as helpers into ttm)
- clflush code should be moved over to using USAGE_KERNEL and the various
  hacks and special cases should be ditched. See df94fd05e69e ("drm/i915:
  expand on the kernel-doc for cache_dirty") for a bit more context

This is still not yet enough, since if a vm_bind races with an eviction we
might stall on the new buffers being readied first before the context can
continue. This needs some care to make sure that vma which aren't fully
bound yet are on a separate list, and vma which are marked for unbinding
are removed from the main working set list as soon as possible.

All of these things are rel

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915: consider min_page_size when migrating

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915: consider min_page_size when 
migrating
URL   : https://patchwork.freedesktop.org/series/102879/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11528_full -> Patchwork_102879v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_102879v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_102879v1_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 -> 11)
--

  Additional (1): shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_sseu@full-enable:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-skl9/igt@i915_pm_s...@full-enable.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-skl7/igt@i915_pm_s...@full-enable.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([FAIL][3], [PASS][4], [PASS][5], [PASS][6], 
[PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], 
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], 
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], 
[PASS][25], [PASS][26], [PASS][27]) ([i915#4386]) -> ([PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl1/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl2/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl2/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl3/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl3/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl3/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl4/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl6/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11528/shard-apl8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl7/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl7/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102879v1/shard-apl6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm

Re: [Intel-gfx] [RFC v2 1/2] drm/doc/rfc: VM_BIND feature design document

[Niranjana Vishwanathapura]

On Wed, Mar 09, 2022 at 10:58:09AM -0500, Alex Deucher wrote:

On Mon, Mar 7, 2022 at 3:30 PM Niranjana Vishwanathapura
 wrote:


VM_BIND design document with description of intended use cases.

Signed-off-by: Niranjana Vishwanathapura 
---
 Documentation/gpu/rfc/i915_vm_bind.rst | 210 +
 Documentation/gpu/rfc/index.rst|   4 +
 2 files changed, 214 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst

diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
b/Documentation/gpu/rfc/i915_vm_bind.rst
new file mode 100644
index ..cdc6bb25b942
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.rst
@@ -0,0 +1,210 @@
+==
+I915 VM_BIND feature design and use cases
+==
+
+VM_BIND feature
+
+DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
+objects (BOs) or sections of a BOs at specified GPU virtual addresses on
+a specified address space (VM).
+
+These mappings (also referred to as persistent mappings) will be persistent
+across multiple GPU submissions (execbuff) issued by the UMD, without user
+having to provide a list of all required mappings during each submission
+(as required by older execbuff mode).
+
+VM_BIND ioctl deferes binding the mappings until next execbuff submission
+where it will be required, or immediately if I915_GEM_VM_BIND_IMMEDIATE
+flag is set (useful if mapping is required for an active context).
+
+VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND.
+User has to opt-in for VM_BIND mode of binding for an address space (VM)
+during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
+A VM in VM_BIND mode will not support older execbuff mode of binding.
+
+UMDs can still send BOs of these persistent mappings in execlist of execbuff
+for specifying BO dependencies (implicit fencing) and to use BO as a batch,
+but those BOs should be mapped ahead via vm_bind ioctl.
+
+VM_BIND features include,
+- Multiple Virtual Address (VA) mappings can map to the same physical pages
+  of an object (aliasing).
+- VA mapping can map to a partial section of the BO (partial binding).
+- Support capture of persistent mappings in the dump upon GPU error.
+- TLB is flushed upon unbind completion. Batching of TLB flushes in some
+  usecases will be helpful.
+- Asynchronous vm_bind and vm_unbind support.
+- VM_BIND uses user/memory fence mechanism for signaling bind completion
+  and for signaling batch completion in long running contexts (explained
+  below).
+
+VM_PRIVATE objects
+--
+By default, BOs can be mapped on multiple VMs and can also be dma-buf
+exported. Hence these BOs are referred to as Shared BOs.
+During each execbuff submission, the request fence must be added to the
+dma-resv fence list of all shared BOs mapped on the VM.
+
+VM_BIND feature introduces an optimization where user can create BO which
+is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during
+BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on
+the VM they are private to and can't be dma-buf exported.
+All private BOs of a VM share the dma-resv object. Hence during each execbuff
+submission, they need only one dma-resv fence list updated. Thus the fast
+path (where required mappings are already bound) submission latency is O(1)
+w.r.t the number of VM private BOs.
+
+VM_BIND locking hirarchy
+-
+VM_BIND locking order is as below.
+
+1) A vm_bind mutex will protect vm_bind lists. This lock is taken in vm_bind/
+   vm_unbind ioctl calls, in the execbuff path and while releasing the mapping.
+
+   In future, when GPU page faults are supported, we can potentially use a
+   rwsem instead, so that multiple pagefault handlers can take the read side
+   lock to lookup the mapping and hence can run in parallel.
+
+2) The BO's dma-resv lock will protect i915_vma state and needs to be held
+   while binding a vma and while updating dma-resv fence list of a BO.
+   The private BOs of a VM will all share a dma-resv object.
+
+   This lock is held in vm_bind call for immediate binding, during vm_unbind
+   call for unbinding and during execbuff path for binding the mapping and
+   updating the dma-resv fence list of the BO.
+
+3) Spinlock/s to protect some of the VM's lists.
+
+We will also need support for bluk LRU movement of persistent mapping to
+avoid additional latencies in execbuff path.
+
+GPU page faults
+
+Both older execbuff mode and the newer VM_BIND mode of binding will require
+using dma-fence to ensure residency.
+In future when GPU page faults are supported, no dma-fence usage is required
+as residency is purely managed by installing and removing/invalidating ptes.
+
+
+User/Memory Fence
+==
+The idea is to take a user specified virtual address and install an interrupt
+handler to wake up the current task when the m

Re: [Intel-gfx] [PULL v2] gvt-next

[Wang, Zhi A]

On 4/20/22 8:00 PM, Jason Gunthorpe wrote:
> On Wed, Apr 20, 2022 at 02:46:00PM -0300, Jason Gunthorpe wrote:
>> On Wed, Apr 20, 2022 at 11:40:33AM -0600, Alex Williamson wrote:
>>> On Wed, 20 Apr 2022 13:43:51 -0300
>>> Jason Gunthorpe  wrote:
>>>
 On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> Hi folks:
>
> Here is the PR of gvt-next. Thanks so much for the patience.
>
> Mostly it includes the patch bundle of GVT-g re-factor patches for 
> adapting the GVT-g with the
> new MDEV interfaces:
>
> - Separating the MMIO table from GVT-g. (Zhi)
> - GVT-g re-factor. (Christoph)
> - GVT-g mdev API cleanup. (Jason)
> - GVT-g trace/makefile cleanup. (Jani)
>
> Thanks so much for making this happen.
>
> This PR has been tested as following and no problem shows up:
>
> $dim update-branches
> $dim apply-pull drm-intel-next < this_email.eml
>
> The following changes since commit 
> 3123109284176b1532874591f7c81f3837bbdc17:
>
>   Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
>
> are available in the Git repository at:
>
>   https://github.com/intel/gvt-linux 
> tags/gvt-next-2022-04-20-for-christoph
>
> for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e:
>
>   vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400)  

 This looks well constructed now! thanks

 Alex you can pull this for VFIO after Jani&co grab it

 I'll respin my vfio_group series on top of this branch
>>>
>>> Sure, so just to confirm tags/gvt-next-2022-04-20-for-christoph is
>>> pruned down to exactly the commits we're looking for now?  Thanks,
>>
>> Yes, the above is correct and the tag points to commit
>> ae7875879b7c838bffb42ed6db4658e5c504032e
>>
>> It is the bare minimum series
> 
> Actually this topic branch doesn't compile:
> 
> ../drivers/gpu/drm/i915/intel_gvt_mmio_table.c:7:10: fatal error: 
> 'display/intel_dmc_regs.h' file not found
> #include "display/intel_dmc_regs.h"
>  ^~
> 1 error generated.
> 
> :( :(
> 
> This is the merge conflict that was mentioned. This topic branch needs
> to delete the above intel_dmc_regs.h include file
> 
> When drm-intel-next merges this PR then need to add it back as part of
> the merge resolution - so explain this in the PR text above and
> include a diff that does it when you send it again. (or do the merge
> yourself as I showed before, it depends on what drm-intel-next wants)
> 
Hi Jason:

Is it possible that I can send two different pull based on the same branch?
I was thinking I can remove this line in the original patch and then add a
small patch to add this line back on the top. Then make two different tags
before and after that small patch, send one pull with tag that includes that
small patch to i915 and the other pull with tag that doesn't includes it to
VFIO?

Thanks,
Zhi.

> Jason
> 

[Intel-gfx] [RFC PATCH 0/3] i915 writeback private framework

[Suraj Kandpal]

A patch series was floated in the drm mailing list which aimed to change
the drm_connector and drm_encoder fields to pointer in the
drm_connector_writeback structure, this received a huge pushback from
the community but since i915 expects each connector present in the
drm_device list to be a intel_connector but drm_writeback framework.
[1] 
https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/
[2] 
https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/
This forces us to use a drm_connector which is not embedded in
intel_connector the current drm_writeback framework becomes very
unfeasible to us as it would mean a lot of checks at a lot of places
to take into account the above issue.Since no one had an issue with
encoder field being changed into a pointer it was decided to break the
connector and encoder pointer changes into two different series.The
encoder field changes is currently being worked upon by Abhinav Kumar
[3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565
In the meantime for i915 to start using the writeback functionality we
came up with a interim solution to own writeback pipeline bypassing one
provided by drm which is what these patches do.
Note: these are temp patches till we figure out how we can either change
drm core writeback to work with our intel_connector structure or find a
different solution which allows us to work with the current
drm_writeback framework

Suraj Kandpal (3):
  drm/i915: Creating writeback pipeline to bypass drm_writeback
framework
  drm/i915: Define WD trancoder for i915
  drm/i915: Enabling WD Transcoder

 drivers/gpu/drm/i915/Makefile |   2 +
 drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  89 +-
 drivers/gpu/drm/i915/display/intel_display.h  |  15 +
 .../drm/i915/display/intel_display_types.h|  18 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   3 +
 drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
 .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++
 .../gpu/drm/i915/display/intel_wb_connector.h |  99 ++
 drivers/gpu/drm/i915/display/intel_wd.c   | 978 ++
 drivers/gpu/drm/i915/display/intel_wd.h   |  82 ++
 drivers/gpu/drm/i915/i915_drv.h   |   5 +
 drivers/gpu/drm/i915/i915_irq.c   |   8 +-
 drivers/gpu/drm/i915/i915_pci.c   |   7 +-
 drivers/gpu/drm/i915/i915_reg.h   | 139 +++
 15 files changed, 1742 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h

-- 
2.35.1

[Intel-gfx] [RFC PATCH 1/3] drm/i915: Creating writeback pipeline to bypass drm_writeback framework

[Suraj Kandpal]

Changes to create a i915 private pipeline to enable the WD transcoder
without relying on the current drm_writeback framework.

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../drm/i915/display/intel_display_types.h|   4 +
 .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++
 .../gpu/drm/i915/display/intel_wb_connector.h |  99 ++
 drivers/gpu/drm/i915/i915_drv.h   |   3 +
 5 files changed, 403 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1a771ee5b1d0..087bd9d1b397 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -286,6 +286,7 @@ i915-y += \
display/intel_tv.o \
display/intel_vdsc.o \
display/intel_vrr.o \
+   display/intel_wb_connector.o\
display/vlv_dsi.o \
display/vlv_dsi_pll.o
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d84e82f3eab9..7a96ecba73c0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -52,6 +52,7 @@
 #include "intel_display_power.h"
 #include "intel_dpll_mgr.h"
 #include "intel_pm_types.h"
+#include "intel_wb_connector.h"
 
 struct drm_printer;
 struct __intel_global_objs_state;
@@ -537,11 +538,14 @@ struct intel_connector {
struct work_struct modeset_retry_work;
 
struct intel_hdcp hdcp;
+
+   struct intel_writeback_connector wb_conn;
 };
 
 struct intel_digital_connector_state {
struct drm_connector_state base;
 
+   struct intel_writeback_job *job;
enum hdmi_force_audio force_audio;
int broadcast_rgb;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_wb_connector.c 
b/drivers/gpu/drm/i915/display/intel_wb_connector.c
new file mode 100644
index ..65f4abef53d0
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_wb_connector.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright © 2022 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Suraj Kandpal 
+ * Arun Murthy 
+ *
+ */
+
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "intel_wb_connector.h"
+#include "intel_display_types.h"
+
+#define fence_to_wb_connector(x) container_of(x->lock, \
+ struct intel_writeback_connector, 
\
+ fence_lock)
+
+static const char *intel_writeback_fence_get_driver_name(struct dma_fence 
*fence)
+{
+   struct intel_writeback_connector *wb_connector =
+   fence_to_wb_connector(fence);
+
+   return wb_connector->base->dev->driver->name;
+}
+
+static const char *
+intel_writeback_fence_get_timeline_name(struct dma_fence *fence)
+{
+   struct intel_writeback_connector *wb_connector =
+   fence_to_wb_connector(fence);
+
+   return wb_connector->timeline_name;
+}
+
+static bool intel_writeback_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+static const struct dma_fence_ops intel_writeback_fence_ops = {
+   .get_driver_name = intel_writeback_fence_get_driver_name,
+   .get_timeline_name = intel_writeback_fence_get_timeline_name,
+   .enable_signaling = intel_writeback_fence_enable_signaling,
+};
+
+static int intel_create_writeback_properties(struct drm_device *dev)
+{
+   struct drm_property *prop;
+   struct drm_i915_private *i915 = to_i915(dev);
+
+   if (!i915->wb_fb_id_property) {
+   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
+  

[Intel-gfx] [RFC PATCH 2/3] drm/i915: Define WD trancoder for i915

[Suraj Kandpal]

Adding WD Types, WD transcoder to enum list and WD Transcoder offsets

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_display.h   | 6 ++
 drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index 8513703086b7..8c93a5de8e07 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -119,6 +119,8 @@ enum transcoder {
TRANSCODER_DSI_1,
TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
+   TRANSCODER_WD_0,
+   TRANSCODER_WD_1,
 
I915_MAX_TRANSCODERS
 };
@@ -140,6 +142,10 @@ static inline const char *transcoder_name(enum transcoder 
transcoder)
return "DSI A";
case TRANSCODER_DSI_C:
return "DSI C";
+   case TRANSCODER_WD_0:
+   return "WD 0";
+   case TRANSCODER_WD_1:
+   return "WD 1";
default:
return "";
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 7a96ecba73c0..dcb4ad43cf88 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -79,6 +79,7 @@ enum intel_output_type {
INTEL_OUTPUT_DSI = 9,
INTEL_OUTPUT_DDI = 10,
INTEL_OUTPUT_DP_MST = 11,
+   INTEL_OUTPUT_WD = 12,
 };
 
 enum hdmi_force_audio {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ddbc7a685a50..6396afd77209 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2023,6 +2023,8 @@
 #define TRANSCODER_EDP_OFFSET 0x6f000
 #define TRANSCODER_DSI0_OFFSET 0x6b000
 #define TRANSCODER_DSI1_OFFSET 0x6b800
+#define TRANSCODER_WD0_OFFSET  0x6e000
+#define TRANSCODER_WD1_OFFSET  0x6e800
 
 #define HTOTAL(trans)  _MMIO_TRANS2(trans, _HTOTAL_A)
 #define HBLANK(trans)  _MMIO_TRANS2(trans, _HBLANK_A)
-- 
2.35.1

[Intel-gfx] [RFC PATCH 3/3] drm/i915: Enabling WD Transcoder

[Suraj Kandpal]

Adding support for writeback transcoder to start capturing frames using
interrupt mechanism

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  89 +-
 drivers/gpu/drm/i915/display/intel_display.h  |   9 +
 .../drm/i915/display/intel_display_types.h|  13 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   3 +
 drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
 drivers/gpu/drm/i915/display/intel_wd.c   | 978 ++
 drivers/gpu/drm/i915/display/intel_wd.h   |  82 ++
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_irq.c   |   8 +-
 drivers/gpu/drm/i915/i915_pci.c   |   7 +-
 drivers/gpu/drm/i915/i915_reg.h   | 137 +++
 13 files changed, 1330 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 087bd9d1b397..5ee32513a945 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -287,6 +287,7 @@ i915-y += \
display/intel_vdsc.o \
display/intel_vrr.o \
display/intel_wb_connector.o\
+   display/intel_wd.o\
display/vlv_dsi.o \
display/vlv_dsi_pll.o
 
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f07..ae08db164f73 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -247,6 +247,7 @@ static u32 acpi_display_type(struct intel_connector 
*connector)
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_WRITEBACK:
display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
break;
case DRM_MODE_CONNECTOR_Unknown:
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index eb49973621f0..6dedc7921f54 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -111,6 +111,7 @@
 #include "intel_sprite.h"
 #include "intel_tc.h"
 #include "intel_vga.h"
+#include "intel_wd.h"
 #include "i9xx_plane.h"
 #include "skl_scaler.h"
 #include "skl_universal_plane.h"
@@ -1544,6 +1545,72 @@ static void intel_encoders_update_complete(struct 
intel_atomic_state *state)
}
 }
 
+static void intel_queue_writeback_job(struct intel_atomic_state *state,
+   struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+{
+   struct drm_connector_state *new_conn_state;
+   struct drm_connector *connector;
+   struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
+   struct intel_wd *intel_wd;
+   struct intel_connector *intel_connector;
+   struct intel_digital_connector_state *intel_conn_state;
+   struct intel_encoder *encoder;
+   int i;
+
+   for_each_intel_encoder_with_wd(&i915->drm, encoder) {
+   intel_wd = enc_to_intel_wd(encoder);
+
+   if (intel_wd->wd_crtc != intel_crtc)
+   return;
+
+   }
+
+   for_each_new_connector_in_state(&state->base, connector, new_conn_state,
+   i) {
+   intel_conn_state = 
to_intel_digital_connector_state(new_conn_state);
+   if (!intel_conn_state->job)
+   continue;
+   intel_connector = to_intel_connector(connector);
+   intel_writeback_queue_job(&intel_connector->wb_conn, 
new_conn_state);
+   drm_dbg_kms(&i915->drm, "queueing writeback job\n");
+   }
+}
+
+static void intel_find_writeback_connector(struct intel_atomic_state *state,
+   struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+{
+   struct drm_connector_state *new_conn_state;
+   struct drm_connector *connector;
+   struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
+   struct intel_wd *intel_wd;
+   struct intel_encoder *encoder;
+   int i;
+
+   for_each_intel_encoder_with_wd(&i915->drm, encoder) {
+   intel_wd = enc_to_intel_wd(encoder);
+
+   if (intel_wd->wd_crtc != intel_crtc)
+   return;
+
+   }
+
+   for_each_new_connector_in_state(&state->base, connector, new_conn_state,
+   i) {
+   struct intel_connector *intel_connector;
+
+   intel_connector = to_intel_connector(connector);
+   drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s]: status: %s\n",
+   connector->base.id, connector->name,
+   
drm_get_connector_status_name(connector->statu

[Intel-gfx] [RFC PATCH v2 00/10] RFCv2: nested AVIC

[Maxim Levitsky]

This patch series implement everything that is needed to
use AMD's AVIC while a nested guest is running including
ability of the nested guest to use it, and brings feature
parity vs APICv.

Compared to v1 of the series, there are lot of fixes,
and refactoring.

This version still use unconditional read-only apic id,
which will be addressed in the next version.

For the last patch, which allows to avoid cleaning is_running
bit in physid pages as long as it is possible, I measured
what would happen in a worst case:

- A malicious guest runs with 2 vCPUs pinned,
its first vCPU pounds on ICR sending IPIs to the 2nd vCPU

and 2nd vCPU scheduled out forever and not halted
(something that should not happen with Qemu though)

- A normal guest with single vCPU is pinned to run
on the same CPU as the 2nd vCPU of the first guest.

The normal guest continued to run, but was observed to run
about 40% slower.

Therefore AVIC doorbel is strict by default but if the admin
policy is to pin guests and not allow them to share a physical
cpu, then strict doorbel can be set to false and that does
improves the nested (and not nested as well) AVIC perf futher.

Suggestions, comments are welcome.

Best regards,
Maxim Levitsky

Maxim Levitsky (10):
  KVM: x86: mmu: allow to enable write tracking externally
  x86: KVMGT: use kvm_page_track_write_tracking_enable
  KVM: x86: mmu: add gfn_in_memslot helper
  KVM: x86: mmu: tweak fast path for emulation of access to nested NPT
pages
  KVM: x86: lapic: don't allow to change APIC ID when apic acceleration
is enabled
  KVM: x86: SVM: remove avic's broken code that updated APIC ID
  KVM: x86: SVM: move avic state to separate struct
  KVM: x86: rename .set_apic_access_page_addr to reload_apic_access_page
  KVM: nSVM: implement support for nested AVIC
  KVM: SVM: allow to avoid not needed updates to is_running

 arch/x86/include/asm/kvm-x86-ops.h|   2 +-
 arch/x86/include/asm/kvm_host.h   |   5 +-
 arch/x86/include/asm/kvm_page_track.h |   1 +
 arch/x86/kvm/Kconfig  |   3 -
 arch/x86/kvm/lapic.c  |  28 +-
 arch/x86/kvm/mmu.h|   8 +-
 arch/x86/kvm/mmu/mmu.c|  21 +-
 arch/x86/kvm/mmu/page_track.c |  10 +-
 arch/x86/kvm/svm/avic.c   | 949 --
 arch/x86/kvm/svm/nested.c | 131 +++-
 arch/x86/kvm/svm/svm.c|  31 +-
 arch/x86/kvm/svm/svm.h| 165 -
 arch/x86/kvm/trace.h  | 140 +++-
 arch/x86/kvm/vmx/vmx.c|   8 +-
 arch/x86/kvm/x86.c|  17 +-
 drivers/gpu/drm/i915/Kconfig  |   1 -
 drivers/gpu/drm/i915/gvt/kvmgt.c  |   5 +
 include/linux/kvm_host.h  |  10 +-
 18 files changed, 1413 insertions(+), 122 deletions(-)

-- 
2.26.3

[Intel-gfx] [RFC PATCH v2 01/10] KVM: x86: mmu: allow to enable write tracking externally

[Maxim Levitsky]

This will be used to enable write tracking from nested AVIC code
and can also be used to enable write tracking in GVT-g module
when it actually uses it as opposed to always enabling it,
when the module is compiled in the kernel.

No functional change intended.

Signed-off-by: Maxim Levitsky 
---
 arch/x86/include/asm/kvm_host.h   |  2 +-
 arch/x86/include/asm/kvm_page_track.h |  1 +
 arch/x86/kvm/mmu.h|  8 +---
 arch/x86/kvm/mmu/mmu.c| 17 ++---
 arch/x86/kvm/mmu/page_track.c | 10 --
 5 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 2c20f715f0094..ae41d2df69fe9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1234,7 +1234,7 @@ struct kvm_arch {
 * is used as one input when determining whether certain memslot
 * related allocations are necessary.
 */
-   bool shadow_root_allocated;
+   bool mmu_page_tracking_enabled;
 
 #if IS_ENABLED(CONFIG_HYPERV)
hpa_t   hv_root_tdp;
diff --git a/arch/x86/include/asm/kvm_page_track.h 
b/arch/x86/include/asm/kvm_page_track.h
index eb186bc57f6a9..955a5ae07b10e 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -50,6 +50,7 @@ int kvm_page_track_init(struct kvm *kvm);
 void kvm_page_track_cleanup(struct kvm *kvm);
 
 bool kvm_page_track_write_tracking_enabled(struct kvm *kvm);
+int kvm_page_track_write_tracking_enable(struct kvm *kvm);
 int kvm_page_track_write_tracking_alloc(struct kvm_memory_slot *slot);
 
 void kvm_page_track_free_memslot(struct kvm_memory_slot *slot);
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 671cfeccf04e9..44d15551f7156 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -269,7 +269,7 @@ int kvm_arch_write_log_dirty(struct kvm_vcpu *vcpu);
 int kvm_mmu_post_init_vm(struct kvm *kvm);
 void kvm_mmu_pre_destroy_vm(struct kvm *kvm);
 
-static inline bool kvm_shadow_root_allocated(struct kvm *kvm)
+static inline bool mmu_page_tracking_enabled(struct kvm *kvm)
 {
/*
 * Read shadow_root_allocated before related pointers. Hence, threads
@@ -277,9 +277,11 @@ static inline bool kvm_shadow_root_allocated(struct kvm 
*kvm)
 * see the pointers. Pairs with smp_store_release in
 * mmu_first_shadow_root_alloc.
 */
-   return smp_load_acquire(&kvm->arch.shadow_root_allocated);
+   return smp_load_acquire(&kvm->arch.mmu_page_tracking_enabled);
 }
 
+int mmu_enable_write_tracking(struct kvm *kvm);
+
 #ifdef CONFIG_X86_64
 static inline bool is_tdp_mmu_enabled(struct kvm *kvm) { return 
kvm->arch.tdp_mmu_enabled; }
 #else
@@ -288,7 +290,7 @@ static inline bool is_tdp_mmu_enabled(struct kvm *kvm) { 
return false; }
 
 static inline bool kvm_memslots_have_rmaps(struct kvm *kvm)
 {
-   return !is_tdp_mmu_enabled(kvm) || kvm_shadow_root_allocated(kvm);
+   return !is_tdp_mmu_enabled(kvm) || mmu_page_tracking_enabled(kvm);
 }
 
 static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, int level)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 69a30d6d1e2b9..2c4edae4b026d 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3368,7 +3368,7 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
return r;
 }
 
-static int mmu_first_shadow_root_alloc(struct kvm *kvm)
+int mmu_enable_write_tracking(struct kvm *kvm)
 {
struct kvm_memslots *slots;
struct kvm_memory_slot *slot;
@@ -3378,21 +3378,20 @@ static int mmu_first_shadow_root_alloc(struct kvm *kvm)
 * Check if this is the first shadow root being allocated before
 * taking the lock.
 */
-   if (kvm_shadow_root_allocated(kvm))
+   if (mmu_page_tracking_enabled(kvm))
return 0;
 
mutex_lock(&kvm->slots_arch_lock);
 
/* Recheck, under the lock, whether this is the first shadow root. */
-   if (kvm_shadow_root_allocated(kvm))
+   if (mmu_page_tracking_enabled(kvm))
goto out_unlock;
 
/*
 * Check if anything actually needs to be allocated, e.g. all metadata
 * will be allocated upfront if TDP is disabled.
 */
-   if (kvm_memslots_have_rmaps(kvm) &&
-   kvm_page_track_write_tracking_enabled(kvm))
+   if (kvm_memslots_have_rmaps(kvm) && mmu_page_tracking_enabled(kvm))
goto out_success;
 
for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
@@ -3422,7 +3421,7 @@ static int mmu_first_shadow_root_alloc(struct kvm *kvm)
 * all the related pointers are set.
 */
 out_success:
-   smp_store_release(&kvm->arch.shadow_root_allocated, true);
+   smp_store_release(&kvm->arch.mmu_page_tracking_enabled, true);
 
 out_unlock:
mutex_unlock(&kvm->slots_arch_lock);
@@ -3459,7 +3458,7 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
  

[Intel-gfx] [RFC PATCH v2 02/10] x86: KVMGT: use kvm_page_track_write_tracking_enable

[Maxim Levitsky]

This allows to enable the write tracking only when KVMGT is
actually used and doesn't carry any penalty otherwise.

Tested by booting a VM with a kvmgt mdev device.

Signed-off-by: Maxim Levitsky 
---
 arch/x86/kvm/Kconfig | 3 ---
 arch/x86/kvm/mmu/mmu.c   | 2 +-
 drivers/gpu/drm/i915/Kconfig | 1 -
 drivers/gpu/drm/i915/gvt/kvmgt.c | 5 +
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index e3cbd77061364..41341905d3734 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -126,7 +126,4 @@ config KVM_XEN
 
  If in doubt, say "N".
 
-config KVM_EXTERNAL_WRITE_TRACKING
-   bool
-
 endif # VIRTUALIZATION
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 2c4edae4b026d..23f895d439cf5 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -5727,7 +5727,7 @@ int kvm_mmu_init_vm(struct kvm *kvm)
node->track_flush_slot = kvm_mmu_invalidate_zap_pages_in_memslot;
kvm_page_track_register_notifier(kvm, node);
 
-   if (IS_ENABLED(CONFIG_KVM_EXTERNAL_WRITE_TRACKING) || !tdp_enabled)
+   if (!tdp_enabled)
mmu_enable_write_tracking(kvm);
 
return 0;
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 98c5450b8eacc..7d8346f4bae11 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -130,7 +130,6 @@ config DRM_I915_GVT_KVMGT
depends on DRM_I915_GVT
depends on KVM
depends on VFIO_MDEV
-   select KVM_EXTERNAL_WRITE_TRACKING
default n
help
  Choose this option if you want to enable KVMGT support for
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 057ec44901045..4c62ab3ef245d 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1933,6 +1933,7 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
struct intel_vgpu *vgpu;
struct kvmgt_vdev *vdev;
struct kvm *kvm;
+   int ret;
 
vgpu = mdev_get_drvdata(mdev);
if (handle_valid(vgpu->handle))
@@ -1948,6 +1949,10 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
if (__kvmgt_vgpu_exist(vgpu, kvm))
return -EEXIST;
 
+   ret = kvm_page_track_write_tracking_enable(kvm);
+   if (ret)
+   return ret;
+
info = vzalloc(sizeof(struct kvmgt_guest_info));
if (!info)
return -ENOMEM;
-- 
2.26.3

[Intel-gfx] [RFC PATCH v2 03/10] KVM: x86: mmu: add gfn_in_memslot helper

[Maxim Levitsky]

This is a tiny refactoring, and can be useful to check
if a GPA/GFN is within a memslot a bit more cleanly.

Signed-off-by: Maxim Levitsky 
---
 include/linux/kvm_host.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 252ee4a61b58b..12e261559070b 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1580,6 +1580,13 @@ int kvm_request_irq_source_id(struct kvm *kvm);
 void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id);
 bool kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args);
 
+
+static inline bool gfn_in_memslot(struct kvm_memory_slot *slot, gfn_t gfn)
+{
+   return (gfn >= slot->base_gfn && gfn < slot->base_gfn + slot->npages);
+}
+
+
 /*
  * Returns a pointer to the memslot if it contains gfn.
  * Otherwise returns NULL.
@@ -1590,12 +1597,13 @@ try_get_memslot(struct kvm_memory_slot *slot, gfn_t gfn)
if (!slot)
return NULL;
 
-   if (gfn >= slot->base_gfn && gfn < slot->base_gfn + slot->npages)
+   if (gfn_in_memslot(slot, gfn))
return slot;
else
return NULL;
 }
 
+
 /*
  * Returns a pointer to the memslot that contains gfn. Otherwise returns NULL.
  *
-- 
2.26.3

[Intel-gfx] [RFC PATCH v2 04/10] KVM: x86: mmu: tweak fast path for emulation of access to nested NPT pages

[Maxim Levitsky]

---
 arch/x86/kvm/mmu/mmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 23f895d439cf5..b63398dfdac3b 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -5315,8 +5315,8 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t 
cr2_or_gpa, u64 error_code,
 */
if (vcpu->arch.mmu->root_role.direct &&
(error_code & PFERR_NESTED_GUEST_PAGE) == PFERR_NESTED_GUEST_PAGE) {
-   kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2_or_gpa));
-   return 1;
+   if (kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2_or_gpa)))
+   return 1;
}
 
/*
-- 
2.26.3

[Intel-gfx] [RFC PATCH v2 05/10] KVM: x86: lapic: don't allow to change APIC ID when apic acceleration is enabled

[Maxim Levitsky]

No normal guest has any reason to change physical APIC IDs, and
allowing this introduces bugs into APIC acceleration code.

Signed-off-by: Maxim Levitsky 
---
 arch/x86/kvm/lapic.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 66b0eb0bda94e..56996aeca9881 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2046,10 +2046,20 @@ static int kvm_lapic_reg_write(struct kvm_lapic *apic, 
u32 reg, u32 val)
 
switch (reg) {
case APIC_ID:   /* Local APIC ID */
-   if (!apic_x2apic_mode(apic))
-   kvm_apic_set_xapic_id(apic, val >> 24);
-   else
+   if (apic_x2apic_mode(apic)) {
ret = 1;
+   break;
+   }
+   /*
+* Don't allow setting APIC ID with any APIC acceleration
+* enabled to avoid unexpected issues
+*/
+   if (enable_apicv && ((val >> 24) != apic->vcpu->vcpu_id)) {
+   kvm_vm_bugged(apic->vcpu->kvm);
+   break;
+   }
+
+   kvm_apic_set_xapic_id(apic, val >> 24);
break;
 
case APIC_TASKPRI:
@@ -2617,8 +2627,16 @@ int kvm_get_apic_interrupt(struct kvm_vcpu *vcpu)
 static int kvm_apic_state_fixup(struct kvm_vcpu *vcpu,
struct kvm_lapic_state *s, bool set)
 {
-   if (apic_x2apic_mode(vcpu->arch.apic)) {
-   u32 *id = (u32 *)(s->regs + APIC_ID);
+   u32 *id = (u32 *)(s->regs + APIC_ID);
+
+   if (!apic_x2apic_mode(vcpu->arch.apic)) {
+   /* Don't allow setting APIC ID with any APIC acceleration
+* enabled to avoid unexpected issues
+*/
+   if (enable_apicv && (*id >> 24) != vcpu->vcpu_id)
+   return -EINVAL;
+   } else {
+
u32 *ldr = (u32 *)(s->regs + APIC_LDR);
u64 icr;
 
-- 
2.26.3

[Intel-gfx] [RFC PATCH v2 06/10] KVM: x86: SVM: remove avic's broken code that updated APIC ID

[Maxim Levitsky]

Now that KVM doesn't allow to change APIC ID in case AVIC is
enabled, remove buggy AVIC code that tried to do so.

Signed-off-by: Maxim Levitsky 
---
 arch/x86/kvm/svm/avic.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index 9b859218af59c..f375ca1d6518e 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -442,35 +442,6 @@ static int avic_handle_ldr_update(struct kvm_vcpu *vcpu)
return ret;
 }
 
-static int avic_handle_apic_id_update(struct kvm_vcpu *vcpu)
-{
-   u64 *old, *new;
-   struct vcpu_svm *svm = to_svm(vcpu);
-   u32 id = kvm_xapic_id(vcpu->arch.apic);
-
-   if (vcpu->vcpu_id == id)
-   return 0;
-
-   old = avic_get_physical_id_entry(vcpu, vcpu->vcpu_id);
-   new = avic_get_physical_id_entry(vcpu, id);
-   if (!new || !old)
-   return 1;
-
-   /* We need to move physical_id_entry to new offset */
-   *new = *old;
-   *old = 0ULL;
-   to_svm(vcpu)->avic_physical_id_cache = new;
-
-   /*
-* Also update the guest physical APIC ID in the logical
-* APIC ID table entry if already setup the LDR.
-*/
-   if (svm->ldr_reg)
-   avic_handle_ldr_update(vcpu);
-
-   return 0;
-}
-
 static void avic_handle_dfr_update(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
@@ -489,10 +460,6 @@ static int avic_unaccel_trap_write(struct kvm_vcpu *vcpu)
AVIC_UNACCEL_ACCESS_OFFSET_MASK;
 
switch (offset) {
-   case APIC_ID:
-   if (avic_handle_apic_id_update(vcpu))
-   return 0;
-   break;
case APIC_LDR:
if (avic_handle_ldr_update(vcpu))
return 0;
@@ -584,8 +551,6 @@ int avic_init_vcpu(struct vcpu_svm *svm)
 
 void avic_apicv_post_state_restore(struct kvm_vcpu *vcpu)
 {
-   if (avic_handle_apic_id_update(vcpu) != 0)
-   return;
avic_handle_dfr_update(vcpu);
avic_handle_ldr_update(vcpu);
 }
-- 
2.26.3

[Intel-gfx] [RFC PATCH v2 08/10] KVM: x86: rename .set_apic_access_page_addr to reload_apic_access_page

[Maxim Levitsky]

This will be used on SVM to reload shadow page of the AVIC physid table

No functional change intended

Signed-off-by: Maxim Levitsky 
---
 arch/x86/include/asm/kvm-x86-ops.h | 2 +-
 arch/x86/include/asm/kvm_host.h| 3 +--
 arch/x86/kvm/vmx/vmx.c | 8 
 arch/x86/kvm/x86.c | 6 +++---
 4 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/kvm-x86-ops.h 
b/arch/x86/include/asm/kvm-x86-ops.h
index 96e4e9842dfc6..997edb7453ac2 100644
--- a/arch/x86/include/asm/kvm-x86-ops.h
+++ b/arch/x86/include/asm/kvm-x86-ops.h
@@ -82,7 +82,7 @@ KVM_X86_OP_OPTIONAL(hwapic_isr_update)
 KVM_X86_OP_OPTIONAL_RET0(guest_apic_has_interrupt)
 KVM_X86_OP_OPTIONAL(load_eoi_exitmap)
 KVM_X86_OP_OPTIONAL(set_virtual_apic_mode)
-KVM_X86_OP_OPTIONAL(set_apic_access_page_addr)
+KVM_X86_OP_OPTIONAL(reload_apic_pages)
 KVM_X86_OP(deliver_interrupt)
 KVM_X86_OP_OPTIONAL(sync_pir_to_irr)
 KVM_X86_OP_OPTIONAL_RET0(set_tss_addr)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index ae41d2df69fe9..f83cfcd7dd74c 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1415,7 +1415,7 @@ struct kvm_x86_ops {
bool (*guest_apic_has_interrupt)(struct kvm_vcpu *vcpu);
void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
void (*set_virtual_apic_mode)(struct kvm_vcpu *vcpu);
-   void (*set_apic_access_page_addr)(struct kvm_vcpu *vcpu);
+   void (*reload_apic_pages)(struct kvm_vcpu *vcpu);
void (*deliver_interrupt)(struct kvm_lapic *apic, int delivery_mode,
  int trig_mode, int vector);
int (*sync_pir_to_irr)(struct kvm_vcpu *vcpu);
@@ -1888,7 +1888,6 @@ int kvm_cpu_has_extint(struct kvm_vcpu *v);
 int kvm_arch_interrupt_allowed(struct kvm_vcpu *vcpu);
 int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
 void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event);
-
 int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
unsigned long ipi_bitmap_high, u32 min,
unsigned long icr, int op_64_bit);
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index cf8581978bce3..7defd31703c61 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6339,7 +6339,7 @@ void vmx_set_virtual_apic_mode(struct kvm_vcpu *vcpu)
vmx_update_msr_bitmap_x2apic(vcpu);
 }
 
-static void vmx_set_apic_access_page_addr(struct kvm_vcpu *vcpu)
+static void vmx_reload_apic_access_page(struct kvm_vcpu *vcpu)
 {
struct page *page;
 
@@ -,7 +,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = {
.enable_irq_window = vmx_enable_irq_window,
.update_cr8_intercept = vmx_update_cr8_intercept,
.set_virtual_apic_mode = vmx_set_virtual_apic_mode,
-   .set_apic_access_page_addr = vmx_set_apic_access_page_addr,
+   .reload_apic_pages = vmx_reload_apic_access_page,
.refresh_apicv_exec_ctrl = vmx_refresh_apicv_exec_ctrl,
.load_eoi_exitmap = vmx_load_eoi_exitmap,
.apicv_post_state_restore = vmx_apicv_post_state_restore,
@@ -7940,12 +7940,12 @@ static __init int hardware_setup(void)
enable_vnmi = 0;
 
/*
-* set_apic_access_page_addr() is used to reload apic access
+* kvm_vcpu_reload_apic_pages() is used to reload apic access
 * page upon invalidation.  No need to do anything if not
 * using the APIC_ACCESS_ADDR VMCS field.
 */
if (!flexpriority_enabled)
-   vmx_x86_ops.set_apic_access_page_addr = NULL;
+   vmx_x86_ops.reload_apic_pages = NULL;
 
if (!cpu_has_vmx_tpr_shadow())
vmx_x86_ops.update_cr8_intercept = NULL;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ab336f7c82e4b..3ac2d0134271b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9949,12 +9949,12 @@ void kvm_arch_mmu_notifier_invalidate_range(struct kvm 
*kvm,
kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
 }
 
-static void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
+static void kvm_vcpu_reload_apic_pages(struct kvm_vcpu *vcpu)
 {
if (!lapic_in_kernel(vcpu))
return;
 
-   static_call_cond(kvm_x86_set_apic_access_page_addr)(vcpu);
+   static_call_cond(kvm_x86_reload_apic_pages)(vcpu);
 }
 
 void __kvm_request_immediate_exit(struct kvm_vcpu *vcpu)
@@ -10071,7 +10071,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
if (kvm_check_request(KVM_REQ_LOAD_EOI_EXITMAP, vcpu))
vcpu_load_eoi_exitmap(vcpu);
if (kvm_check_request(KVM_REQ_APIC_PAGE_RELOAD, vcpu))
-   kvm_vcpu_reload_apic_access_page(vcpu);
+   kvm_vcpu_reload_apic_pages(vcpu);
if (kvm_check_request(KVM_REQ_HV_CRASH, vcpu)) {
vcpu->run->exit_reason = KVM_EXIT_SYSTEM_EVE

[Intel-gfx] [RFC PATCH v2 07/10] KVM: x86: SVM: move avic state to separate struct

[Maxim Levitsky]

This will make the code a bit easier to read when nested AVIC support
is added.

No functional change intended.

Signed-off-by: Maxim Levitsky 
---
 arch/x86/kvm/svm/avic.c | 49 +++--
 arch/x86/kvm/svm/svm.h  | 14 +++-
 2 files changed, 36 insertions(+), 27 deletions(-)

diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index f375ca1d6518e..87756237c646d 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -69,6 +69,8 @@ int avic_ga_log_notifier(u32 ga_tag)
unsigned long flags;
struct kvm_svm *kvm_svm;
struct kvm_vcpu *vcpu = NULL;
+   struct kvm_svm_avic *avic;
+
u32 vm_id = AVIC_GATAG_TO_VMID(ga_tag);
u32 vcpu_id = AVIC_GATAG_TO_VCPUID(ga_tag);
 
@@ -76,9 +78,13 @@ int avic_ga_log_notifier(u32 ga_tag)
trace_kvm_avic_ga_log(vm_id, vcpu_id);
 
spin_lock_irqsave(&svm_vm_data_hash_lock, flags);
-   hash_for_each_possible(svm_vm_data_hash, kvm_svm, hnode, vm_id) {
-   if (kvm_svm->avic_vm_id != vm_id)
+   hash_for_each_possible(svm_vm_data_hash, avic, hnode, vm_id) {
+
+
+   if (avic->vm_id != vm_id)
continue;
+
+   kvm_svm = container_of(avic, struct kvm_svm, avic);
vcpu = kvm_get_vcpu_by_id(&kvm_svm->kvm, vcpu_id);
break;
}
@@ -98,18 +104,18 @@ int avic_ga_log_notifier(u32 ga_tag)
 void avic_vm_destroy(struct kvm *kvm)
 {
unsigned long flags;
-   struct kvm_svm *kvm_svm = to_kvm_svm(kvm);
+   struct kvm_svm_avic *avic = &to_kvm_svm(kvm)->avic;
 
if (!enable_apicv)
return;
 
-   if (kvm_svm->avic_logical_id_table_page)
-   __free_page(kvm_svm->avic_logical_id_table_page);
-   if (kvm_svm->avic_physical_id_table_page)
-   __free_page(kvm_svm->avic_physical_id_table_page);
+   if (avic->logical_id_table_page)
+   __free_page(avic->logical_id_table_page);
+   if (avic->physical_id_table_page)
+   __free_page(avic->physical_id_table_page);
 
spin_lock_irqsave(&svm_vm_data_hash_lock, flags);
-   hash_del(&kvm_svm->hnode);
+   hash_del(&avic->hnode);
spin_unlock_irqrestore(&svm_vm_data_hash_lock, flags);
 }
 
@@ -117,10 +123,9 @@ int avic_vm_init(struct kvm *kvm)
 {
unsigned long flags;
int err = -ENOMEM;
-   struct kvm_svm *kvm_svm = to_kvm_svm(kvm);
-   struct kvm_svm *k2;
struct page *p_page;
struct page *l_page;
+   struct kvm_svm_avic *avic = &to_kvm_svm(kvm)->avic;
u32 vm_id;
 
if (!enable_apicv)
@@ -131,14 +136,14 @@ int avic_vm_init(struct kvm *kvm)
if (!p_page)
goto free_avic;
 
-   kvm_svm->avic_physical_id_table_page = p_page;
+   avic->physical_id_table_page = p_page;
 
/* Allocating logical APIC ID table (4KB) */
l_page = alloc_page(GFP_KERNEL_ACCOUNT | __GFP_ZERO);
if (!l_page)
goto free_avic;
 
-   kvm_svm->avic_logical_id_table_page = l_page;
+   avic->logical_id_table_page = l_page;
 
spin_lock_irqsave(&svm_vm_data_hash_lock, flags);
  again:
@@ -149,13 +154,15 @@ int avic_vm_init(struct kvm *kvm)
}
/* Is it still in use? Only possible if wrapped at least once */
if (next_vm_id_wrapped) {
-   hash_for_each_possible(svm_vm_data_hash, k2, hnode, vm_id) {
-   if (k2->avic_vm_id == vm_id)
+   struct kvm_svm_avic *avic2;
+
+   hash_for_each_possible(svm_vm_data_hash, avic2, hnode, vm_id) {
+   if (avic2->vm_id == vm_id)
goto again;
}
}
-   kvm_svm->avic_vm_id = vm_id;
-   hash_add(svm_vm_data_hash, &kvm_svm->hnode, kvm_svm->avic_vm_id);
+   avic->vm_id = vm_id;
+   hash_add(svm_vm_data_hash, &avic->hnode, avic->vm_id);
spin_unlock_irqrestore(&svm_vm_data_hash_lock, flags);
 
return 0;
@@ -169,8 +176,8 @@ void avic_init_vmcb(struct vcpu_svm *svm, struct vmcb *vmcb)
 {
struct kvm_svm *kvm_svm = to_kvm_svm(svm->vcpu.kvm);
phys_addr_t bpa = __sme_set(page_to_phys(svm->avic_backing_page));
-   phys_addr_t lpa = 
__sme_set(page_to_phys(kvm_svm->avic_logical_id_table_page));
-   phys_addr_t ppa = 
__sme_set(page_to_phys(kvm_svm->avic_physical_id_table_page));
+   phys_addr_t lpa = 
__sme_set(page_to_phys(kvm_svm->avic.logical_id_table_page));
+   phys_addr_t ppa = 
__sme_set(page_to_phys(kvm_svm->avic.physical_id_table_page));
 
vmcb->control.avic_backing_page = bpa & AVIC_HPA_MASK;
vmcb->control.avic_logical_id = lpa & AVIC_HPA_MASK;
@@ -193,7 +200,7 @@ static u64 *avic_get_physical_id_entry(struct kvm_vcpu 
*vcpu,
if (index >= AVIC_MAX_PHYSICAL_ID_COUNT)
return NULL;
 
-   avic_physical_id_table = 
page_address(kvm_svm->avic_physical_id_tab

[Intel-gfx] [RFC PATCH v2 09/10] KVM: nSVM: implement support for nested AVIC

[Maxim Levitsky]

This implements initial support of using the AVIC in a nested guest

Signed-off-by: Maxim Levitsky 
---
 arch/x86/kvm/svm/avic.c   | 850 +-
 arch/x86/kvm/svm/nested.c | 131 +-
 arch/x86/kvm/svm/svm.c|  18 +
 arch/x86/kvm/svm/svm.h| 150 +++
 arch/x86/kvm/trace.h  | 140 ++-
 arch/x86/kvm/x86.c|  11 +
 6 files changed, 1282 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index 87756237c646d..9176c35662ada 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -51,6 +51,526 @@ static u32 next_vm_id = 0;
 static bool next_vm_id_wrapped = 0;
 static DEFINE_SPINLOCK(svm_vm_data_hash_lock);
 
+static u32 nested_avic_get_reg(struct kvm_vcpu *vcpu, int reg_off)
+{
+   struct vcpu_svm *svm = to_svm(vcpu);
+
+   void *nested_apic_regs = svm->nested.l2_apic_access_page.hva;
+
+   if (WARN_ON_ONCE(!nested_apic_regs))
+   return 0;
+
+   return *((u32 *) (nested_apic_regs + reg_off));
+}
+
+static inline struct kvm_vcpu *avic_vcpu_by_l1_apicid(struct kvm *kvm,
+ int l1_apicid)
+{
+   WARN_ON(l1_apicid == -1);
+   return kvm_get_vcpu_by_id(kvm, l1_apicid);
+}
+
+static void avic_physid_shadow_entry_set_vcpu(struct kvm *kvm,
+ struct avic_physid_table *t,
+ int n,
+ int new_l1_apicid)
+{
+   struct avic_physid_entry_descr *e = &t->entries[n];
+   u64 sentry = READ_ONCE(*e->sentry);
+   u64 old_sentry = sentry;
+   struct kvm_svm *kvm_svm = to_kvm_svm(kvm);
+   struct kvm_vcpu *new_vcpu = NULL;
+   int l0_apicid = -1;
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(&kvm_svm->avic.table_entries_lock, flags);
+
+   WARN_ON(!test_bit(n, t->valid_entires));
+
+   if (!list_empty(&e->link))
+   list_del_init(&e->link);
+
+   if (new_l1_apicid != -1)
+   new_vcpu = avic_vcpu_by_l1_apicid(kvm, new_l1_apicid);
+
+   if (new_vcpu)
+   list_add_tail(&e->link, 
&to_svm(new_vcpu)->nested.physid_ref_entries);
+
+   if (new_vcpu && to_svm(new_vcpu)->nested_avic_active)
+   l0_apicid = kvm_cpu_get_apicid(new_vcpu->cpu);
+
+   physid_entry_set_apicid(&sentry, l0_apicid);
+
+   if (sentry != old_sentry)
+   WRITE_ONCE(*e->sentry, sentry);
+
+   raw_spin_unlock_irqrestore(&kvm_svm->avic.table_entries_lock, flags);
+}
+
+static void avic_physid_shadow_entry_create(struct kvm *kvm,
+   struct avic_physid_table *t,
+   int n,
+   u64 gentry)
+{
+   struct avic_physid_entry_descr *e = &t->entries[n];
+   struct page *backing_page;
+   u64 backing_page_gpa = physid_entry_get_backing_table(gentry);
+   int l1_apic_id = physid_entry_get_apicid(gentry);
+   hpa_t backing_page_hpa;
+   u64 sentry = 0;
+
+
+   if (backing_page_gpa == INVALID_BACKING_PAGE)
+   return;
+
+   /* Pin the APIC backing page */
+   backing_page = gfn_to_page(kvm, gpa_to_gfn(backing_page_gpa));
+
+   if (is_error_page(backing_page))
+   /* Invalid GPA in the guest entry - point to a dummy entry */
+   backing_page_hpa = t->dummy_page_hpa;
+   else
+   backing_page_hpa = page_to_phys(backing_page);
+
+   physid_entry_set_backing_table(&sentry, backing_page_hpa);
+
+   e->gentry = gentry;
+   *e->sentry = sentry;
+
+   if (test_and_set_bit(n, t->valid_entires))
+   WARN_ON(1);
+
+   if (backing_page_hpa != t->dummy_page_hpa)
+   avic_physid_shadow_entry_set_vcpu(kvm, t, n, l1_apic_id);
+}
+
+static void avic_physid_shadow_entry_remove(struct kvm *kvm,
+  struct avic_physid_table *t,
+  int n)
+{
+   struct avic_physid_entry_descr *e = &t->entries[n];
+   struct kvm_svm *kvm_svm = to_kvm_svm(kvm);
+   hpa_t backing_page_hpa;
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(&kvm_svm->avic.table_entries_lock, flags);
+
+   if (!test_and_clear_bit(n, t->valid_entires))
+   WARN_ON(1);
+
+   /* Release the APIC backing page */
+   backing_page_hpa = physid_entry_get_backing_table(*e->sentry);
+
+   if (backing_page_hpa != t->dummy_page_hpa)
+   kvm_release_pfn_dirty(backing_page_hpa >> PAGE_SHIFT);
+
+   if (!list_empty(&e->link))
+   list_del_init(&e->link);
+
+   e->gentry = 0;
+   *e->sentry = 0;
+
+   raw_spin_unlock_irqrestore(&kvm_svm->avic.table_entries_lock, flags);
+}
+
+static void avic_update_peer_physid_entries(struct kvm_vcpu *vcpu, int cpu)
+{
+   /*
+* Update all sha

[Intel-gfx] [RFC PATCH v2 10/10] KVM: SVM: allow to avoid not needed updates to is_running

[Maxim Levitsky]

Allow optionally to make KVM not update is_running unless it is
functionally needed which is only when a vCPU halts,
or is in the guest mode.

This means security wise that if a vCPU is scheduled out,
other vCPUs could still send doorbell messages to the
last physical CPU where this vCPU was last running.

If a malicious guest tries to do it can slow down
the victim CPU by about 40% in my testing, so this
should only be enabled if physical CPUs are not shared
among guests.

The option is avic_doorbell_strict and is true by
default, setting it to false allows this relaxed
non strict mode.

Signed-off-by: Maxim Levitsky 
---
 arch/x86/kvm/svm/avic.c | 19 ---
 arch/x86/kvm/svm/svm.c  | 19 ++-
 arch/x86/kvm/svm/svm.h  |  1 +
 3 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index 9176c35662ada..1bfe58ee961b2 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -1641,7 +1641,7 @@ avic_update_iommu_vcpu_affinity(struct kvm_vcpu *vcpu, 
int cpu, bool r)
 
 void __avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
-   u64 entry;
+   u64 old_entry, new_entry;
int h_physical_id = kvm_cpu_get_apicid(cpu);
struct vcpu_svm *svm = to_svm(vcpu);
 
@@ -1660,14 +1660,16 @@ void __avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
if (kvm_vcpu_is_blocking(vcpu))
return;
 
-   entry = READ_ONCE(*(svm->avic_physical_id_cache));
-   WARN_ON(entry & AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK);
+   old_entry = READ_ONCE(*(svm->avic_physical_id_cache));
+   new_entry = old_entry;
 
-   entry &= ~AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK;
-   entry |= (h_physical_id & AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK);
-   entry |= AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK;
+   new_entry &= ~AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK;
+   new_entry |= (h_physical_id & 
AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK);
+   new_entry |= AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK;
+
+   if (old_entry != new_entry)
+   WRITE_ONCE(*(svm->avic_physical_id_cache), new_entry);
 
-   WRITE_ONCE(*(svm->avic_physical_id_cache), entry);
avic_update_iommu_vcpu_affinity(vcpu, h_physical_id, true);
 }
 
@@ -1777,6 +1779,9 @@ void avic_refresh_apicv_exec_ctrl(struct kvm_vcpu *vcpu)
 
 void avic_vcpu_blocking(struct kvm_vcpu *vcpu)
 {
+   if (!avic_doorbell_strict)
+   __nested_avic_put(vcpu);
+
if (!kvm_vcpu_apicv_active(vcpu))
return;
 
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 3d9ab1e7b2b52..7e79fefc81650 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -190,6 +190,10 @@ module_param(avic, bool, 0444);
 static bool force_avic;
 module_param_unsafe(force_avic, bool, 0444);
 
+bool avic_doorbell_strict = true;
+module_param(avic_doorbell_strict, bool, 0444);
+
+
 bool __read_mostly dump_invalid_vmcb;
 module_param(dump_invalid_vmcb, bool, 0644);
 
@@ -1395,16 +1399,21 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int 
cpu)
 
if (kvm_vcpu_apicv_active(vcpu))
__avic_vcpu_load(vcpu, cpu);
-
__nested_avic_load(vcpu, cpu);
 }
 
 static void svm_vcpu_put(struct kvm_vcpu *vcpu)
 {
-   if (kvm_vcpu_apicv_active(vcpu))
-   __avic_vcpu_put(vcpu);
-
-   __nested_avic_put(vcpu);
+   /*
+* Forbid AVIC's peers to send interrupts
+* to this CPU unless we are in non strict mode,
+* in which case, we will do so only when this vCPU blocks
+*/
+   if (avic_doorbell_strict) {
+   if (kvm_vcpu_apicv_active(vcpu))
+   __avic_vcpu_put(vcpu);
+   __nested_avic_put(vcpu);
+   }
 
svm_prepare_host_switch(vcpu);
 
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index 7d1a5028750e6..7139bbb534f9e 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -36,6 +36,7 @@ extern u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly;
 extern bool npt_enabled;
 extern int vgif;
 extern bool intercept_smi;
+extern bool avic_doorbell_strict;
 
 /*
  * Clean bits in VMCB.
-- 
2.26.3

Re: [Intel-gfx] [RFC PATCH v2 04/10] KVM: x86: mmu: tweak fast path for emulation of access to nested NPT pages

[Maxim Levitsky]

On Thu, 2022-04-21 at 08:12 +0300, Maxim Levitsky wrote:
> ---
>  arch/x86/kvm/mmu/mmu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 23f895d439cf5..b63398dfdac3b 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -5315,8 +5315,8 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t 
> cr2_or_gpa, u64 error_code,
>*/
>   if (vcpu->arch.mmu->root_role.direct &&
>   (error_code & PFERR_NESTED_GUEST_PAGE) == PFERR_NESTED_GUEST_PAGE) {
> - kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2_or_gpa));
> - return 1;
> + if (kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2_or_gpa)))
> + return 1;
>   }
>  
>   /*

I forgot to add commit description here:

If non leaf mmu page is write tracked externally for some reason,
which can in theory happen if it was used for nested avic physid page
before, then this code will enter an endless loop of page faults because
unprotecting the page will not remove write tracking, nor will the
write tracker callback be called.

Fix this by only invoking the fast patch if we succeeded in zapping the
mmu page.

Fixes: 147277540bbc5 ("kvm: svm: Add support for additional SVM NPF error 
codes")
Signed-off-by: Maxim Levitsky 

--

In theory, KVMGT also does external write tracking so in theory this issue can 
happen today,
but it is highly unlikely.

Best regards,
Maxim Levitsk

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915 writeback private framework (rev5)

[Patchwork]

== Series Details ==

Series: i915 writeback private framework (rev5)
URL   : https://patchwork.freedesktop.org/series/101425/
State : warning

== Summary ==

Error: dim checkpatch failed
41097e64119f drm/i915: Creating writeback pipeline to bypass drm_writeback 
framework
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:52: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#52: 
new file mode 100644

-:86: CHECK:LINE_SPACING: Please don't use multiple blank lines
#86: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:30:
+
+

-:99: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to 
avoid precedence issues
#99: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:43:
+#define fence_to_wb_connector(x) container_of(x->lock, \
+ struct intel_writeback_connector, 
\
+ fence_lock)

-:138: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#138: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:82:
+   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
+   "WRITEBACK_FB_ID",

-:157: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#157: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:101:
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+   "WRITEBACK_OUT_FENCE_PTR", 0,

-:172: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#172: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:116:
+int intel_writeback_connector_init(struct drm_device *dev,
+struct intel_writeback_connector *wb_connector,

-:195: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#195: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:139:
+   ret = drm_encoder_init(dev, wb_connector->encoder,
+   &intel_writeback_encoder_funcs,

-:203: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#203: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:147:
+   ret = drm_connector_init(dev, connector, con_funcs,
+   DRM_MODE_CONNECTOR_WRITEBACK);

-:208: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#208: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:152:
+   ret = drm_connector_attach_encoder(connector,
+   wb_connector->encoder);

-:218: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#218: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:162:
+   snprintf(wb_connector->timeline_name,
+   sizeof(wb_connector->timeline_name),

-:222: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#222: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:166:
+   drm_object_attach_property(&connector->base,
+   i915->wb_out_fence_ptr_property, 0);

-:225: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#225: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:169:
+   drm_object_attach_property(&connector->base,
+   i915->wb_fb_id_property, 0);

-:228: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#228: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:172:
+   drm_object_attach_property(&connector->base,
+   i915->wb_pixel_formats_property,

-:244: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#244: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:188:
+void intel_writeback_queue_job(struct intel_writeback_connector *wb_connector,
+   struct drm_connector_state *conn_state)

-:260: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#260: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:204:
+int intel_writeback_set_fb(struct drm_connector_state *conn_state,
+struct drm_framebuffer *fb)

-:303: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#303: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:247:
+intel_writeback_signal_completion(struct intel_writeback_connector 
*wb_connector,
+   int status)

-:311: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#311: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.c:255:
+   job = list_first_entry_or_null(&wb_connector->job_queue,
+   struct intel_writeback_job,

-:348: CHECK

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915 writeback private framework (rev5)

[Patchwork]

== Series Details ==

Series: i915 writeback private framework (rev5)
URL   : https://patchwork.freedesktop.org/series/101425/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PULL v2] gvt-next

[Christoph Hellwig]

On Thu, Apr 21, 2022 at 04:57:34AM +, Wang, Zhi A wrote:
> Is it possible that I can send two different pull based on the same branch?
> I was thinking I can remove this line in the original patch and then add a
> small patch to add this line back on the top. Then make two different tags
> before and after that small patch, send one pull with tag that includes that
> small patch to i915 and the other pull with tag that doesn't includes it to
> VFIO?

Yes, you can do that as long as the small fixup commit is the very last
one.

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915 writeback private framework (rev5)

[Patchwork]

== Series Details ==

Series: i915 writeback private framework (rev5)
URL   : https://patchwork.freedesktop.org/series/101425/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11530 -> Patchwork_101425v5


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_101425v5 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_101425v5, 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_101425v5/index.html

Participating hosts (45 -> 44)
--

  Additional (1): fi-cml-u2 
  Missing(2): fi-bsw-cyan fi-tgl-u2 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cml-u2:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-cml-u2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-busy@bcs0:
- fi-cml-u2:  NOTRUN -> [SKIP][2] ([i915#1208]) +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][3] -> [INCOMPLETE][4] ([i915#146])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11530/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-cml-u2:  NOTRUN -> [SKIP][5] ([i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-cml-u2/igt@gem_huc_c...@huc-copy.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][6] -> [INCOMPLETE][7] ([i915#4785])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11530/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-cml-u2:  NOTRUN -> [SKIP][8] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-cml-u2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-cml-u2:  NOTRUN -> [SKIP][9] ([fdo#109278]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-cml-u2:  NOTRUN -> [SKIP][10] ([fdo#109285])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-cml-u2/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  NOTRUN -> [DMESG-WARN][11] ([i915#4269])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cml-u2:  NOTRUN -> [SKIP][12] ([fdo#109278] / [i915#533])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-cml-u2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-hsw-g3258:   NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#4312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-hsw-g3258/igt@run...@aborted.html
- fi-tgl-1115g4:  NOTRUN -> [FAIL][14] ([i915#5257])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-tgl-1115g4/igt@run...@aborted.html

  
 Possible fixes 

  * igt@core_hotunplug@unbind-rebind:
- {bat-rpls-2}:   [DMESG-WARN][15] ([i915#4391]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11530/bat-rpls-2/igt@core_hotunp...@unbind-rebind.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/bat-rpls-2/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][17] ([i915#4785]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11530/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101425v5/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_busy@basic@flip:
- {bat-adlp-6}:   [DMESG-WARN

Re: [Intel-gfx] [PATCH] drm/i915: Fix race in __i915_vma_remove_closed

[kernel test robot]

Hi Karol,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on linus/master v5.18-rc3 next-20220420]
[cannot apply to drm-intel/for-linux-next linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/intel-lab-lkp/linux/commits/Karol-Herbst/drm-i915-Fix-race-in-__i915_vma_remove_closed/20220420-074525
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-c002 
(https://download.01.org/0day-ci/archive/20220420/202204201854.2r6j6wjr-...@intel.com/config)
compiler: gcc-11 (Debian 11.2.0-20) 11.2.0
reproduce (this is a W=1 build):
# 
https://github.com/intel-lab-lkp/linux/commit/50a17180127b7d2527ee9a8f5c9e8207e158afb6
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Karol-Herbst/drm-i915-Fix-race-in-__i915_vma_remove_closed/20220420-074525
git checkout 50a17180127b7d2527ee9a8f5c9e8207e158afb6
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_vma.c: In function 'release_references':
>> drivers/gpu/drm/i915/i915_vma.c:1654:9: error: ISO C90 forbids mixed 
>> declarations and code [-Werror=declaration-after-statement]
1654 | struct intel_gt *gt = vma->vm->gt;
 | ^~
   cc1: all warnings being treated as errors


vim +1654 drivers/gpu/drm/i915/i915_vma.c

  1640  
  1641  static void release_references(struct i915_vma *vma, bool vm_ddestroy)
  1642  {
  1643  struct drm_i915_gem_object *obj = vma->obj;
  1644  
  1645  GEM_BUG_ON(i915_vma_is_active(vma));
  1646  
  1647  spin_lock(&obj->vma.lock);
  1648  list_del(&vma->obj_link);
  1649  if (!RB_EMPTY_NODE(&vma->obj_node))
  1650  rb_erase(&vma->obj_node, &obj->vma.tree);
  1651  
  1652  spin_unlock(&obj->vma.lock);
  1653  
> 1654  struct intel_gt *gt = vma->vm->gt;
  1655  
  1656  spin_lock_irq(>->closed_lock);
  1657  __i915_vma_remove_closed(vma);
  1658  spin_unlock_irq(>->closed_lock);
  1659  
  1660  if (vm_ddestroy)
  1661  i915_vm_resv_put(vma->vm);
  1662  
  1663  i915_active_fini(&vma->active);
  1664  GEM_WARN_ON(vma->resource);
  1665  i915_vma_free(vma);
  1666  }
  1667  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

Re: [Intel-gfx] [PATCH] drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines

[Joonas Lahtinen]

Quoting Ville Syrjälä (2022-04-20 19:23:57)
> On Wed, Apr 20, 2022 at 05:32:43PM +0200, Hans de Goede wrote:
> > Hi Ville,
> > 
> > On 4/20/22 16:03, Ville Syrjälä wrote:
> > > On Mon, Apr 18, 2022 at 05:09:36PM +0200, Hans de Goede wrote:
> > >> Commit 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane 
> > >> registers")
> > >> introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these
> > >> their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16).
> > >>
> > >> This breaks the primary display pane on at least pineview machines, fix
> > >> the mask to fix the primary display pane only showing black.
> > >>
> > >> Tested on an Acer One AO532h with an Intel N450 SoC.
> > >>
> > >> Fixes: 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane 
> > >> registers")
> > >> Cc: José Roberto de Souza 
> > >> Cc: Ville Syrjälä 
> > >> Signed-off-by: Hans de Goede 
> > >> ---
> > >> Note this fixes a regression in 5.18-rc# and I'm not entirely sure what
> > >> the procedure is here. Once I get a Reviewed-by or Acked-by and I push
> > >> this to drm-intel-next (where it also is necessary), should I then also
> > >> push it to drm-intel-fixes or will the current drm-intel-fixes
> > >> maintainer pick it up?
> > >> ---
> > >>  drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> > >>  1 file changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > >> b/drivers/gpu/drm/i915/i915_reg.h
> > >> index 51f46fe45c72..5f1f38684d65 100644
> > >> --- a/drivers/gpu/drm/i915/i915_reg.h
> > >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> > >> @@ -4352,12 +4352,12 @@
> > >>  #define _DSPAADDR 0x70184
> > >>  #define _DSPASTRIDE   0x70188
> > >>  #define _DSPAPOS  0x7018C /* reserved */
> > >> -#define   DISP_POS_Y_MASK REG_GENMASK(31, 0)
> > >> +#define   DISP_POS_Y_MASK REG_GENMASK(31, 16)
> > > 
> > > Doh. I guess I only tested it on plane A where the plane gets its size
> > > from PIPESRC instead. And looks like the failure mode is such that
> > > the likes of kms_plane/pixel-formats still gets consistent looking CRCs
> > > even with the misconfigured plane size :/
> > > 
> > > Thanks for the fix. Pushed to drm-intel-next.
> > 
> > Thank you pushing this out, will you (or someone else from Intel)
> > also take care of getting this on its way to 5.18-rc# ?
> 
> It has a fixes tag so it should get cherry-picked for fixes.

Yeah, it sould get picked up for next week's drm-intel-fixes PR.

For both drm-intel-next and drm-intel-gt-next, committers only push to
the -next branches and the rest is handled by tooling and maintainers as
long as the Fixes: tags are correct.

If a Fixes: tag has been missed when committing, only then you need to
manually let maintainers know to pick the patch up.

Regards, Joonas

> 
> -- 
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Joonas Lahtinen]

+ Tvrtko

Quoting Jason Gunthorpe (2022-04-13 17:45:48)
> On Wed, Apr 13, 2022 at 02:26:23PM +, Wang, Zhi A wrote:
> > On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 01:39:35PM +, Wang, Zhi A wrote:
> > > 
> > >> It seems Jani's makefile clean patch has already included this one, I can
> > >> just simply drop this one so that Christoph won't need to re-send 
> > >> everything.
> > >>
> > >> For the branch to move on, I am merging the patches and will re-generate 
> > >> the
> > >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and 
> > >> other
> > >> gvt branches.
> > >>
> > >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you 
> > >> can use
> > >> gvt-staging branch until my pull request landed in drm-intel-next.
> > >>
> > >> Also our QA will test gvt-staging-branch before the pull request. I 
> > >> suppose
> > >> it will take one or two days.
> > > 
> > > When you are wrangling the branches it would be great if Christoph's
> > > series and it's minimal dependencies could be on a single branch that
> > > could reasonably be pulled to the VFIO tree too, thanks
> > > 
> > > Jason
> > > 
> > 
> > Hi Jason:
> > 
> > I am thinking about the process of merging process. Here are the dependence:
> > 
> > 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
> > go through drm.
> > My patches of GVT-g will go through drm-intel-next -> drm -> upstream. 
> > 
> > 2) Christoph's patches depends on my patches, but part of them are for VFIO.
> > 
> > a. If they are fully going through VFIO repo, they might have to wait my
> > patches to get landed first.
> > 
> > b. If only the GVT-g parts goes through GVT repo, and rest of them goes
> > through VFIO, the rest part still needs to wait.
> > 
> > What would be a better process?
> 
> You should organize everything onto one simple branch based on a rc to
> make this all work.
> 
> Make your #1 patch as a single patch PR based on rc to drm-intel so it
> gets to the right tree
> 
> Make your MMIO series as PR on the branch above that first PR and merge to
> the gvt tree
> 
> Make Christoph's series as a PR on the branch above the second PR's
> MMIO series and merge to the gvt tree
> 
> Merge the gvt toward DRM in the normal way - ie the main merge path for
> this should be through DRM.
> 
> Then ask Alex to merge the 3rd PR as well.
> 
> I don't see any intel-next stuff in linux-next yet so hopefully it is
> early enough to get #1 OK.
> 
> Jason

Re: [Intel-gfx] [PULL v2] gvt-next

[Joonas Lahtinen]

+ Tvrtko

Quoting Christoph Hellwig (2022-04-21 08:47:38)
> On Thu, Apr 21, 2022 at 04:57:34AM +, Wang, Zhi A wrote:
> > Is it possible that I can send two different pull based on the same branch?
> > I was thinking I can remove this line in the original patch and then add a
> > small patch to add this line back on the top. Then make two different tags
> > before and after that small patch, send one pull with tag that includes that
> > small patch to i915 and the other pull with tag that doesn't includes it to
> > VFIO?
> 
> Yes, you can do that as long as the small fixup commit is the very last
> one.