[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev9)

== Series Details == Series: drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev9) URL : https://patchwork.freedesktop.org/series/112196/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/112196/revisions/9/mbox/ not found Build failed, no er

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/bridge-connector: simplify handling of USB-C DP

== Series Details == Series: drm/bridge-connector: simplify handling of USB-C DP URL : https://patchwork.freedesktop.org/series/121560/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13439 -> Patchwork_121560v1 Summary -

[Intel-gfx] [PATCH v4 27/29] KVM: x86/mmu: Drop @slot param from exported/external page-track APIs

Refactor KVM's exported/external page-track, a.k.a. write-track, APIs to take only the gfn and do the required memslot lookup in KVM proper. Forcing users of the APIs to get the memslot unnecessarily bleeds KVM internals into KVMGT and complicates usage of the APIs. No functional change intended.

[Intel-gfx] [PATCH v4 25/29] KVM: x86/mmu: Assert that correct locks are held for page write-tracking

When adding/removing gfns to/from write-tracking, assert that mmu_lock is held for write, and that either slots_lock or kvm->srcu is held. mmu_lock must be held for write to protect gfn_write_track's refcount, and SRCU or slots_lock must be held to protect the memslot itself. Tested-by: Yan Zhao

[Intel-gfx] [PATCH v4 26/29] KVM: x86/mmu: Bug the VM if write-tracking is used but not enabled

Bug the VM if something attempts to write-track a gfn, but write-tracking isn't enabled. The VM is doomed (and KVM has an egregious bug) if KVM or KVMGT wants to shadow guest page tables but can't because write-tracking isn't enabled. Tested-by: Yongwei Ma Signed-off-by: Sean Christopherson ---

[Intel-gfx] [PATCH v4 24/29] KVM: x86/mmu: Rename page-track APIs to reflect the new reality

Rename the page-track APIs to capture that they're all about tracking writes, now that the facade of supporting multiple modes is gone. Opportunstically replace "slot" with "gfn" in anticipation of removing the @slot param from the external APIs. No functional change intended. Tested-by: Yongwei

[Intel-gfx] [PATCH v4 28/29] KVM: x86/mmu: Handle KVM bookkeeping in page-track APIs, not callers

