[Intel-gfx] [RFC PATCH 16/20] drm/i915/regs: Set DISPLAY_MMIO_BASE to 0 for xe

From: Maarten Lankhorst Only required for some old pre-gen9 platforms, not for Xe. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i915/display/intel_display_reg_defs.h | 4 2 files changed, 5 insertions(+), 1 deletion(-)

[Intel-gfx] [RFC PATCH 05/20] drm/sched: Add generic scheduler message interface

Add generic schedule message interface which sends messages to backend from the drm_gpu_scheduler main submission thread. The idea is some of these messages modify some state in drm_sched_entity which is also modified during submission. By scheduling these messages and submission in the same thread

[Intel-gfx] [RFC PATCH 20/20] mei/hdcp: Also enable for XE

From: Maarten Lankhorst Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms starting with Tiger Lake. Let's ensure mei/hdcp can accept xe instead of i915 whenever that is in use. Cc: Tomas Winkler Signed-off-by: Maarten Lankhorst --- drivers/misc/mei/hdcp/K

[Intel-gfx] [RFC PATCH 11/20] drm/i915: Remove gem and overlay frontbuffer tracking

From: Maarten Lankhorst Frontbuffer update handling should be done explicitly by using dirtyfb calls only. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/display/i9xx_plane.c | 1 + drivers/gpu/drm/i915/display/intel_drrs.c | 1 + drivers/gpu/drm/i915/display/intel_fb.c

[Intel-gfx] [RFC PATCH 07/20] drm/sched: Submit job before starting TDR

If the TDR is set to a value, it can fire before a job is submitted in drm_sched_main. The job should be always be submitted before the TDR fires, fix this ordering. Signed-off-by: Matthew Brost --- drivers/gpu/drm/scheduler/sched_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) dif

[Intel-gfx] [RFC PATCH 18/20] drm/i915/display: Remaining changes to make xe compile

From: Maarten Lankhorst Xe, the new Intel GPU driver, will re-use the i915 display. At least for now, the plan is to use symbolic links and adjust the build so we are building the display either for i915 or for xe. The display can be split out if needed. Also the compilation is optional at this

[Intel-gfx] [RFC PATCH 10/20] drm/ttm: Don't print error message if eviction was interrupted

From: Thomas Hellström Avoid printing an error message if eviction was interrupted by, for example, the user pressing CTRL-C. That may happen if eviction is waiting for something, like for example a free batch-buffer. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/ttm/ttm_bo.c | 3 ++- 1

[Intel-gfx] [RFC PATCH 13/20] drm/i915/display: Add more macros to remove all direct calls to uncore

From: Maarten Lankhorst Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/display/intel_de.h | 38 + 1 file changed, 38 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_de.h b/drivers/gpu/drm/i915/display/intel_de.h index 3dbd76fdabd6..3394044d281c

[Intel-gfx] [RFC PATCH 19/20] sound/hda: Allow XE as i915 replacement for sound

From: Maarten Lankhorst Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms starting with Tiger Lake. Let's ensure sound can accept xe instead of i915 whenever that is in use. Cc: Kai Vehmanen Signed-off-by: Maarten Lankhorst --- sound/hda/hdac_i915.c

[Intel-gfx] [RFC PATCH 14/20] drm/i915/display: Remove all uncore mmio accesses in favor of intel_de

From: Maarten Lankhorst Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/display/hsw_ips.c| 7 ++- drivers/gpu/drm/i915/display/intel_bios.c | 25 ++- drivers/gpu/drm/i915/display/intel_bw.c | 34 +++--- drivers/gpu/drm/i915/display/intel_cdclk.c|

[Intel-gfx] [RFC PATCH 17/20] drm/i915/display: Fix a use-after-free when intel_edp_init_connector fails

From: Maarten Lankhorst We enable the DP aux channel during probe, but may free the connector soon afterwards. Ensure the DP aux display power put is completed before everything is freed, to prevent a use-after-free in icl_aux_pw_to_phy(), called from icl_combo_phy_aux_power_well_disable. Signed

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hdmi: Go for scrambling only if platform supports TMDS clock > 340MHz (rev3)

== Series Details == Series: drm/i915/hdmi: Go for scrambling only if platform supports TMDS clock > 340MHz (rev3) URL : https://patchwork.freedesktop.org/series/111877/ State : success == Summary == CI Bug Log - changes from CI_DRM_12522_full -> Patchwork_111877v3_full ==

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Initial Xe driver submission

== Series Details == Series: Initial Xe driver submission URL : https://patchwork.freedesktop.org/series/112189/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/112189/revisions/1/mbox/ not applied Applying: drm/suballoc: Introduce a generic suball

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable HDCP2.x via GSC CS (rev4)

== Series Details == Series: Enable HDCP2.x via GSC CS (rev4) URL : https://patchwork.freedesktop.org/series/111876/ State : success == Summary == CI Bug Log - changes from CI_DRM_12522_full -> Patchwork_111876v4_full Summary --- **S

[Intel-gfx] ✓ Fi.CI.IGT: success for Remove platform acronyms and stepping from comments

== Series Details == Series: Remove platform acronyms and stepping from comments URL : https://patchwork.freedesktop.org/series/112161/ State : success == Summary == CI Bug Log - changes from CI_DRM_12522_full -> Patchwork_112161v1_full Sum

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix same object multiple mmap memory leak

== Series Details == Series: drm/i915: Fix same object multiple mmap memory leak URL : https://patchwork.freedesktop.org/series/112166/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12522_full -> Patchwork_112166v1_full Sum

