[Intel-gfx] ✓ Fi.CI.BAT: success for More error capture improvements (rev3)

== Series Details == Series: More error capture improvements (rev3) URL : https://patchwork.freedesktop.org/series/113628/ State : success == Summary == CI Bug Log - changes from CI_DRM_12842 -> Patchwork_113628v3 Summary --- **SUCCE

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for More error capture improvements (rev3)

== Series Details == Series: More error capture improvements (rev3) URL : https://patchwork.freedesktop.org/series/113628/ 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 v3 0/3] More error capture improvements

From: John Harrison Ecodes got lost with the switch to GuC based register lists. Put them back. Seqno values got lost with the switch to per context timelines. Put those back too. v2: Rework the timeline patch to just read the single seqno value rather than copying the entire object (Daniele) v

[Intel-gfx] [PATCH v3 1/3] drm/i915/guc: Fix missing ecodes

From: John Harrison Error captures are tagged with an 'ecode'. This is a pseduo-unique magic number that is meant to distinguish similar seeming bugs with different underlying signatures. It is a combination of two ring state registers. Unfortunately, the register state being used is only valid i

[Intel-gfx] [PATCH v3 3/3] drm/i915: Include timeline seqno in error capture

From: John Harrison The seqno value actually written out to memory is no longer in the regular HWSP. Instead, it is now in its own private timeline buffer. Thus, it is no longer visible in an error capture. So, explicitly read the value and include that in the capture. v2: %d -> %u (Alan) Signe

[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Clean up of register capture search

From: John Harrison The comparison in the search for a matching register capture node was not the most readable. It was also assuming that a zero GuC id means invalid, which it does not. So remove one invalid term, one redundant term and re-format to keep each term on a single line, and only one

Re: [Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units

On Fri, 10 Mar 2023 16:18:30 -0800, Umesh Nerlige Ramappa wrote: > > On Fri, Mar 10, 2023 at 09:36:52AM -0800, Dixit, Ashutosh wrote: > > On Fri, 10 Mar 2023 08:39:27 -0800, Umesh Nerlige Ramappa wrote: > >> > > > > Hi Umesh, > > > >> On Thu, Mar 09, 2023 at 03:57:48PM -0800, Dixit, Ashutosh wrote:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/ttm: let struct ttm_device_funcs be placed in rodata

== Series Details == Series: drm/ttm: let struct ttm_device_funcs be placed in rodata URL : https://patchwork.freedesktop.org/series/114907/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114907v1_full

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: make kobj attributes const (rev2)

== Series Details == Series: drm/i915/gt: make kobj attributes const (rev2) URL : https://patchwork.freedesktop.org/series/114898/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114898v2_full Summary

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Allow for very slow GuC loading

On 3/3/2023 11:20, Ceraolo Spurio, Daniele wrote: On 2/17/2023 3:47 PM, john.c.harri...@intel.com wrote: From: John Harrison A failure to load the GuC is occasionally observed where the GuC log actually showed that the GuC had loaded just fine. The implication being that the load just took eve

[Intel-gfx] [PATCH] drm/i915/guc: Disable PL1 power limit when loading GuC firmware

On dGfx, the PL1 power limit being enabled and set to a low value results in a low GPU operating freq. It also negates the freq raise operation which is done before GuC firmware load. As a result GuC firmware load can time out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power

[Intel-gfx] [PATCH v2 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 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 v2 26/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 v2 20/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 v2 25/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 v2 22/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 v2 24/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 v2 23/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 v2 18/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 v2 21/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 v2 19/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 v2 17/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 v2 12/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 v2 16/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 v2 14/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 v2 15/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 v2 13/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 v2 10/27] 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 v2 11/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 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 v2 09/27] 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 v2 08/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 v2 07/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 v2 06/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 v2 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 v2 04/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 v2 05/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 v2 03/27] 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 v2 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 v2 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] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL (rev2)

== Series Details == Series: series starting with [v2,1/2] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL (rev2) URL : https://patchwork.freedesktop.org/series/114873/ State : success == Summary == CI Bug Log - changes from CI_DRM_12841 -> Patchwork_114873v2 =