Get/put references to KVM when a page-track notifier is (un)registered instead of relying on the caller to do so. Forcing the caller to do the bookkeeping is unnecessary and adds one more thing for users to get wrong, e.g. see commit 9ed1fdee9ee3 ("drm/i915/gvt: Get reference to KVM iff attachment

[Intel-gfx] [PATCH v4 29/29] drm/i915/gvt: Drop final dependencies on KVM internal details

Open code gpa_to_gfn() in kvmgt_page_track_write() and drop KVMGT's dependency on kvm_host.h, i.e. include only kvm_page_track.h. KVMGT assumes "gfn == gpa >> PAGE_SHIFT" all over the place, including a few lines below in the same function with the same gpa, i.e. there's no reason to use KVM's hel

[Intel-gfx] [PATCH v4 21/29] KVM: x86/mmu: Move KVM-only page-track declarations to internal header

Bury the declaration of the page-track helpers that are intended only for internal KVM use in a "private" header. In addition to guarding against unwanted usage of the internal-only helpers, dropping their definitions avoids exposing other structures that should be KVM-internal, e.g. for memslots.

[Intel-gfx] [PATCH v4 22/29] KVM: x86/mmu: Use page-track notifiers iff there are external users

Disable the page-track notifier code at compile time if there are no external users, i.e. if CONFIG_KVM_EXTERNAL_WRITE_TRACKING=n. KVM itself now hooks emulated writes directly instead of relying on the page-track mechanism. Provide a stub for "struct kvm_page_track_notifier_node" so that includi

[Intel-gfx] [PATCH v4 20/29] KVM: x86: Remove the unused page-track hook track_flush_slot()

From: Yan Zhao Remove ->track_remove_slot(), there are no longer any users and it's unlikely a "flush" hook will ever be the correct API to provide to an external page-track user. Cc: Zhenyu Wang Suggested-by: Sean Christopherson Signed-off-by: Yan Zhao Tested-by: Yongwei Ma Signed-off-by: S

[Intel-gfx] [PATCH v4 19/29] drm/i915/gvt: switch from ->track_flush_slot() to ->track_remove_region()

From: Yan Zhao Switch from the poorly named and flawed ->track_flush_slot() to the newly introduced ->track_remove_region(). From KVMGT's perspective, the two hooks are functionally equivalent, the only difference being that ->track_remove_region() is called only when KVM is 100% certain the mem

[Intel-gfx] [PATCH v4 18/29] KVM: x86: Add a new page-track hook to handle memslot deletion

From: Yan Zhao Add a new page-track hook, track_remove_region(), that is called when a memslot DELETE operation is about to be committed. The "remove" hook will be used by KVMGT and will effectively replace the existing track_flush_slot() altogether now that KVM itself doesn't rely on the "flush

[Intel-gfx] [PATCH v4 23/29] KVM: x86/mmu: Drop infrastructure for multiple page-track modes

Drop "support" for multiple page-track modes, as there is no evidence that array-based and refcounted metadata is the optimal solution for other modes, nor is there any evidence that other use cases, e.g. for access-tracking, will be a good fit for the page-track machinery in general. E.g. one pot

[Intel-gfx] [PATCH v4 16/29] KVM: x86: Reject memslot MOVE operations if KVMGT is attached

Disallow moving memslots if the VM has external page-track users, i.e. if KVMGT is being used to expose a virtual GPU to the guest, as KVMGT doesn't correctly handle moving memory regions. Note, this is potential ABI breakage! E.g. userspace could move regions that aren't shadowed by KVMGT withou

[Intel-gfx] [PATCH v4 15/29] KVM: drm/i915/gvt: Drop @vcpu from KVM's ->track_write() hook

Drop @vcpu from KVM's ->track_write() hook provided for external users of the page-track APIs now that KVM itself doesn't use the page-track mechanism. Reviewed-by: Yan Zhao Tested-by: Yongwei Ma Signed-off-by: Sean Christopherson --- arch/x86/include/asm/kvm_page_track.h | 5 ++--- arch/x86/

[Intel-gfx] [PATCH v4 17/29] drm/i915/gvt: Don't bother removing write-protection on to-be-deleted slot

When handling a slot "flush", don't call back into KVM to drop write protection for gfns in the slot. Now that KVM rejects attempts to move memory slots while KVMGT is attached, the only time a slot is "flushed" is when it's being removed, i.e. the memslot and all its write-tracking metadata is ab

[Intel-gfx] [PATCH v4 14/29] KVM: x86/mmu: Don't bounce through page-track mechanism for guest PTEs

Don't use the generic page-track mechanism to handle writes to guest PTEs in KVM's MMU. KVM's MMU needs access to information that should not be exposed to external page-track users, e.g. KVM needs (for some definitions of "need") the vCPU to query the current paging mode, whereas external users,

[Intel-gfx] [PATCH v4 12/29] KVM: x86/mmu: Move kvm_arch_flush_shadow_{all, memslot}() to mmu.c

Move x86's implementation of kvm_arch_flush_shadow_{all,memslot}() into mmu.c, and make kvm_mmu_zap_all() static as it was globally visible only for kvm_arch_flush_shadow_all(). This will allow refactoring kvm_arch_flush_shadow_memslot() to call kvm_mmu_zap_all() directly without having to expose

[Intel-gfx] [PATCH v4 11/29] drm/i915/gvt: Protect gfn hash table with vgpu_lock

Use vgpu_lock instead of KVM's mmu_lock to protect accesses to the hash table used to track which gfns are write-protected when shadowing the guest's GTT, and hoist the acquisition of vgpu_lock from intel_vgpu_page_track_handler() out to its sole caller, kvmgt_page_track_write(). This fixes a bug

[Intel-gfx] [PATCH v4 10/29] drm/i915/gvt: Drop unused helper intel_vgpu_reset_gtt()

Drop intel_vgpu_reset_gtt() as it no longer has any callers. In addition to eliminating dead code, this eliminates the last possible scenario where __kvmgt_protect_table_find() can be reached without holding vgpu_lock. Requiring vgpu_lock to be held when calling __kvmgt_protect_table_find() will a

[Intel-gfx] [PATCH v4 13/29] KVM: x86/mmu: Don't rely on page-track mechanism to flush on memslot change

Call kvm_mmu_zap_all_fast() directly when flushing a memslot instead of bouncing through the page-track mechanism. KVM (unfortunately) needs to zap and flush all page tables on memslot DELETE/MOVE irrespective of whether KVM is shadowing guest page tables. This will allow changing KVM to register

[Intel-gfx] [PATCH v4 08/29] drm/i915/gvt: Don't rely on KVM's gfn_to_pfn() to query possible 2M GTT

Now that gvt_pin_guest_page() explicitly verifies the pinned PFN is a transparent hugepage page, don't use KVM's gfn_to_pfn() to pre-check if a 2MiB GTT entry is possible and instead just try to map the GFN with a 2MiB entry. Using KVM to query pfn that is ultimately managed through VFIO is odd, a

[Intel-gfx] [PATCH v4 09/29] drm/i915/gvt: Use an "unsigned long" to iterate over memslot gfns

Use an "unsigned long" instead of an "int" when iterating over the gfns in a memslot. The number of pages in the memslot is tracked as an "unsigned long", e.g. KVMGT could theoretically break if a KVM memslot larger than 16TiB were deleted (2^32 * 4KiB). Reviewed-by: Yan Zhao Tested-by: Yongwei

[Intel-gfx] [PATCH v4 07/29] drm/i915/gvt: Error out on an attempt to shadowing an unknown GTT entry type

Bail from ppgtt_populate_shadow_entry() if an unexpected GTT entry type is encountered instead of subtly falling through to the common "direct shadow" path. Eliminating the default/error path's reliance on the common handling will allow hoisting intel_gvt_dma_map_guest_page() into the case stateme

[Intel-gfx] [PATCH v4 05/29] drm/i915/gvt: Put the page reference obtained by KVM's gfn_to_pfn()

Put the struct page reference acquired by gfn_to_pfn(), KVM's API is that the caller is ultimately responsible for dropping any reference. Note, kvm_release_pfn_clean() ensures the pfn is actually a refcounted struct page before trying to put any references. Fixes: b901b252b6cf ("drm/i915/gvt: Ad

[Intel-gfx] [PATCH v4 06/29] drm/i915/gvt: Explicitly check that vGPU is attached before shadowing

Move the check that a vGPU is attacked from is_2MB_gtt_possible() all the way up to shadow_ppgtt_mm() to avoid unnecessary work, and to make it more obvious that a future cleanup of is_2MB_gtt_possible() isn't introducing a bug. is_2MB_gtt_possible() has only one caller, ppgtt_populate_shadow_entr

[Intel-gfx] [PATCH v4 04/29] drm/i915/gvt: Don't try to unpin an empty page range

From: Yan Zhao Attempt to unpin pages in the error path of gvt_pin_guest_page() if and only if at least one page was successfully pinned. Unpinning doesn't cause functional problems, but vfio_device_container_unpin_pages() rightfully warns about being asked to unpin zero pages. Signed-off-by: Y

[Intel-gfx] [PATCH v4 03/29] drm/i915/gvt: Verify hugepages are contiguous in physical address space

When shadowing a GTT entry with a 2M page, verify that the pfns are contiguous, not just that the struct page pointers are contiguous. The memory map is virtual contiguous if "CONFIG_FLATMEM=y || CONFIG_SPARSEMEM_VMEMMAP=y", but not for "CONFIG_SPARSEMEM=y && CONFIG_SPARSEMEM_VMEMMAP=n", so theore

[Intel-gfx] [PATCH v4 01/29] drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page"

Check that the pfn found by gfn_to_pfn() is actually backed by "struct page" memory prior to retrieving and dereferencing the page. KVM supports backing guest memory with VM_PFNMAP, VM_IO, etc., and so there is no guarantee the pfn returned by gfn_to_pfn() has an associated "struct page". Fixes:

[Intel-gfx] [PATCH v4 02/29] drm/i915/gvt: remove interface intel_gvt_is_valid_gfn

From: Yan Zhao Currently intel_gvt_is_valid_gfn() is called in two places: (1) shadowing guest GGTT entry (2) shadowing guest PPGTT leaf entry, which was introduced in commit cc753fbe1ac4 ("drm/i915/gvt: validate gfn before set shadow page entry"). However, now it's not necessary to call this in

[Intel-gfx] [PATCH v4 00/29] drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups

Fix a handful of minor bugs in KVMGT, and overhaul KVM's page-track APIs to provide a leaner and cleaner interface. The motivation for this series is to (significantly) reduce the number of KVM APIs that KVMGT uses, with a long-term goal of making all kvm_host.h headers KVM-internal. If there are

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/bridge-connector: simplify handling of USB-C DP

== Series Details == Series: drm/bridge-connector: simplify handling of USB-C DP URL : https://patchwork.freedesktop.org/series/121560/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH 4/4] soc: qcom: pmic_glink: properly describe the DP connector

During the discussion of the DP connectors, it was suggested that USB-C DisplayPort connectors should have DRM_MODE_CONNECTOR_DisplayPort connector type. This follows the example provided by other drivers (AMDGPU, Intel). To distinguish them from native DP ports, they should have the freshly define

[Intel-gfx] [PATCH 3/4] drm/uapi: document the USB subconnector type

To properly define the USB-C DP altmode connectors, add the USB subconnector type. Suggested-by: Simon Ser Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/drm_connector.c | 1 + include/uapi/drm/drm_mode.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_connect

[Intel-gfx] [PATCH 2/4] drm/bridge-connector: handle subconnector types

If the created connector type supports subconnector type property, create and attach corresponding it. The default subtype value is 0, which maps to the DRM_MODE_SUBCONNECTOR_Unknown type. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/drm_bridge_connector.c | 33 +-

[Intel-gfx] [PATCH 1/4] drm: allow specifying default subtype for the DP subconnector property

In the embedded usecases the default subtype depends on the bridge chain, so it is easier to specify the subtype at the proprety attachment type rather than specifying it later. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 3 ++- drivers/gpu/d

[Intel-gfx] [PATCH 0/4] drm/bridge-connector: simplify handling of USB-C DP

During the discussion of DP connetors, it was pointed out that existing DP drivers supporting USB-C altmode (AMDGPU, Intel) use DRM_MODE_CONNECTOR_DisplayPort for such connectors rather than DRM_MODE_CONNECTOR_USB. This patchset attempts to solve this issue. It adds USB to the enum drm_dp_subconne

Re: [Intel-gfx] PR for ADLP DMC v2.20 and MTL DMC v2.13

On Wed, Jul 26, 2023 at 4:50 PM Gustavo Sousa wrote: > > The following changes since commit b6ea35ff6b9869470a0c68813f1668acb3d356a8: > > copy-firmware: Fix linking directories when using compression (2023-07-25 > 06:53:30 -0400) > > are available in the Git repository at: > > git://anongit.f

[Intel-gfx] ✓ Fi.CI.IGT: success for Panel replay phase1 implementation (rev5)

== Series Details == Series: Panel replay phase1 implementation (rev5) URL : https://patchwork.freedesktop.org/series/94470/ State : success == Summary == CI Bug Log - changes from CI_DRM_13436_full -> Patchwork_94470v5_full Summary ---

Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/panelreplay: Initializaton and compute config for panel replay

Hi Animesh, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-tip/drm-tip] url: https://github.com/intel-lab-lkp/linux/commits/Animesh-Manna/drm-panelreplay-dpcd-register-definition-for-panelreplay/20230728-205902 base: git://anongit.freedesktop.org