[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce __xchg, non-atomic xchg

== Series Details == Series: Introduce __xchg, non-atomic xchg URL : https://patchwork.freedesktop.org/series/112169/ State : success == Summary == CI Bug Log - changes from CI_DRM_12522_full -> Patchwork_112169v1_full Summary --- **

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dmc: Use unversioned firmware paths

On Thu, Dec 22, 2022 at 07:12:08PM -0300, Gustavo Sousa wrote: On Wed, Dec 21, 2022 at 04:23:45PM -0800, Lucas De Marchi wrote: On Wed, Dec 21, 2022 at 12:26:26PM +0200, Jani Nikula wrote: > On Tue, 20 Dec 2022, Gustavo Sousa wrote: > > As we do not require specific versions anymore, change the

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

Fix a variety of found-by-inspection 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.

[Intel-gfx] [PATCH 01/27] 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 02/27] KVM: x86/mmu: Factor out helper to get max mapping size of a memslot

Extract the memslot-related logic of kvm_mmu_max_mapping_level() into a new helper so that KVMGT can determine whether or not mapping a 2MiB page into the guest is (dis)allowed per KVM's memslots. No functional change intended. Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/mmu.c

[Intel-gfx] [PATCH 05/27] 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 03/27] drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry

Honor KVM's max allowed page size when determining whether or not a 2MiB GTT shadow page can be created for the guest. Querying KVM's max allowed size is somewhat odd as there's no strict requirement that KVM's memslots and VFIO's mappings are configured with the same gfn=>hva mapping, but the che

[Intel-gfx] [PATCH 04/27] drm/i915/gvt: Verify VFIO-pinned page is THP when shadowing 2M gtt entry

When shadowing a GTT entry with a 2M page, explicitly verify that the first page pinned by VFIO is a transparent hugepage instead of assuming that page observed by is_2MB_gtt_possible() is the same page pinned by vfio_pin_pages(). E.g. if userspace is doing something funky with the guest's memslot

[Intel-gfx] [PATCH 06/27] 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 2M GTT entry is possible and instead just try to map the GFN with a 2MB entry. Using KVM to query pfn that is ultimately managed through VFIO is odd, and

[Intel-gfx] [PATCH 08/27] drm/i915/gvt: Hoist acquisition of vgpu_lock out to kvmgt_page_track_write()

Host the acquisition of vgpu_lock from intel_vgpu_page_track_handler() out to its sole caller, kvmgt_page_track_write(). An upcoming fix will add a mutex to protect the gfn hash table that referenced by kvmgt_gfn_is_write_protected(), i.e. kvmgt_page_track_write() will need to acquire another lock

[Intel-gfx] [PATCH 11/27] 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 10/27] 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 bounding 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 09/27] drm/i915/gvt: Protect gfn hash table with dedicated mutex

Add and use a new mutex, gfn_lock, to protect accesses to the hash table used to track which gfns are write-protected when shadowing the guest's GTT. This fixes a bug where kvmgt_page_track_write(), which doesn't hold kvm->mmu_lock, could race with intel_gvt_page_track_remove() and trigger a use-a

[Intel-gfx] [PATCH 07/27] 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). Signed-off-by: Sean Christopherson --- d

[Intel-gfx] [PATCH 16/27] 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 15/27] 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 12/27] 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. Signed-off-by: Sean Christopherson --- arch/x86/include/asm/kvm_page_track.h | 5 ++--- arch/x86/kvm/mmu/page_track.c | 2 +- drivers/

[Intel-gfx] [PATCH 13/27] 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 KVM 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 without

[Intel-gfx] [PATCH 20/27] 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 18/27] 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 21/27] 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. Signed-off-by: Sea

[Intel-gfx] [PATCH 19/27] 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. Signed-off-by: Sean Christopherson --- arch/x86/include/asm/kvm_host.h

[Intel-gfx] [PATCH 24/27] 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 23/27] 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. Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/page

[Intel-gfx] [PATCH 17/27] 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 Signed-off-by: Sean Christopherson ---

[Intel-gfx] [PATCH 22/27] 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. Signed-off-by: Sean C

[Intel-gfx] [PATCH 25/27] 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 26/27] KVM: x86/mmu: Add page-track API to query if a gfn is valid

Add a page-track API to query if a gfn is "valid", i.e. is backed by a memslot and is visible to the guest. This is one more step toward removing KVM internal details from the page-track APIs. Add a FIXME to call out that intel_gvt_is_valid_gfn() is broken with respect to 2MiB (or larger) guest e

[Intel-gfx] [PATCH 14/27] 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 27/27] 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 on 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 h

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

== Series Details == Series: drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups URL : https://patchwork.freedesktop.org/series/112196/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/112196/revisions/1/mbox/ not applied Applying: drm/i915/gvt:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/display/core: use intel_de_rmw if possible

== Series Details == Series: series starting with [v2,1/2] drm/i915/display/core: use intel_de_rmw if possible URL : https://patchwork.freedesktop.org/series/112171/ State : success == Summary == CI Bug Log - changes from CI_DRM_12523_full -> Patchwork_112171v1_full ==

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Flush power delayed put when connector init failed

== Series Details == Series: drm/i915: Flush power delayed put when connector init failed URL : https://patchwork.freedesktop.org/series/112182/ State : success == Summary == CI Bug Log - changes from CI_DRM_12523_full -> Patchwork_112182v1_full

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reset twice

On 12/22/22 3:47 PM, Andi Shyti wrote: Hi GG,  drivers/gpu/drm/i915/gt/intel_reset.c | 34 ++-  1 file changed, 28 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index ffde89c5835a4..88dfc0c

<    1   2