Re: [Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units

On Fri, Mar 10, 2023 at 09:36:52AM -0800, Dixit, Ashutosh wrote: On Fri, 10 Mar 2023 08:39:27 -0800, Umesh Nerlige Ramappa wrote: Hi Umesh, On Thu, Mar 09, 2023 at 03:57:48PM -0800, Dixit, Ashutosh wrote: > On Tue, 07 Mar 2023 12:16:11 -0800, Umesh Nerlige Ramappa wrote: >> >> -static int g

[Intel-gfx] [PATCH v2 4/4] drm/i915: Extract intel_crtc_scanline_offset()

From: Ville Syrjälä Pull the scanline_offset calculation into its own function. Might have further use for this later with DSB scanline waits. Reviewed-by: Jani Nikula Reviewed-by: Mitul Golani Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_vblank.c | 89 +++-

[Intel-gfx] [PATCH v2 3/4] drm/i915: Relocate intel_crtc_update_active_timings()

From: Ville Syrjälä Move intel_crtc_update_active_timings() into intel_vblank.c where it more properly belongs. Also do the s/dev_priv/i915/ modernization rename while at it. Reviewed-by: Jani Nikula Reviewed-by: Mitul Golani Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/int

[Intel-gfx] [PATCH v2 2/4] drm/i915: Add belts and suspenders locking for seamless M/N changes

From: Ville Syrjälä Add some (probably overkill) locking to protect the vblank timestamping constants updates during seamless M/N fastsets. As everything should be naturally aligned I think the individual pieces should probably end up updating atomically enough. So this is only really meant to g

[Intel-gfx] [PATCH v2 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change

From: Ville Syrjälä When we change the M/N values seamlessly during a fastset we should also update the vblank timestamping stuff to make sure the vblank timestamp corrections/guesstimations come out exact. Note that only crtc_clock and framedur_ns can actually end up changing here during fastse

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev4)

== Series Details == Series: series starting with [1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change (rev4) URL : https://patchwork.freedesktop.org/series/114720/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/114720/revisions

Re: [Intel-gfx] [PATCH v6 19/24] vfio-iommufd: Add detach_ioas support for emulated VFIO devices

On Wed, Mar 08, 2023 at 05:28:58AM -0800, Yi Liu wrote: > External email: Use caution opening links or attachments > > > this prepares for adding DETACH ioctl for emulated VFIO devices. > > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > Tested-by: Terrence Xu > Tested-by: Nicolin Chen > T

[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable HDCP2.x via GSC CS (rev12)

== Series Details == Series: Enable HDCP2.x via GSC CS (rev12) URL : https://patchwork.freedesktop.org/series/111876/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_111876v12_full Summary --- *

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change

On Fri, Mar 10, 2023 at 07:01:18PM +, Golani, Mitulkumar Ajitkumar wrote: > > > > -Original Message- > > From: Intel-gfx On Behalf Of Ville > > Syrjala > > Sent: 06 March 2023 20:59 > > To: intel-gfx@lists.freedesktop.org > > Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank t

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable YCbCr420 format for VDSC (rev3)

== Series Details == Series: Enable YCbCr420 format for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/114246/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114246v3_full Summary ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev3)

== Series Details == Series: series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev3) URL : https://patchwork.freedesktop.org/series/114868/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12841 -> Patchwork_114868v3 ==

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extract intel_crtc_scanline_offset()

> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: 06 March 2023 20:59 > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Extract > intel_crtc_scanline_offset() > > From: Ville Syrjälä > > Pull the scanline_offset calculation i

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Relocate intel_crtc_update_active_timings()

> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: 06 March 2023 20:59 > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 3/4] drm/i915: Relocate > intel_crtc_update_active_timings() > > From: Ville Syrjälä > > Move intel_crtc_update_active_ti

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.

On Fri, Mar 10, 2023 at 06:26:54PM +0200, Ville Syrjälä wrote: > On Thu, Mar 09, 2023 at 05:03:52PM -0500, Rodrigo Vivi wrote: > > On Thu, Mar 09, 2023 at 12:03:19AM +0200, Ville Syrjälä wrote: > > > On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote: > > > > uncore->lock only protects th

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change

> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: 06 March 2023 20:59 > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff > on seamless M/N change > > From: Ville Syrjälä > > When we change the M

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pmu: Use common freq functions with sysfs (rev2)

== Series Details == Series: drm/i915/pmu: Use common freq functions with sysfs (rev2) URL : https://patchwork.freedesktop.org/series/114814/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114814v2_full ===

Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

On Fri, Mar 10, 2023 at 06:04:02AM +, Liu, Yi L wrote: > > From: Tian, Kevin > > Sent: Friday, March 10, 2023 1:31 PM > > > > > From: Yi Liu > > > Sent: Wednesday, March 8, 2023 9:29 PM > > > > > > This is another method to issue PCI hot reset for the users that bounds > > > device to a posit

Re: [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()

On Wed, Mar 08, 2023 at 05:13:40AM -0800, Yi Liu wrote: > After making the no-DMA drivers (samples/vfio-mdev) providing iommufd > callbacks, __vfio_register_dev() should check the presence of the iommufd > callbacks if CONFIG_IOMMUFD is enabled. > > Signed-off-by: Yi Liu > --- > drivers/vfio/vfi

Re: [Intel-gfx] [PATCH v1 4/5] Samples/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers

On Wed, Mar 08, 2023 at 05:13:39AM -0800, Yi Liu wrote: > This harmonizes the no-DMA devices (the vfio-mdev sample drivers) with > the emulated devices (gvt-g, vfio-ap etc.). It makes it easier to add > BIND_IOMMUFD user interface which requires to return an iommufd ID to > represent the device/iom

Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl wrote: > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > From: Rob Clark > > > > Add a way to hint to the fence signaler of an upcoming deadline, such as > > vblank, which the fence waiter would prefer not to miss. This is to aid > > t

Re: [Intel-gfx] [PATCH v1 3/5] vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID

On Wed, Mar 08, 2023 at 05:13:38AM -0800, Yi Liu wrote: > vfio device cdev needs to return iommufd_access ID to userspace if > bind_iommufd succeeds. > > Signed-off-by: Yi Liu > --- > drivers/iommu/iommufd/device.c | 4 +++- > drivers/iommu/iommufd/selftest.c | 3 ++- > drivers/vfio/iommufd.c

Re: [Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units

On Fri, 10 Mar 2023 08:39:27 -0800, Umesh Nerlige Ramappa wrote: > Hi Umesh, > On Thu, Mar 09, 2023 at 03:57:48PM -0800, Dixit, Ashutosh wrote: > > On Tue, 07 Mar 2023 12:16:11 -0800, Umesh Nerlige Ramappa wrote: > >> > >> -static int gen8_configure_context(struct i915_gem_context *ctx, > >> +sta

Re: [Intel-gfx] [PATCH v1 2/5] vfio-iommufd: No need to record iommufd_ctx in vfio_device

On Wed, Mar 08, 2023 at 05:13:37AM -0800, Yi Liu wrote: > iommufd_ctx is stored in vfio_device for emulated devices per bind_iommufd. > However, as iommufd_access is created in bind, no more need to stored it > since iommufd_access implicitly stores it. > > Signed-off-by: Yi Liu > --- > drivers/

Re: [Intel-gfx] [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind()

On Wed, Mar 08, 2023 at 05:13:36AM -0800, Yi Liu wrote: > +int iommufd_access_set_ioas(struct iommufd_access *access, u32 ioas_id) > +{ > + struct iommufd_ioas *new_ioas = NULL, *cur_ioas; > + struct iommufd_ctx *ictx = access->ictx; > + struct iommufd_object *obj; > + int rc = 0;

Re: [Intel-gfx] [PATCH] drm/i915/active: Fix missing debug object activation

Hi Janusz, On 3/10/2023 4:19 PM, Janusz Krzysztofik wrote: Hi Nirmoy, On Friday, 10 March 2023 15:11:38 CET Nirmoy Das wrote: debug_active_activate() expected ref->count to be zero which is not true anymore as __i915_active_activate() calls debug_active_activate() after incrementing the count.

[Intel-gfx] ✓ Fi.CI.IGT: success for cpumask: fix incorrect cpumask scanning result checks

== Series Details == Series: cpumask: fix incorrect cpumask scanning result checks URL : https://patchwork.freedesktop.org/series/114882/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114882v1_full S

Re: [Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units

On Thu, Mar 09, 2023 at 03:57:48PM -0800, Dixit, Ashutosh wrote: On Tue, 07 Mar 2023 12:16:11 -0800, Umesh Nerlige Ramappa wrote: Hi Umesh, -static int gen8_configure_context(struct i915_gem_context *ctx, +static int gen8_configure_context(struct i915_perf_stream *stream, +

Re: [Intel-gfx] [bug report] drm/i915/dmc: add i915_to_dmc() and dmc->i915 and use them

On Fri, 10 Mar 2023, Dan Carpenter wrote: > On Thu, Mar 09, 2023 at 04:51:10PM +0200, Jani Nikula wrote: >> On Thu, 09 Mar 2023, Dan Carpenter wrote: >> > Hello Jani Nikula, >> > >> > This is a semi-automatic email about new static checker warnings. >> > >> > The patch 1b28c1c789d0: "drm/i915/dmc

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.

On Thu, Mar 09, 2023 at 05:03:52PM -0500, Rodrigo Vivi wrote: > On Thu, Mar 09, 2023 at 12:03:19AM +0200, Ville Syrjälä wrote: > > On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote: > > > uncore->lock only protects the forcewake domain itself, > > > not the register accesses. > > > > >

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display

On Fri, Mar 10, 2023 at 01:08:54PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup > during system resume on platforms without display > URL : https://patchwork.freedesktop.org/series/114866/ > State : success Thank

Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > From: Rob Clark > > Add a way to hint to the fence signaler of an upcoming deadline, such as > vblank, which the fence waiter would prefer not to miss. This is to aid > the fence signaler in making power management decisions, like boos

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: vblank stuff (rev6)

== Series Details == Series: drm/i915: vblank stuff (rev6) URL : https://patchwork.freedesktop.org/series/112170/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_112170v6_full Summary --- **SUCC

Re: [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()

On Fri, Mar 10, 2023 at 02:12:21PM +, Liu, Yi L wrote: > > The ops are NULL if !CONFIG_IOMMUFD. The previous code was OK > > because > > it checked for non-null bind before demanding the others be non-null. > > Now we want the no-dma drivers to reuse the emulated iommu op set, > so if CONFIG_

Re: [Intel-gfx] [PATCH] drm/i915/active: Fix missing debug object activation

Hi Nirmoy, On Friday, 10 March 2023 15:11:38 CET Nirmoy Das wrote: > debug_active_activate() expected ref->count to be zero > which is not true anymore as __i915_active_activate() calls > debug_active_activate() after incrementing the count. > > Fixes: 04240e30ed06 ("drm/i915: Skip taking acquire

Re: [Intel-gfx] [bug report] drm/i915/dmc: add i915_to_dmc() and dmc->i915 and use them

On Thu, Mar 09, 2023 at 04:51:10PM +0200, Jani Nikula wrote: > On Thu, 09 Mar 2023, Dan Carpenter wrote: > > Hello Jani Nikula, > > > > This is a semi-automatic email about new static checker warnings. > > > > The patch 1b28c1c789d0: "drm/i915/dmc: add i915_to_dmc() and > > dmc->i915 and use them

[Intel-gfx] [PATCH] drm/i915: Power management SAGV/QGV calculation rounding fix

Currently in our bandwidth calculations for QGV points we round up the calculations. Recently there was an update to BSpec, recommending to floor those calculations. The reasoning behind this was that, overestimating BW demand with that rounding can cause SAGV to use next QGV point, even though the

Re: [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()

> From: Jason Gunthorpe > Sent: Friday, March 10, 2023 10:04 PM > > On Fri, Mar 10, 2023 at 02:15:32AM +, Tian, Kevin wrote: > > > From: Liu, Yi L > > > Sent: Wednesday, March 8, 2023 9:14 PM > > > > > > After making the no-DMA drivers (samples/vfio-mdev) providing > iommufd > > > callbacks,

[Intel-gfx] [PATCH] drm/i915/active: Fix missing debug object activation

debug_active_activate() expected ref->count to be zero which is not true anymore as __i915_active_activate() calls debug_active_activate() after incrementing the count. Fixes: 04240e30ed06 ("drm/i915: Skip taking acquire mutex for no ref->active callback") Cc: Chris Wilson Cc: Tvrtko Ursulin Cc

[Intel-gfx] [PATCH 6.1 068/200] drm/i915: move a Kconfig symbol to unbreak the menu presentation

From: Randy Dunlap [ Upstream commit 0b93efca3659f6d55ed31cff6722dca5f6e4d6e2 ] Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT) into a list of other symbols that do have a dependency (on DRM_I915) breaks the driver menu presentation in 'make *config'. Relocate the DRM_

Re: [Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()

On Fri, Mar 10, 2023 at 02:15:32AM +, Tian, Kevin wrote: > > From: Liu, Yi L > > Sent: Wednesday, March 8, 2023 9:14 PM > > > > After making the no-DMA drivers (samples/vfio-mdev) providing iommufd > > callbacks, __vfio_register_dev() should check the presence of the iommufd > > callbacks if

[Intel-gfx] [PATCH 6.2 075/211] drm/i915: move a Kconfig symbol to unbreak the menu presentation

From: Randy Dunlap [ Upstream commit 0b93efca3659f6d55ed31cff6722dca5f6e4d6e2 ] Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT) into a list of other symbols that do have a dependency (on DRM_I915) breaks the driver menu presentation in 'make *config'. Relocate the DRM_

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display

== Series Details == Series: series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display URL : https://patchwork.freedesktop.org/series/114866/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_1148

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add guard page to ggtt->error_capture (rev8)

== Series Details == Series: drm/i915: add guard page to ggtt->error_capture (rev8) URL : https://patchwork.freedesktop.org/series/113560/ State : success == Summary == CI Bug Log - changes from CI_DRM_12836 -> Patchwork_113560v8 Summary --

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: add guard page to ggtt->error_capture (rev8)

== Series Details == Series: drm/i915: add guard page to ggtt->error_capture (rev8) URL : https://patchwork.freedesktop.org/series/113560/ 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 v2 1/1] drm/i915/mtl: Disable MC6 for MTL A step

On Fri, Mar 10, 2023 at 11:43:39AM +0530, Badal Nilawar wrote: > The Wa_14017073508 require to send Media Busy/Idle mailbox while > accessing Media tile. As of now it is getting handled while __gt_unpark, > __gt_park. But there are various corner cases where forcewakes are taken > without __gt_unpa

Re: [Intel-gfx] [PATCH] drm/i915: Preserve crtc_state->inherited during state clearing

> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, February 23, 2023 8:51 PM > To: intel-gfx@lists.freedesktop.org > Cc: sta...@vger.kernel.org > Subject: [Intel-gfx] [PATCH] drm/i915: Preserve crtc_state->inherited during > state > clearing > > From

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/debugfs: move IPS debugfs to hsw_ips.c (rev4)

== Series Details == Series: drm/i915/debugfs: move IPS debugfs to hsw_ips.c (rev4) URL : https://patchwork.freedesktop.org/series/114578/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_114578v4_full

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915/display: Implement fb_mmap callback function

Ping, please provide some feedback on this. On 3/7/2023 3:46 PM, Nirmoy Das wrote: If stolen memory allocation fails for fbdev, the driver will fallback to system memory. Calculation of smem_start is wrong for such framebuffer objs if the platform comes with no gmadr or no aperture. Solve this b

[Intel-gfx] [PATCH v2] drm/i915/gt: Update engine_init_common documentation

Change the function doc to reflect updated name. v2: un-kerneldoc the comment(Matt). :s/engines_init_common/engine_init_common(Andi) Cc: Andi Shyti Cc: Matt Roper Signed-off-by: Nirmoy Das Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++-- 1 file changed, 2 i

Re: [Intel-gfx] [PATCH v6 21/24] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

> From: Liu, Yi L > Sent: Friday, March 10, 2023 5:58 PM > > > From: Tian, Kevin > > Sent: Friday, March 10, 2023 5:02 PM > > > > > From: Liu, Yi L > > > Sent: Wednesday, March 8, 2023 9:29 PM > > > + > > > +static int vfio_device_cdev_probe_noiommu(struct vfio_device *device) > > > +{ > > > +

Re: [Intel-gfx] [PATCH v4 5/5] drm/i915/gt: Make sure that errors are propagated through request chains

On 08/03/2023 09:41, Andi Shyti wrote: Currently, when we perform operations such as clearing or copying large blocks of memory, we generate multiple requests that are executed in a chain. However, if one of these requests fails, we may not realize it unless it happens to be the last request in

Re: [Intel-gfx] [PATCH v6 20/24] vfio: Add cdev for vfio_device

> From: Tian, Kevin > Sent: Friday, March 10, 2023 4:49 PM > > > From: Liu, Yi L > > Sent: Wednesday, March 8, 2023 9:29 PM > > > > + /* > > +* Placing it before vfio_device_put_registration() to prevent > > +* new registration refcount increment by > > VFIO_GROUP_GET_DEVICE_FD > > +

Re: [Intel-gfx] [PATCH v6 21/24] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

> From: Tian, Kevin > Sent: Friday, March 10, 2023 5:02 PM > > > From: Liu, Yi L > > Sent: Wednesday, March 8, 2023 9:29 PM > > + > > +static int vfio_device_cdev_probe_noiommu(struct vfio_device *device) > > +{ > > + struct iommu_group *iommu_group; > > + int ret = 0; > > + > > + if (!IS_

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add guard page to ggtt->error_capture (rev7)

== Series Details == Series: drm/i915: add guard page to ggtt->error_capture (rev7) URL : https://patchwork.freedesktop.org/series/113560/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829_full -> Patchwork_113560v7_full

[Intel-gfx] [PATCH v2] drm/i915/mtl: Disable stolen memory backed FB for A0

Stolen memory is not usable for MTL A0 stepping beyond certain access size and we have no control over userspace access size of /dev/fb which can be backed by stolen memory. So disable stolen memory backed fb by setting i915->dsm.usable_size to zero. v2: remove hsdes reference and fix commit messa

Re: [Intel-gfx] [PATCH] drm/i915/gt: Update engine_init_common documentation

> > On Thu, Mar 09, 2023 at 05:58:52PM +0100, Nirmoy Das wrote: > > > Change the function doc to reflect updated name. > > > > > > Cc: Andi Shyti > > > Signed-off-by: Nirmoy Das > > > --- > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(

[Intel-gfx] [PATCH v6 2/2] drm/i915: add guard page to ggtt->error_capture

Write-combining memory allows speculative reads by CPU. ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try to prefetch memory beyond the error_capture, ie it tries to read memory pointed by next PTE in GGTT. If this PTE points to invalid address DMAR errors will occur. This behaviour was o

[Intel-gfx] [PATCH v6 0/2] drm/i915: add guard page to ggtt->error_capture

This patch tries to diminish plague of DMAR read errors present in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR). CI is usually tolerant for these errors, so the scale of the problem is not really visible. To show it I have counted lines containing DMAR read errors in dmesgs pro

[Intel-gfx] [PATCH v6 1/2] drm/i915/gt: introduce vm->scratch_range callback

The callback will be responsible for setting scratch page PTEs for specified range. In contrast to clear_range it cannot be optimized to nop. It will be used by code adding guard pages. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 23 +++ drive

Re: [Intel-gfx] [PATCH v6 13/24] vfio/iommufd: Split the compat_ioas attach out from vfio_iommufd_bind()

> From: Liu, Yi L > Sent: Friday, March 10, 2023 4:22 PM > > > > > > +int vfio_iommufd_attach_compat_ioas(struct vfio_device *vdev, > > > + struct iommufd_ctx *ictx) > > > +{ > > > + u32 ioas_id; > > > + int ret; > > > + > > > + lockdep_assert_held(&vdev->dev_set->lock

  1   2   >