Re: [Intel-gfx] [PATCH v2] drm/i915/guc/slpc: Restore efficient freq earlier

On Tue, Jul 25, 2023 at 06:00:44PM -0700, Vinay Belgaumkar wrote: > This should be done before the soft min/max frequencies are restored. > When we disable the "Ignore efficient frequency" flag, GuC does not > actually bring the requested freq down to RPn. > > Specifically, this scenario- > > - i

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Hold reference to intel_context over life of i915_request

== Series Details == Series: drm/i915: Hold reference to intel_context over life of i915_request URL : https://patchwork.freedesktop.org/series/121510/ State : success == Summary == CI Bug Log - changes from CI_DRM_13435_full -> Patchwork_121510v1_full =

Re: [Intel-gfx] [RFC 4/8] drm/i915: Refactor PAT/object cache handling

On Fri, Jul 28, 2023 at 01:39:06PM +0100, Tvrtko Ursulin wrote: > > Forgot one part of your reply: > > On 28/07/2023 00:57, Matt Roper wrote: > > On Thu, Jul 27, 2023 at 03:55:00PM +0100, Tvrtko Ursulin wrote: > > > From: Tvrtko Ursulin > > > > > > Commit 9275277d5324 ("drm/i915: use pat_index

Re: [Intel-gfx] [PATCH i-g-t 2/3] lib/igt_drm_clients: Store memory info in the client

On 27/07/2023 16:17, Tvrtko Ursulin wrote: Hi, On 27/07/2023 15:10, Kamil Konieczny wrote: Hi Tvrtko, On 2023-07-27 at 10:20:24 +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Define the storage structure and copy over memory data as parsed by the fdinfo helpers. v2:   * Fix empty reg

Re: [Intel-gfx] [RFC 2/8] drm/i915: Split PTE encode between Gen12 and Meteorlake

On Fri, Jul 28, 2023 at 09:18:36AM +0100, Tvrtko Ursulin wrote: > > On 27/07/2023 23:25, Matt Roper wrote: > > On Thu, Jul 27, 2023 at 03:54:58PM +0100, Tvrtko Ursulin wrote: > > > From: Tvrtko Ursulin > > > > > > No need to run extra instructions which will never trigger on platforms > > > befo

Re: [Intel-gfx] [PATCH v6 3/4] drm: Expand max DRM device number to full MINORBITS

On Thursday, July 27th, 2023 at 14:01, Christian König wrote: > > We do need patches to stop trying to infer the node type from the minor > > in libdrm, though. Emil has suggested using sysfs, which we already do > > in a few places in libdrm. > > That sounds like a really good idea to me as we

Re: [Intel-gfx] [PATCH 16/17] cgroup/drm: Expose memory stats

One additional thought on one sub-topic: On 27/07/2023 18:08, Tvrtko Ursulin wrote: [snip] For something like this,  you would probably want it to work inside the drm scheduler first. Presumably, this can be done by setting a weight on each runqueue, and perhaps adding a callback to update

[Intel-gfx] ✓ Fi.CI.BAT: success for Panel replay phase1 implementation (rev5)

== Series Details == Series: Panel replay phase1 implementation (rev5) URL : https://patchwork.freedesktop.org/series/94470/ State : success == Summary == CI Bug Log - changes from CI_DRM_13436 -> Patchwork_94470v5 Summary --- **SUCC

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Panel replay phase1 implementation (rev5)

== Series Details == Series: Panel replay phase1 implementation (rev5) URL : https://patchwork.freedesktop.org/series/94470/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Panel replay phase1 implementation (rev5)

== Series Details == Series: Panel replay phase1 implementation (rev5) URL : https://patchwork.freedesktop.org/series/94470/ State : warning == Summary == Error: dim checkpatch failed 445e87b0b6b4 drm/panelreplay: dpcd register definition for panelreplay 81963673fe7c drm/i915/panelreplay: Adde

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix premature release of request's reusable memory

Hi Janusz, On Thu, Jul 20, 2023 at 11:35:44AM +0200, Janusz Krzysztofik wrote: > Infinite waits for completion of GPU activity have been observed in CI, > mostly inside __i915_active_wait(), triggered by igt@gem_barrier_race or > igt@perf@stress-open-close. Root cause analysis, based of ftrace du

[Intel-gfx] [PATCH v3 3/6] drm/i915/psr: Move psr specific dpcd init into own function

From: Jouni Högander This patch is preparing adding panel replay specific dpcd init. Signed-off-by: Jouni Högander --- drivers/gpu/drm/i915/display/intel_psr.c | 39 +--- 1 file changed, 22 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.

[Intel-gfx] [PATCH v3 6/6] drm/i915/panelreplay: enable/disable panel replay

TRANS_DP2_CTL register is programmed to enable panel replay from source and sink is enabled through panel replay dpcd configuration address. Bspec: 1407940617 v1: Initial version. v2: - Use pr_* flags instead psr_* flags. [Jouni] - Remove intel_dp_is_edp check as edp1.5 also has panel replay. [Jo

[Intel-gfx] [PATCH v3 5/6] drm/i915/panelreplay: Enable panel replay dpcd initialization for DP

Due to similarity panel replay dpcd initialization got added in psr function which is specific for edp panel. This patch enables panel replay initialization for dp connector. Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/display/intel_psr.c | 3 +++ 1 file changed, 3 insertions(+) diff

[Intel-gfx] [PATCH v3 4/6] drm/i915/panelreplay: Initializaton and compute config for panel replay

Modify existing PSR implementation to enable panel replay feature of DP 2.0 which is similar to PSR feature of EDP panel. There is different DPCD address to check panel capability compare to PSR and vsc sdp header is different. v1: Initial version. v2: - Set source_panel_replay_support flag under

[Intel-gfx] [PATCH v3 2/6] drm/i915/panelreplay: Added HAS_PANEL_REPLAY() macro

Platforms having Display 13 and above will support panel replay feature of DP 2.0 monitor. Added a HAS_PANEL_REPLAY() macro to check for panel replay capability. v1: Initial version. v2: DISPLAY_VER() removed as HAS_DP20() is having platform check. [Jouni] Cc: Jouni Högander Signed-off-by: Anime

[Intel-gfx] [PATCH v3 1/6] drm/panelreplay: dpcd register definition for panelreplay

DPCD register definition added to check and enable panel replay capability of the sink. Cc: Jouni Högander Signed-off-by: Animesh Manna --- include/drm/display/drm_dp.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h i

[Intel-gfx] [PATCH v3 0/6] Panel replay phase1 implementation

Panel Replay is a power saving feature for DP 2.0 monitor and similar to PSR on EDP. These patches are basic enablement patches added on top of existing psr framework to enable full-screen live active frame update mode of panel replay. Panel replay also can be enabled in selective update mode whic

Re: [Intel-gfx] [RFC 4/8] drm/i915: Refactor PAT/object cache handling

On 28/07/2023 08:14, Yang, Fei wrote: [snip] @@ -41,14 +42,17 @@ static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj) return false; /* - * For objects created by userspace through GEM_CREATE with pat_index - * set by set_pat extension, i915_gem

Re: [Intel-gfx] [RFC 7/8] drm/i915: Lift the user PAT restriction from use_cpu_reloc

On 28/07/2023 01:09, Matt Roper wrote: On Thu, Jul 27, 2023 at 03:55:03PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Now that i915 understands the caching modes behind PAT indices, we can refine the check in use_cpu_reloc() to not reject the uncached PAT if it was set by userspace. I

[Intel-gfx] ✓ Fi.CI.IGT: success for DSC misc fixes (rev5)

== Series Details == Series: DSC misc fixes (rev5) URL : https://patchwork.freedesktop.org/series/117662/ State : success == Summary == CI Bug Log - changes from CI_DRM_13435_full -> Patchwork_117662v5_full Summary --- **SUCCESS**

Re: [Intel-gfx] [RFC 4/8] drm/i915: Refactor PAT/object cache handling

Forgot one part of your reply: On 28/07/2023 00:57, Matt Roper wrote: On Thu, Jul 27, 2023 at 03:55:00PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has introduced PAT indices to i915 internal APIs, partially repla

Re: [Intel-gfx] [RFC 4/8] drm/i915: Refactor PAT/object cache handling

On 28/07/2023 01:17, Matt Roper wrote: On Thu, Jul 27, 2023 at 04:57:53PM -0700, Matt Roper wrote: On Thu, Jul 27, 2023 at 03:55:00PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has introduced PAT indices to i915 i

Re: [Intel-gfx] [RFC 5/8] drm/i915: Improve the vm_fault_gtt user PAT index restriction

On 28/07/2023 01:04, Matt Roper wrote: On Thu, Jul 27, 2023 at 03:55:01PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Now that i915 understands the caching modes behind PAT indices, we can refine the check in vm_fault_gtt() to not reject the uncached PAT if it was set by userspace on a

Re: [Intel-gfx] [RFC 4/8] drm/i915: Refactor PAT/object cache handling

On 28/07/2023 00:57, Matt Roper wrote: On Thu, Jul 27, 2023 at 03:55:00PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has introduced PAT indices to i915 internal APIs, partially replacing the usage of driver interna

Re: [Intel-gfx] [RFC 3/8] drm/i915: Cache PAT index used by the driver

On 27/07/2023 23:44, Matt Roper wrote: On Thu, Jul 27, 2023 at 03:54:59PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Eliminate a bunch of runtime calls to i915_gem_get_pat_index() by caching the interesting PAT indices in struct drm_i915_private. They are static per platfrom so no nee

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Add check for bitmap_zalloc()

== Series Details == Series: drm/i915/gem: Add check for bitmap_zalloc() URL : https://patchwork.freedesktop.org/series/121491/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13435_full -> Patchwork_121491v1_full Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid circular locking dependency when flush delayed work on gt reset (rev4)

== Series Details == Series: drm/i915: Avoid circular locking dependency when flush delayed work on gt reset (rev4) URL : https://patchwork.freedesktop.org/series/118898/ State : success == Summary == CI Bug Log - changes from CI_DRM_13434_full -> Patchwork_118898v4_full =

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in SDP CRC enable

Hello Arun, > -Original Message- > From: Intel-gfx On Behalf Of Arun R > Murthy > Sent: Friday, July 14, 2023 11:08 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in SDP CRC enable > > The debug print for enabling SDP CRC16 is appl

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Hold reference to intel_context over life of i915_request

== Series Details == Series: drm/i915: Hold reference to intel_context over life of i915_request URL : https://patchwork.freedesktop.org/series/121510/ State : success == Summary == CI Bug Log - changes from CI_DRM_13435 -> Patchwork_121510v1 ===

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Hold reference to intel_context over life of i915_request

== Series Details == Series: drm/i915: Hold reference to intel_context over life of i915_request URL : https://patchwork.freedesktop.org/series/121510/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Hold reference to intel_context over life of i915_request

== Series Details == Series: drm/i915: Hold reference to intel_context over life of i915_request URL : https://patchwork.freedesktop.org/series/121510/ State : warning == Summary == Error: dim checkpatch failed 116e3202bc7d drm/i915: Hold reference to intel_context over life of i915_request -:

Re: [Intel-gfx] [PATCH] drm/i915: Hold reference to intel_context over life of i915_request

On 28.07.2023 09:54, Andrzej Hajda wrote: References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On t

Re: [Intel-gfx] [RFC 2/8] drm/i915: Split PTE encode between Gen12 and Meteorlake

On 27/07/2023 23:25, Matt Roper wrote: On Thu, Jul 27, 2023 at 03:54:58PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin No need to run extra instructions which will never trigger on platforms before Meteorlake. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c |

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Make i915_coherent_map_type GT-centric

On Fri, Jul 28, 2023 at 09:07:14AM +0100, Tvrtko Ursulin wrote: > > On 28/07/2023 02:34, Andi Shyti wrote: > > Hi Daniele and John, > > > > On Thu, Jul 27, 2023 at 12:35:02PM +0100, Tvrtko Ursulin wrote: > > > > > > On 26/07/2023 16:53, Jonathan Cavitt wrote: > > > > Refactor i915_coherent_map_t

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Make i915_coherent_map_type GT-centric

On 28/07/2023 02:34, Andi Shyti wrote: Hi Daniele and John, On Thu, Jul 27, 2023 at 12:35:02PM +0100, Tvrtko Ursulin wrote: On 26/07/2023 16:53, Jonathan Cavitt wrote: Refactor i915_coherent_map_type to be GT-centric rather than device-centric. Each GT may require different coherency handl

Re: [Intel-gfx] [PATCH] drm/i915/gem: Add check for bitmap_zalloc()

Hi, On 28/07/2023 02:58, Jiasheng Jiang wrote: Add the check for the return value of bitmap_zalloc() in order to guarantee the success of the allocation. Fixes: e9b73c67390a ("drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pages") Signed-off-by: Jiasheng Jiang ---

[Intel-gfx] [PATCH] drm/i915: Hold reference to intel_context over life of i915_request

References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to kn

Re: [Intel-gfx] [RFC 4/8] drm/i915: Refactor PAT/object cache handling

[snip] > @@ -41,14 +42,17 @@ static bool gpu_write_needs_clflush(struct > drm_i915_gem_object *obj) > return false; > > /* > - * For objects created by userspace through GEM_CREATE with pat_index > - * set by set_pat extension, i915_gem_object_has_cache_level() will >