John Harrison [Sat, 11 Dec 2021 06:58:58 +0000 (22:58 -0800)]
drm/i915/guc: Flag an error if an engine reset fails
If GuC encounters an error during engine reset, the i915 driver
promotes to full GT reset. This includes an info message about why the
reset is happening. However, that is not treated as a failure by any
of the CI systems because resets are an expected occurrance during
testing. This kind of failure is a major problem and should never
happen. So, complain more loudly and make sure CI notices.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211211065859.2248188-4-John.C.Harrison@Intel.com
John Harrison [Sat, 11 Dec 2021 06:58:57 +0000 (22:58 -0800)]
drm/i915/guc: Increase GuC log size for CONFIG_DEBUG_GEM
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
bigger GuC logs are extremely useful for almost any regression debug.
So enable bigger logs for DEBUG_GEM builds as well.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211211065859.2248188-3-John.C.Harrison@Intel.com
John Harrison [Sat, 11 Dec 2021 06:58:56 +0000 (22:58 -0800)]
drm/i915/guc: Speed up GuC log dumps
Add support for telling the debugfs interface the size of the GuC log
dump in advance. Without that, the underlying framework keeps calling
the 'show' function with larger and larger buffer allocations until it
fits. That means reading the log from graphics memory many times - 16
times with the full 18MB log size.
v2: Don't return error codes from size query. Report overflow in the
error dump as well (review feedback from Daniele).
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211211065859.2248188-2-John.C.Harrison@Intel.com
Maarten Lankhorst [Thu, 16 Dec 2021 14:27:39 +0000 (15:27 +0100)]
drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes.
Now that we require locking to evict, multiple vmas from the same object
might not be evicted. This is expected and required, because execbuf will
move to short-term pinning by using the lock only. This will cause these
tests to fail, because they create a ton of vma's for the same object.
Unbind manually to prevent spurious -ENOSPC in those mock tests.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211216142749.1966107-8-maarten.lankhorst@linux.intel.com
Maarten Lankhorst [Thu, 16 Dec 2021 14:27:38 +0000 (15:27 +0100)]
drm/i915: Ensure gem_contexts selftests work with unbind changes, v2.
In the next commits, we may not evict when refcount = 0.
igt_vm_isolation() continuously tries to pin/unpin at same address,
but also calls put() on the object, which means the object may not
be unpinned in time.
Instead of this, re-use the same object over and over, so they can
be unbound as required.
Changes since v1:
- Fix cleaning up obj_b on failure. (Matt)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211216142749.1966107-7-maarten.lankhorst@linux.intel.com
Maarten Lankhorst [Thu, 16 Dec 2021 14:27:37 +0000 (15:27 +0100)]
drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2.
We will need the lock to unbind the vma, and wait for bind to complete.
Remove the special casing for the !ww path, and force ww locking for all.
Changes since v1:
- Pass err to for_i915_gem_ww handling for -EDEADLK handling.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211216142749.1966107-6-maarten.lankhorst@linux.intel.com
Maarten Lankhorst [Thu, 16 Dec 2021 14:27:36 +0000 (15:27 +0100)]
drm/i915: Take object lock in i915_ggtt_pin if ww is not set
i915_vma_wait_for_bind needs the vma lock held, fix the caller.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211216142749.1966107-5-maarten.lankhorst@linux.intel.com
Maarten Lankhorst [Thu, 16 Dec 2021 14:27:35 +0000 (15:27 +0100)]
drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v3.
Big delta, but boils down to moving set_pages to i915_vma.c, and removing
the special handling, all callers use the defaults anyway. We only remap
in ggtt, so default case will fall through.
Because we still don't require locking in i915_vma_unpin(), handle this by
using xchg in get_pages(), as it's locked with obj->mutex, and cmpxchg in
unpin, which only fails if we race a against a new pin.
Changes since v1:
- aliasing gtt sets ZERO_SIZE_PTR, not -ENODEV, remove special case
from __i915_vma_get_pages(). (Matt)
Changes since v2:
- Free correct old pages in __i915_vma_get_pages(). (Matt)
Remove race of clearing vma->pages accidentally from put,
free it but leave it set, as only get has the lock.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211216142749.1966107-4-maarten.lankhorst@linux.intel.com
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Maarten Lankhorst [Thu, 16 Dec 2021 14:27:34 +0000 (15:27 +0100)]
drm/i915: Change shrink ordering to use locking around unbinding.
Call drop_pages with the gem object lock held, instead of the other
way around. This will allow us to drop the vma bindings with the
gem object lock held.
We plan to require the object lock for unpinning in the future,
and this is an easy target.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211216142749.1966107-3-maarten.lankhorst@linux.intel.com
Maarten Lankhorst [Thu, 16 Dec 2021 14:27:33 +0000 (15:27 +0100)]
drm/i915: Remove unused bits of i915_vma/active api
When reworking the code to move the eviction fence to the object,
the best code is removed code.
Remove some functions that are unused, and change the function definition
if it's only used in 1 place.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
[mlankhorst: Remove new use of i915_active_has_exclusive]
Link: https://patchwork.freedesktop.org/patch/msgid/20211216142749.1966107-2-maarten.lankhorst@linux.intel.com
Andi Shyti [Tue, 14 Dec 2021 19:33:40 +0000 (21:33 +0200)]
drm/i915: Rename i915->gt to i915->gt0
In preparation of the multitile support, highlight the root GT by
calling it gt0 inside the drm i915 private data.
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-11-andi.shyti@linux.intel.com
Michał Winiarski [Tue, 14 Dec 2021 19:33:39 +0000 (21:33 +0200)]
drm/i915: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-10-andi.shyti@linux.intel.com
Andi Shyti [Tue, 14 Dec 2021 19:33:38 +0000 (21:33 +0200)]
drm/i915/pxp: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-9-andi.shyti@linux.intel.com
Andi Shyti [Tue, 14 Dec 2021 19:33:37 +0000 (21:33 +0200)]
drm/i915/selftests: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-8-andi.shyti@linux.intel.com
Michał Winiarski [Tue, 14 Dec 2021 19:33:36 +0000 (21:33 +0200)]
drm/i915/gvt: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-7-andi.shyti@linux.intel.com
Michał Winiarski [Tue, 14 Dec 2021 19:33:35 +0000 (21:33 +0200)]
drm/i915/gem: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-6-andi.shyti@linux.intel.com
Michał Winiarski [Tue, 14 Dec 2021 19:33:34 +0000 (21:33 +0200)]
drm/i915/gt: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-5-andi.shyti@linux.intel.com
Michał Winiarski [Tue, 14 Dec 2021 19:33:33 +0000 (21:33 +0200)]
drm/i915/display: Use to_gt() helper
Use to_gt() helper consistently throughout the codebase.
Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-4-andi.shyti@linux.intel.com
Michał Winiarski [Tue, 14 Dec 2021 19:33:32 +0000 (21:33 +0200)]
drm/i915: Introduce to_gt() helper
To allow further refactoring and abstract away the fact that GT is
stored inside i915 private.
No functional changes.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-3-andi.shyti@linux.intel.com
Michał Winiarski [Tue, 14 Dec 2021 19:33:31 +0000 (21:33 +0200)]
drm/i915: Store backpointer to GT in uncore
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
At this point the early initialization of the gt needs to be
broken in two parts where the first is needed to assign to the gt
the i915 private data pointer and the uncore. A temporary
function has been made and the two parts are
__intel_gt_init_early() and intel_gt_init_early(). This split
will be fixed in the future with the multitile patch.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-2-andi.shyti@linux.intel.com
Matthew Brost [Tue, 14 Dec 2021 17:05:00 +0000 (09:05 -0800)]
drm/i915/guc: Selftest for stealing of guc ids
Testing the stealing of guc ids is hard from user space as we have 64k
guc_ids. Add a selftest, which artificially reduces the number of guc
ids, and forces a steal.
The test creates a spinner which is used to block all subsequent
submissions until it completes. Next, a loop creates a context and a NOP
request each iteration until the guc_ids are exhausted (request creation
returns -EAGAIN). The spinner is ended, unblocking all requests created
in the loop. At this point all guc_ids are exhausted but are available
to steal. Try to create another request which should successfully steal
a guc_id. Wait on last request to complete, idle GPU, verify a guc_id
was stolen via a counter, and exit the test. Test also artificially
reduces the number of guc_ids so the test runs in a timely manner.
v2:
(John Harrison)
- s/stole/stolen
- Fix some wording in test description
- Rework indexing into context array
- Add test description to commit message
- Fix typo in commit message
(Checkpatch)
- s/guc/(guc) in NUMBER_MULTI_LRC_GUC_ID
v3:
(John Harrison)
- Set array value to NULL after extracting error
- Fix a few typos in comments / error messages
- Delete redundant comment in commit message
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214170500.28569-8-matthew.brost@intel.com
Matthew Brost [Tue, 14 Dec 2021 17:04:59 +0000 (09:04 -0800)]
drm/i915/guc: Kick G2H tasklet if no credits
Let's be paranoid and kick the G2H tasklet, which dequeues messages, if
G2H credits are exhausted.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214170500.28569-7-matthew.brost@intel.com
Matthew Brost [Tue, 14 Dec 2021 17:04:58 +0000 (09:04 -0800)]
drm/i915/guc: Add extra debug on CT deadlock
Print CT state (H2G + G2H head / tail pointers, credits) on CT
deadlock.
v2:
(John Harrison)
- Add units to debug messages
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214170500.28569-6-matthew.brost@intel.com
John Harrison [Tue, 14 Dec 2021 17:04:57 +0000 (09:04 -0800)]
drm/i915/guc: Don't hog IRQs when destroying contexts
While attempting to debug a CT deadlock issue in various CI failures
(most easily reproduced with gem_ctx_create/basic-files), I was seeing
CPU deadlock errors being reported. This were because the context
destroy loop was blocking waiting on H2G space from inside an IRQ
spinlock. There no was deadlock as such, it's just that the H2G queue
was full of context destroy commands and GuC was taking a long time to
process them. However, the kernel was seeing the large amount of time
spent inside the IRQ lock as a dead CPU. Various Bad Things(tm) would
then happen (heartbeat failures, CT deadlock errors, outstanding H2G
WARNs, etc.).
Re-working the loop to only acquire the spinlock around the list
management (which is all it is meant to protect) rather than the
entire destroy operation seems to fix all the above issues.
v2:
(John Harrison)
- Fix typo in comment message
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214170500.28569-5-matthew.brost@intel.com
Matthew Brost [Tue, 14 Dec 2021 17:04:56 +0000 (09:04 -0800)]
drm/i915/guc: Remove racey GEM_BUG_ON
A full GT reset can race with the last context put resulting in the
context ref count being zero but the destroyed bit not yet being set.
Remove GEM_BUG_ON in scrub_guc_desc_for_outstanding_g2h that asserts the
destroyed bit must be set in ref count is zero.
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214170500.28569-4-matthew.brost@intel.com
Matthew Brost [Tue, 14 Dec 2021 17:04:55 +0000 (09:04 -0800)]
drm/i915/guc: Only assign guc_id.id when stealing guc_id
Previously assigned whole guc_id structure (list, spin lock) which is
incorrect, only assign the guc_id.id.
Fixes:
0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214170500.28569-3-matthew.brost@intel.com
Matthew Brost [Tue, 14 Dec 2021 17:04:54 +0000 (09:04 -0800)]
drm/i915/guc: Use correct context lock when callig clr_context_registered
s/ce/cn/ when grabbing guc_state.lock before calling
clr_context_registered.
Fixes:
0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211214170500.28569-2-matthew.brost@intel.com
Lucas De Marchi [Thu, 2 Dec 2021 00:30:48 +0000 (16:30 -0800)]
drm/i915: replace X86_FEATURE_PAT with pat_enabled()
PAT can be disabled on boot with "nopat" in the command line. Replace
one x86-ism with another, which is slightly more correct to prepare for
supporting other architectures.
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211202003048.1015511-1-lucas.demarchi@intel.com
Matthew Auld [Mon, 13 Dec 2021 12:55:30 +0000 (12:55 +0000)]
drm/i915/debugfs: add noreclaim annotations
We have a debugfs hook to directly call into i915_gem_shrink() with the
fs_reclaim acquire annotations to simulate hitting direct reclaim.
However we should also annotate this with memalloc_noreclaim, which will
set PF_MEMALLOC for us on the current context, to ensure we can't
re-enter direct reclaim(just like "real" direct reclaim does). This is
an issue now that ttm_bo_validate could potentially be called here,
which might try to allocate a tiny amount of memory to hold the new
ttm_resource struct, as per the below splat:
[ 2507.913844] WARNING: possible recursive locking detected
[ 2507.913848] 5.16.0-rc4+ #5 Tainted: G U
[ 2507.913853] --------------------------------------------
[ 2507.913856] gem_exec_captur/1825 is trying to acquire lock:
[ 2507.913861]
ffffffffb9df2500 (fs_reclaim){..}-{0:0}, at: kmem_cache_alloc_trace+0x30/0x390
[ 2507.913875]
but task is already holding lock:
[ 2507.913879]
ffffffffb9df2500 (fs_reclaim){..}-{0:0}, at: i915_drop_caches_set+0x1c9/0x2c0 [i915]
[ 2507.913962]
other info that might help us debug this:
[ 2507.913966] Possible unsafe locking scenario:
[ 2507.913970] CPU0
[ 2507.913973] ----
[ 2507.913975] lock(fs_reclaim);
[ 2507.913979] lock(fs_reclaim);
[ 2507.913983]
DEADLOCK ***
[ 2507.913988] May be due to missing lock nesting notation
[ 2507.913992] 4 locks held by gem_exec_captur/1825:
[ 2507.913997] #0:
ffff888101f6e460 (sb_writers#17){..}-{0:0}, at: ksys_write+0xe9/0x1b0
[ 2507.914009] #1:
ffff88812d99e2b8 (&attr->mutex){..}-{3:3}, at: simple_attr_write+0xbb/0x220
[ 2507.914019] #2:
ffffffffb9df2500 (fs_reclaim){..}-{0:0}, at: i915_drop_caches_set+0x1c9/0x2c0 [i915]
[ 2507.914085] #3:
ffff8881b4a11b20 (reservation_ww_class_mutex){..}-{3:3}, at: ww_mutex_trylock+0x43f/0xcb0
[ 2507.914097]
stack backtrace:
[ 2507.914102] CPU: 0 PID: 1825 Comm: gem_exec_captur Tainted: G U 5.16.0-rc4+ #5
[ 2507.914109] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021
[ 2507.914115] Call Trace:
[ 2507.914118] <TASK>
[ 2507.914121] dump_stack_lvl+0x59/0x73
[ 2507.914128] __lock_acquire.cold+0x227/0x3b0
[ 2507.914135] ? lockdep_hardirqs_on_prepare+0x410/0x410
[ 2507.914141] ? __lock_acquire+0x23ca/0x5000
[ 2507.914147] lock_acquire+0x19c/0x4b0
[ 2507.914152] ? kmem_cache_alloc_trace+0x30/0x390
[ 2507.914157] ? lock_release+0x690/0x690
[ 2507.914163] ? lock_is_held_type+0xe4/0x140
[ 2507.914170] ? ttm_sys_man_alloc+0x47/0xb0 [ttm]
[ 2507.914178] fs_reclaim_acquire+0x11a/0x160
[ 2507.914183] ? kmem_cache_alloc_trace+0x30/0x390
[ 2507.914188] kmem_cache_alloc_trace+0x30/0x390
[ 2507.914192] ? lock_release+0x37f/0x690
[ 2507.914198] ttm_sys_man_alloc+0x47/0xb0 [ttm]
[ 2507.914206] ttm_bo_pipeline_gutting+0x70/0x440 [ttm]
[ 2507.914214] ? ttm_mem_io_free+0x150/0x150 [ttm]
[ 2507.914221] ? lock_is_held_type+0xe4/0x140
[ 2507.914227] ttm_bo_validate+0x2fb/0x370 [ttm]
[ 2507.914234] ? lock_acquire+0x19c/0x4b0
[ 2507.914239] ? ttm_bo_bounce_temp_buffer.constprop.0+0xf0/0xf0 [ttm]
[ 2507.914246] ? lock_acquire+0x131/0x4b0
[ 2507.914251] ? lock_is_held_type+0xe4/0x140
[ 2507.914257] i915_ttm_shrinker_release_pages+0x2bc/0x490 [i915]
[ 2507.914339] ? i915_ttm_swap_notify+0x130/0x130 [i915]
[ 2507.914429] ? i915_gem_object_release_mmap_offset+0x32/0x250 [i915]
[ 2507.914529] i915_gem_shrink+0xb14/0x1290 [i915]
[ 2507.914616] ? ___i915_gem_object_make_shrinkable+0x3e0/0x3e0 [i915]
[ 2507.914698] ? _raw_spin_unlock_irqrestore+0x2d/0x60
[ 2507.914705] ? track_intel_runtime_pm_wakeref+0x180/0x230 [i915]
[ 2507.914777] i915_gem_shrink_all+0x4b/0x70 [i915]
[ 2507.914857] i915_drop_caches_set+0x227/0x2c0 [i915]
Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211213125530.3960007-1-matthew.auld@intel.com
Robert Beckett [Fri, 10 Dec 2021 19:50:05 +0000 (19:50 +0000)]
drm/i915/ttm: fix large buffer population trucation
ttm->num_pages is uint32_t which was causing very large buffers to
only populate a truncated size.
This fixes gem_create@create-clear igt test on large memory systems.
Fixes:
7ae034590cea ("drm/i915/ttm: add tt shmem backend")
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211210195005.2582884-1-bob.beckett@collabora.com
Chris Wilson [Wed, 8 Dec 2021 15:34:04 +0000 (21:04 +0530)]
drm/i915: Test all device memory on probing
This extends the previous sanitychecking of device memory to read/write
all the memory on the device during the device probe, ala memtest86,
as an optional module parameter: i915.memtest=1. This is not expected to
be fast, but a reasonably thorough verfification that the device memory
is accessible and doesn't return bit errors.
v2: Rebased.
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208153404.27546-4-ramalingam.c@intel.com
Chris Wilson [Thu, 9 Dec 2021 16:26:20 +0000 (21:56 +0530)]
drm/i915: Sanitycheck device iomem on probe
As we setup the memory regions for the device, give each a quick test to
verify that we can read and write to the full iomem range. This ensures
that our physical addressing for the device's memory is correct, and
some reassurance that the memory is functional.
v2: wrapper for memtest [Chris]
v3: Removed the unused ptr i915 [Chris]
v4: used the %pa for the resource_size_t.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211209162620.5218-1-ramalingam.c@intel.com
Chris Wilson [Wed, 8 Dec 2021 15:34:02 +0000 (21:04 +0530)]
drm/i915: Exclude reserved stolen from driver use
Remove the portion of stolen memory reserved for private use from driver
access.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208153404.27546-2-ramalingam.c@intel.com
Thomas Hellström [Thu, 9 Dec 2021 14:13:04 +0000 (15:13 +0100)]
drm/i915: Don't leak the capture list items
When we recently converted the capture code to use vma snapshots,
we forgot to free the struct i915_capture_list list items after use.
Fix that by bringing back a kfree.
Fixes:
ff20afc4cee7 ("drm/i915: Update error capture code to avoid using the current vma state")
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211209141304.393479-1-thomas.hellstrom@linux.intel.com
Daniele Ceraolo Spurio [Sat, 11 Dec 2021 00:07:56 +0000 (16:07 -0800)]
drm/i915/guc: support bigger RSA keys
Some of the newer HW will use bigger RSA keys to authenticate the GuC
binary. On those platforms the HW will read the key from memory instead
of the RSA registers, so we need to copy it in a dedicated vma, like we
do for the HuC. The address of the key is provided to the HW via the
first RSA register.
v2: clarify that the RSA behavior is hardcoded in the bootrom (Matt)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211211000756.1698923-4-daniele.ceraolospurio@intel.com
Michal Wajdeczko [Sat, 11 Dec 2021 00:07:55 +0000 (16:07 -0800)]
drm/i915/uc: Prepare for different firmware key sizes
Future GuC/HuC firmwares might be signed with different key sizes.
Don't assume that it must be always 2048 bits long.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211211000756.1698923-3-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Sat, 11 Dec 2021 00:07:54 +0000 (16:07 -0800)]
drm/i915/uc: correctly track uc_fw init failure
The FAILURE state of uc_fw currently implies that the fw is loadable
(i.e init completed), so we can't use it for init failures and instead
need a dedicated error code.
Note that this currently does not cause any issues because if we fail to
init any of the firmwares we abort the load, but better be accurate
anyway in case things change in the future.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211211000756.1698923-2-daniele.ceraolospurio@intel.com
Thomas Hellström [Wed, 8 Dec 2021 08:22:45 +0000 (09:22 +0100)]
drm/i915: Fix coredump of perma-pinned vmas
When updating the error capture code and introducing vma snapshots,
we introduced code to hold the vma in memory while capturing it,
calling i915_active_acquire_if_busy(). Now that function isn't relevant
for perma-pinned vmas and caused important vmas to be dropped from the
coredump. Like for example the GuC log.
Fix this by instead requiring those vmas to be pinned while capturing.
Tested by running the initial subtests of the gem_exec_capture igt test
with GuC submission enabled and verifying that a GuC log blob appears
in the output.
Fixes:
ff20afc4cee7 ("drm/i915: Update error capture code to avoid using the current vma state")
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reported-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208082245.86933-1-thomas.hellstrom@linux.intel.com
Sebastian Andrzej Siewior [Fri, 10 Dec 2021 20:44:17 +0000 (21:44 +0100)]
drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock().
This is a revert of commits
d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as irqsafe")
6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by timeline->mutex")
6dcb85a0ad990 ("drm/i915: Hold irq-off for the entire fake lock period")
The existing code leads to a different behaviour depending on whether
lockdep is enabled or not. Any following lock that is acquired without
disabling interrupts (but needs to) will not be noticed by lockdep.
This it not just a lockdep annotation but is used but an actual mutex_t
that is properly used as a lock but in case of __timeline_mark_lock()
lockdep is only told that it is acquired but no lock has been acquired.
It appears that its purpose is just satisfy the lockdep_assert_held()
check in intel_context_mark_active(). The other problem with disabling
interrupts is that on PREEMPT_RT interrupts are also disabled which
leads to problems for instance later during memory allocation.
Add a CONTEXT_IS_PARKING bit to intel_engine_cs and set_bit/clear_bit it
instead of mutex_acquire/mutex_release. Use test_bit in the two
identified spots which relied on the lockdep annotation.
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YbO8Ie1Nj7XcQPNQ@linutronix.de
John Harrison [Fri, 10 Dec 2021 04:40:22 +0000 (20:40 -0800)]
drm/i915/guc: Don't go bang in GuC log if no GuC
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211210044022.1842938-5-John.C.Harrison@Intel.com
John Harrison [Fri, 10 Dec 2021 04:40:19 +0000 (20:40 -0800)]
drm/i915/uc: Allow platforms to have GuC but not HuC
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211210044022.1842938-2-John.C.Harrison@Intel.com
Umesh Nerlige Ramappa [Tue, 7 Dec 2021 02:02:39 +0000 (18:02 -0800)]
drm/i915/pmu: Fix wakeref leak in PMU busyness during reset
GuC PMU busyness gets gt wakeref if awake, but fails to release the
wakeref if a reset is in progress. Release the wakeref if it was
acquried successfully.
v2: Simplify the fix (Ashutosh)
Fixes:
2a67b18e67f3 ("drm/i915/pmu: Fix synchronization of PMU callback with reset")
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211207020239.43402-1-umesh.nerlige.ramappa@intel.com
Umesh Nerlige Ramappa [Wed, 8 Dec 2021 18:33:13 +0000 (10:33 -0800)]
drm/i915/pmu: Wait longer for busyness data to be available from GuC
live_engine_busy_stats waits for busyness to start ticking before
sampling busyness for the test sample duration. The wait accesses an
MMIO register and the uncore call to read it takes up to 3 ms in the
worst case. This can result in the wait timing out since the MMIO read
itself consumes up the timeout of 500us. Increase the timeout to a
larger value of 10ms to account for the MMIO read time.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4536
Fixes:
77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu")
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208183313.13126-1-umesh.nerlige.ramappa@intel.com
Matthew Auld [Wed, 8 Dec 2021 14:16:13 +0000 (19:46 +0530)]
drm/i915: enforce min page size for scratch
If the device needs 64K minimum GTT pages for device local-memory,
like on XEHPSDV, then we need to fail the allocation if we can't
meet it, instead of falling back to 4K pages, otherwise we can't
safely support the insertion of device local-memory pages for
this vm, since the HW expects the correct physical alignment and
size for every PTE, if we mark the page-table as 64K GTT mode.
v2: s/userpsace/userspace [Thomas]
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208141613.7251-5-ramalingam.c@intel.com
Matthew Auld [Wed, 8 Dec 2021 14:16:12 +0000 (19:46 +0530)]
drm/i915/gtt/xehpsdv: move scratch page to system memory
On some platforms the hw has dropped support for 4K GTT pages when
dealing with LMEM, and due to the design of 64K GTT pages in the hw, we
can only mark the *entire* page-table as operating in 64K GTT mode,
since the enable bit is still on the pde, and not the pte. And since we
we still need to allow 4K GTT pages for SMEM objects, we can't have a
"normal" 4K page-table with scratch pointing to LMEM, since that's
undefined from the hw pov. The simplest solution is to just move the 64K
scratch page to SMEM on such platforms and call it a day, since that
should work for all configurations.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208141613.7251-4-ramalingam.c@intel.com
Matthew Auld [Wed, 8 Dec 2021 15:48:54 +0000 (21:18 +0530)]
drm/i915/xehpsdv: set min page-size to 64K
Conditionally allocate LMEM with 64K granularity, since 4K page support
for LMEM will be dropped on some platforms when using the PPGTT.
v2:
updated commit msg [Thomas]
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208154854.28037-1-ramalingam.c@intel.com
Stuart Summers [Wed, 8 Dec 2021 14:16:10 +0000 (19:46 +0530)]
drm/i915: Add has_64k_pages flag
Add a new platform flag, has_64k_pages, to mark the requirement of 64K
GTT page sizes or larger for device local memory access.
Also implies that we require or at least support the compact PT layout
for the ppGTT when using 64K GTT pages.
v2: More explanation for the flag [Thomas]
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208141613.7251-2-ramalingam.c@intel.com
Tejas Upadhyay [Mon, 6 Dec 2021 08:10:26 +0000 (13:40 +0530)]
drm/i915/gt: Use hw_engine_masks as reset_domains
We need a way to reset engines by their reset domains.
This change sets up way to fetch reset domains of each
engine globally.
Changes since V1:
- Use static reset domain array - Ville and Tvrtko
- Use BUG_ON at appropriate place - Tvrtko
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206081026.4024401-1-tejaskumarx.surendrakumar.upadhyay@intel.com
Matthew Auld [Mon, 6 Dec 2021 11:25:39 +0000 (11:25 +0000)]
drm/i915/selftests: handle object rounding
Ensure we account for any object rounding due to min_page_size
restrictions.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206112539.3149779-4-matthew.auld@intel.com
Matthew Auld [Mon, 6 Dec 2021 11:25:38 +0000 (11:25 +0000)]
drm/i915/migrate: fix length calculation
No need to insert PTEs for the PTE window itself, also foreach expects a
length not an end offset, which could be gigantic here with a second
engine.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206112539.3149779-3-matthew.auld@intel.com
Matthew Auld [Mon, 6 Dec 2021 11:25:37 +0000 (11:25 +0000)]
drm/i915/migrate: fix offset calculation
Ensure we add the engine base only after we calculate the qword offset
into the PTE window.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206112539.3149779-2-matthew.auld@intel.com
Matthew Auld [Mon, 6 Dec 2021 11:25:36 +0000 (11:25 +0000)]
drm/i915/migrate: don't check the scratch page
The scratch page might not be allocated in LMEM(like on DG2), so instead
of using that as the deciding factor for where the paging structures
live, let's just query the pt before mapping it.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206112539.3149779-1-matthew.auld@intel.com
Bruce Chang [Tue, 7 Dec 2021 00:38:45 +0000 (16:38 -0800)]
drm/i915/selftests: Follow up on increase timeout in i915_gem_contexts selftests
Follow up on below commit, to increase the timeout further on new
platforms, to accomodate the additional time required for the completion
of guc submissions for numerous requests created in loop.
commit
5e076529e2652244ec20a86d8f99ba634a16c4f4
Author: Matthew Brost <matthew.brost@intel.com>
Date: Mon Jul 26 20:17:03 2021 -0700
drm/i915/selftests: Increase timeout in i915_gem_contexts selftests
Signed-off-by: Bruce Chang <yu.bruce.chang@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211207003845.12419-1-yu.bruce.chang@intel.com
Michael Cheng [Mon, 6 Dec 2021 21:52:45 +0000 (13:52 -0800)]
drm/i915: Introduce new macros for i915 PTE
Certain functions within i915 uses macros that are defined for
specific architectures by the mmu, such as _PAGE_RW and _PAGE_PRESENT
(Some architectures don't even have these macros defined, like ARM64).
Instead of re-using bits defined for the CPU, we should use bits
defined for i915. This patch introduces two new 64 bit macros,
GEN8_PAGE_PRESENT and GEN8_PAGE_RW, to check for bits 0 and 1 and, to
replace all occurrences of _PAGE_RW and _PAGE_PRESENT within i915.
v2(Michael Cheng): Use GEN8_ instead of I915_
Signed-off-by: Michael Cheng <michael.cheng@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
[ Move defines together with other GEN8 defines ]
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206215245.513677-2-michael.cheng@intel.com
Dan Carpenter [Thu, 2 Dec 2021 04:48:31 +0000 (20:48 -0800)]
drm/i915: Fix error pointer dereference in i915_gem_do_execbuffer()
Originally "out_fence" was set using out_fence = sync_file_create() but
which returns NULL, but now it is set with out_fence = eb_requests_create()
which returns error pointers. The error path needs to be modified to
avoid an Oops in the "goto err_request;" path.
Fixes:
544460c33821 ("drm/i915: Multi-BB execbuf")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211202044831.29583-1-matthew.brost@intel.com
Raviteja Goud Talla [Fri, 3 Dec 2021 14:56:03 +0000 (20:26 +0530)]
drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()
Bspec page says "Reset: BUS", Accordingly moving w/a's:
Wa_1407352427,Wa_1406680159 to proper function icl_gt_workarounds_init()
Which will resolve guc enabling error
v2:
- Previous patch rev2 was created by email client which caused the
Build failure, This v2 is to resolve the previous broken series
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Raviteja Goud Talla <ravitejax.goud.talla@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211203145603.4006937-1-ravitejax.goud.talla@intel.com
Ramalingam C [Tue, 16 Nov 2021 17:48:17 +0000 (09:48 -0800)]
drm/i915/dg2: Add Wa_16013000631
Invalidate IC cache through pipe control command as part of the ctx
restore flow through indirect ctx pointer.
v2:
- Move pipe control from xcs indirect context to the rcs indirect
context. We'll eventually need this on the CCS engines too, but
support for those hasn't landed yet.
Cc: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116174818.2128062-5-matthew.d.roper@intel.com
Matt Roper [Tue, 16 Nov 2021 17:48:16 +0000 (09:48 -0800)]
drm/i915/dg2: Add Wa_16011777198
Coarse power gating for render should not be enabled on some DG2
steppings.
Bspec: 52698
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116174818.2128062-4-matthew.d.roper@intel.com
José Roberto de Souza [Fri, 19 Nov 2021 14:09:31 +0000 (06:09 -0800)]
drm/i915: Add workaround numbers to GEN7_COMMON_SLICE_CHICKEN1 whitelisting
Those two workarounds needs to be implemented in UMD, KMD only needs
to whitelist the registers, so here only adding the workaround number
to facilitate future workaroud table checks.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211119140931.32791-2-jose.souza@intel.com
José Roberto de Souza [Fri, 19 Nov 2021 14:09:30 +0000 (06:09 -0800)]
Revert "drm/i915: Implement Wa_1508744258"
This workarounds are causing hangs, because I missed the fact that it
needs to be enabled for all cases and disabled when doing a resolve
pass.
So KMD only needs to whitelist it and UMD will be the one setting it
on per case.
This reverts commit
28ec02c9cbebf3feeaf21a59df9dfbc02bda3362.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4145
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Fixes:
28ec02c9cbeb ("drm/i915: Implement Wa_1508744258")
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211119140931.32791-1-jose.souza@intel.com
Thomas Hellström [Mon, 29 Nov 2021 20:22:45 +0000 (21:22 +0100)]
drm/i915: Update error capture code to avoid using the current vma state
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correct memory, the snapshots take
references on relevant sg-tables and memory regions.
Also move the capture list allocation out of the fence signaling
critical path and use the CONFIG_DRM_I915_CAPTURE_ERROR define to
avoid compiling in members and functions used for error capture
when they're not used.
Finally, Introduce lockdep annotation.
v4:
- Break out the capture allocation mode change to a separate patch.
v5:
- Fix compilation error in the !CONFIG_DRM_I915_CAPTURE_ERROR case
(kernel test robot)
v6:
- Use #if IS_ENABLED() instead of #ifdef to match driver style.
- Move yet another change of allocation mode to the separate patch.
- Commit message rework due to patch reordering.
v7:
- Adjust for removal of region refcounting.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211129202245.472043-1-thomas.hellstrom@linux.intel.com
Zhou Qingyang [Tue, 30 Nov 2021 14:15:44 +0000 (22:15 +0800)]
drm/i915/gem: Fix a NULL pointer dereference in igt_request_rewind()
In igt_request_rewind(), mock_context(i915, "A") is assigned to ctx[0]
and used in i915_gem_context_get_engine(). There is a dereference
of ctx[0] in i915_gem_context_get_engine(), which could lead to a NULL
pointer dereference on failure of mock_context(i915, "A") .
So as mock_context(i915, "B").
Although this bug is not serious for it belongs to testing code, it is
better to be fixed to avoid unexpected failure in testing.
Fix this bugs by adding checks about ctx[0] and ctx[1].
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_DRM_I915_SELFTEST=y show no new warnings,
and our static analyzer no longer warns about this code.
References:
591c0fb85d1c ("drm/i915: Exercise request cancellation using a mock selftest")
[tursulin: Replaced fixes with references to avoid.]
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211130141545.153899-1-zhou1615@umn.edu
Tvrtko Ursulin [Fri, 26 Nov 2021 14:14:24 +0000 (14:14 +0000)]
drm/i915: Use per device iommu check
With both integrated and discrete Intel GPUs in a system, the current
global check of intel_iommu_gfx_mapped, as done from intel_vtd_active()
may not be completely accurate.
In this patch we add i915 parameter to intel_vtd_active() in order to
prepare it for multiple GPUs and we also change the check away from Intel
specific intel_iommu_gfx_mapped (global exported by the Intel IOMMU
driver) to probing the presence of IOMMU on a specific device using
device_iommu_mapped().
This will return true both for IOMMU pass-through and address translation
modes which matches the current behaviour. If in the future we wanted to
distinguish between these two modes we could either use
iommu_get_domain_for_dev() and check for __IOMMU_DOMAIN_PAGING bit
indicating address translation, or ask for a new API to be exported from
the IOMMU core code.
v2:
* Check for dmar translation specifically, not just iommu domain. (Baolu)
v3:
* Go back to plain "any domain" check for now, rewrite commit message.
v4:
* Use device_iommu_mapped. (Robin, Baolu)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211126141424.493753-1-tvrtko.ursulin@linux.intel.com
Matthew Brost [Tue, 16 Nov 2021 19:49:29 +0000 (11:49 -0800)]
drm/i915: Drop stealing of bits from i915_sw_fence function pointer
Rather than stealing bits from i915_sw_fence function pointer use
separate fields for function pointer and flags. If using two different
fields, the 4 byte alignment for the i915_sw_fence function pointer can
also be dropped.
v2:
(CI)
- Set new function field rather than flags in __i915_sw_fence_init
v3:
(Tvrtko)
- Remove BUG_ON(!fence->flags) in reinit as that will now blow up
- Only define fence->flags if CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is
defined
v4:
- Rebase, resend for CI
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116194929.10211-1-matthew.brost@intel.com
Umesh Nerlige Ramappa [Mon, 8 Nov 2021 21:10:57 +0000 (13:10 -0800)]
drm/i915/pmu: Fix synchronization of PMU callback with reset
Since the PMU callback runs in irq context, it synchronizes with gt
reset using the reset count. We could run into a case where the PMU
callback could read the reset count before it is updated. This has a
potential of corrupting the busyness stats.
In addition to the reset count, check if the reset bit is set before
capturing busyness.
In addition save the previous stats only if you intend to update them.
v2:
- The 2 reset counts captured in the PMU callback can end up being the
same if they were captured right after the count is incremented in the
reset flow. This can lead to a bad busyness state. Ensure that reset
is not in progress when the initial reset count is captured.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211108211057.68783-1-umesh.nerlige.ramappa@intel.com
Thomas Hellström [Mon, 29 Nov 2021 15:27:27 +0000 (16:27 +0100)]
dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()
If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
Fix this by clearing the PENDING_ERROR status if we return true in
dma_fence_array_signaled().
v2:
- Update Cc list, and add R-b.
Fixes:
1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: <stable@vger.kernel.org> # v5.4+
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thomas.hellstrom@linux.intel.com
Matthew Auld [Fri, 26 Nov 2021 11:08:43 +0000 (11:08 +0000)]
drm/i915/gemfs: don't mark huge_opt as static
vfs_kernel_mount() modifies the passed in mount options, leaving us with
"huge", instead of "huge=within_size". Normally this shouldn't matter
with the usual module load/unload flow, however with the core_hotunplug
IGT we are hitting the following, when re-probing the memory regions:
i915 0000:00:02.0: [drm] Transparent Hugepage mode 'huge'
tmpfs: Bad value for 'huge'
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-22).
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4651
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211126110843.2028582-1-matthew.auld@intel.com
Thomas Hellström [Mon, 8 Nov 2021 17:45:45 +0000 (18:45 +0100)]
drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code
The capture code is typically run entirely in the fence signalling
critical path. We're about to add lockdep annotation in an upcoming patch
which reveals a lockdep splat similar to the below one.
Fix the associated potential deadlocks using __GFP_KSWAPD_RECLAIM
(which is the same as GFP_WAIT, but open-coded for clarity) rather than
GFP_KERNEL for memory allocation in the capture path. This has the
potential drawback that capture might fail in situations with memory
pressure.
[ 234.842048] WARNING: possible circular locking dependency detected
[ 234.842050] 5.15.0-rc7+ #20 Tainted: G U W
[ 234.842052] ------------------------------------------------------
[ 234.842054] gem_exec_captur/1180 is trying to acquire lock:
[ 234.842056]
ffffffffa3e51c00 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc+0x4d/0x330
[ 234.842063]
but task is already holding lock:
[ 234.842064]
ffffffffa3f57620 (dma_fence_map){++++}-{0:0}, at: i915_vma_snapshot_resource_pin+0x27/0x30 [i915]
[ 234.842138]
which lock already depends on the new lock.
[ 234.842140]
the existing dependency chain (in reverse order) is:
[ 234.842142]
-> #2 (dma_fence_map){++++}-{0:0}:
[ 234.842145] __dma_fence_might_wait+0x41/0xa0
[ 234.842149] dma_resv_lockdep+0x1dc/0x28f
[ 234.842151] do_one_initcall+0x58/0x2d0
[ 234.842154] kernel_init_freeable+0x273/0x2bf
[ 234.842157] kernel_init+0x16/0x120
[ 234.842160] ret_from_fork+0x1f/0x30
[ 234.842163]
-> #1 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
[ 234.842166] fs_reclaim_acquire+0x6d/0xd0
[ 234.842168] __kmalloc_node+0x51/0x3a0
[ 234.842171] alloc_cpumask_var_node+0x1b/0x30
[ 234.842174] native_smp_prepare_cpus+0xc7/0x292
[ 234.842177] kernel_init_freeable+0x160/0x2bf
[ 234.842179] kernel_init+0x16/0x120
[ 234.842181] ret_from_fork+0x1f/0x30
[ 234.842184]
-> #0 (fs_reclaim){+.+.}-{0:0}:
[ 234.842186] __lock_acquire+0x1161/0x1dc0
[ 234.842189] lock_acquire+0xb5/0x2b0
[ 234.842192] fs_reclaim_acquire+0xa1/0xd0
[ 234.842193] __kmalloc+0x4d/0x330
[ 234.842196] i915_vma_coredump_create+0x78/0x5b0 [i915]
[ 234.842253] intel_engine_coredump_add_vma+0x36/0xe0 [i915]
[ 234.842307] __i915_gpu_coredump+0x290/0x5e0 [i915]
[ 234.842365] i915_capture_error_state+0x57/0xa0 [i915]
[ 234.842415] intel_gt_handle_error+0x348/0x3e0 [i915]
[ 234.842462] intel_gt_debugfs_reset_store+0x3c/0x90 [i915]
[ 234.842504] simple_attr_write+0xc1/0xe0
[ 234.842507] full_proxy_write+0x53/0x80
[ 234.842509] vfs_write+0xbc/0x350
[ 234.842513] ksys_write+0x58/0xd0
[ 234.842514] do_syscall_64+0x38/0x90
[ 234.842516] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 234.842519]
other info that might help us debug this:
[ 234.842521] Chain exists of:
fs_reclaim --> mmu_notifier_invalidate_range_start --> dma_fence_map
[ 234.842526] Possible unsafe locking scenario:
[ 234.842528] CPU0 CPU1
[ 234.842529] ---- ----
[ 234.842531] lock(dma_fence_map);
[ 234.842532] lock(mmu_notifier_invalidate_range_start);
[ 234.842535] lock(dma_fence_map);
[ 234.842537] lock(fs_reclaim);
[ 234.842539]
*** DEADLOCK ***
[ 234.842540] 4 locks held by gem_exec_captur/1180:
[ 234.842543] #0:
ffff9007812d9460 (sb_writers#17){.+.+}-{0:0}, at: ksys_write+0x58/0xd0
[ 234.842547] #1:
ffff900781d9ecb8 (&attr->mutex){+.+.}-{3:3}, at: simple_attr_write+0x3a/0xe0
[ 234.842552] #2:
ffffffffc11913a8 (capture_mutex){+.+.}-{3:3}, at: i915_capture_error_state+0x1a/0xa0 [i915]
[ 234.842602] #3:
ffffffffa3f57620 (dma_fence_map){++++}-{0:0}, at: i915_vma_snapshot_resource_pin+0x27/0x30 [i915]
[ 234.842656]
stack backtrace:
[ 234.842658] CPU: 0 PID: 1180 Comm: gem_exec_captur Tainted: G U W 5.15.0-rc7+ #20
[ 234.842661] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021
[ 234.842664] Call Trace:
[ 234.842666] dump_stack_lvl+0x57/0x72
[ 234.842669] check_noncircular+0xde/0x100
[ 234.842672] ? __lock_acquire+0x3bf/0x1dc0
[ 234.842675] __lock_acquire+0x1161/0x1dc0
[ 234.842678] lock_acquire+0xb5/0x2b0
[ 234.842680] ? __kmalloc+0x4d/0x330
[ 234.842683] ? finish_task_switch.isra.0+0xf2/0x360
[ 234.842686] ? i915_vma_coredump_create+0x78/0x5b0 [i915]
[ 234.842734] fs_reclaim_acquire+0xa1/0xd0
[ 234.842737] ? __kmalloc+0x4d/0x330
[ 234.842739] __kmalloc+0x4d/0x330
[ 234.842742] i915_vma_coredump_create+0x78/0x5b0 [i915]
[ 234.842793] ? capture_vma+0xbe/0x110 [i915]
[ 234.842844] intel_engine_coredump_add_vma+0x36/0xe0 [i915]
[ 234.842892] __i915_gpu_coredump+0x290/0x5e0 [i915]
[ 234.842939] i915_capture_error_state+0x57/0xa0 [i915]
[ 234.842985] intel_gt_handle_error+0x348/0x3e0 [i915]
[ 234.843032] ? __mutex_lock+0x81/0x830
[ 234.843035] ? simple_attr_write+0x3a/0xe0
[ 234.843038] ? __lock_acquire+0x3bf/0x1dc0
[ 234.843041] intel_gt_debugfs_reset_store+0x3c/0x90 [i915]
[ 234.843083] ? _copy_from_user+0x45/0x80
[ 234.843086] simple_attr_write+0xc1/0xe0
[ 234.843089] full_proxy_write+0x53/0x80
[ 234.843091] vfs_write+0xbc/0x350
[ 234.843094] ksys_write+0x58/0xd0
[ 234.843096] do_syscall_64+0x38/0x90
[ 234.843098] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 234.843101] RIP: 0033:0x7fa467480877
[ 234.843103] Code: 75 05 48 83 c4 58 c3 e8 37 4e ff ff 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[ 234.843108] RSP: 002b:
00007ffd14d79b08 EFLAGS:
00000246 ORIG_RAX:
0000000000000001
[ 234.843112] RAX:
ffffffffffffffda RBX:
00007ffd14d79b60 RCX:
00007fa467480877
[ 234.843114] RDX:
0000000000000014 RSI:
00007ffd14d79b60 RDI:
0000000000000007
[ 234.843116] RBP:
0000000000000007 R08:
0000000000000000 R09:
00007ffd14d79ab0
[ 234.843119] R10:
ffffffffffffffff R11:
0000000000000246 R12:
0000000000000014
[ 234.843121] R13:
0000000000000000 R14:
00007ffd14d79b60 R15:
0000000000000005
v5:
- Use __GFP_KSWAPD_RECLAIM rather than __GFP_NOWAIT for clarity.
(Daniel Vetter)
v6:
- Include an instance in execlists_capture_work().
- Rework the commit message due to patch reordering.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211108174547.979714-3-thomas.hellstrom@linux.intel.com
Thomas Hellström [Mon, 8 Nov 2021 17:45:44 +0000 (18:45 +0100)]
drm/i915: Avoid allocating a page array for the gpu coredump
The gpu coredump typically takes place in a dma_fence signalling
critical path, and hence can't use GFP_KERNEL allocations, as that
means we might hit deadlocks under memory pressure. However
changing to __GFP_KSWAPD_RECLAIM which will be done in an upcoming
patch will instead mean a lower chance of the allocation succeeding.
In particular large contigous allocations like the coredump page
vector.
Remove the page vector in favor of a linked list of single pages.
Use the page lru list head as the list link, as the page owner is
allowed to do that.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211108174547.979714-2-thomas.hellstrom@linux.intel.com
Maarten Lankhorst [Thu, 21 Oct 2021 10:35:40 +0000 (12:35 +0200)]
drm/i915: Remove dma_resv_prune
The signaled bit is already used for quick testing if a fence is signaled.
On top of that, it's a terrible abuse of dma-fence api, and in the common
case where the object is already locked by the caller, the trylock will fail.
If it were useful, the core dma-api would have exposed the same functionality.
The fact that i915 has a dma_resv_utils.c file should be a warning that the
functionality either belongs in core, or is not very useful at all.
In this case the latter.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[mlankhorst: Improve commit message]
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211021103605.735002-3-maarten.lankhorst@linux.intel.com
Reviewed-by: Matthew Auld <matthew.auld@intel.com> #irc
Tvrtko Ursulin [Thu, 25 Nov 2021 12:47:45 +0000 (12:47 +0000)]
Merge drm/drm-next into drm-intel-gt-next
Maarten requested a backmerge due his work depending on subtle semantic
changes introduced by:
7e2e69ed4678 ("drm/i915: Fix i915_request fence wait semantics")
2cbb8d4d6770 ("drm/i915: use new iterator in i915_gem_object_wait_reservation")
Both should probably have been merged to drm-intel-gt-next anyway.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thomas Hellström [Mon, 22 Nov 2021 21:45:54 +0000 (22:45 +0100)]
drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be asynchronous
Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for
future users and update the only current user to sync the objects
as needed after this function.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-7-thomas.hellstrom@linux.intel.com
Thomas Hellström [Mon, 22 Nov 2021 21:45:53 +0000 (22:45 +0100)]
drm/i915/ttm: Implement asynchronous TTM moves
Don't wait sync while migrating, but rather make the GPU blit await the
dependencies and add a moving fence to the object.
This also enables asynchronous VRAM management in that on eviction,
rather than waiting for the moving fence to expire before freeing VRAM,
it is freed immediately and the fence is stored with the VRAM manager and
handed out to newly allocated objects to await before clears and swapins,
or for kernel objects before setting up gpu vmas or mapping.
To collect dependencies before migrating, add a set of utilities that
coalesce these to a single dma_fence.
What is still missing for fully asynchronous operation is asynchronous vma
unbinding, which is still to be implemented.
This commit substantially reduces execution time in the gem_lmem_swapping
test.
v2:
- Make a couple of functions static.
v4:
- Fix some style issues (Matthew Auld)
- Audit and add more checks for ghost objects (Matthew Auld)
- Add more documentation for the i915_deps utility (Mattew Auld)
- Simplify the i915_deps_sync() function
v6:
- Re-check for fence signaled before returning -EBUSY (Matthew Auld)
- Use dma_resv_iter_is_exclusive() (Matthew Auld)
- Await all dma-resv fences before a migration blit (Matthew Auld)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-6-thomas.hellstrom@linux.intel.com
Thomas Hellström [Mon, 22 Nov 2021 21:45:52 +0000 (22:45 +0100)]
drm/i915/ttm: Correctly handle waiting for gpu when shrinking
With async migration, the shrinker may end up wanting to release the
pages of an object while the migration blit is still running, since
the GT migration code doesn't set up VMAs and the shrinker is thus
oblivious to the fact that the GPU is still using the pages.
Add waiting for gpu in the shrinker_release_pages() op and an
argument to that function indicating whether the shrinker expects it
to not wait for gpu. In the latter case the shrinker_release_pages()
op will return -EBUSY if the object is not idle.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-5-thomas.hellstrom@linux.intel.com
Thomas Hellström [Mon, 22 Nov 2021 21:45:51 +0000 (22:45 +0100)]
drm/i915/ttm: Drop region reference counting
There is an interesting refcounting loop:
struct intel_memory_region has a struct ttm_resource_manager,
ttm_resource_manager->move may hold a reference to i915_request,
i915_request may hold a reference to intel_context,
intel_context may hold a reference to drm_i915_gem_object,
drm_i915_gem_object may hold a reference to intel_memory_region.
Break this loop by dropping region reference counting.
In addition, Have regions with a manager moving fence make sure
that all region objects are released before freeing the region.
v6:
- Fix a code comment.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-4-thomas.hellstrom@linux.intel.com
Thomas Hellström [Mon, 22 Nov 2021 21:45:50 +0000 (22:45 +0100)]
drm/i915/ttm: Move the i915_gem_obj_copy_ttm() function
Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h.
This will help keep a number of functions static when introducing
async moves.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-3-thomas.hellstrom@linux.intel.com
Maarten Lankhorst [Mon, 22 Nov 2021 21:45:49 +0000 (22:45 +0100)]
drm/i915: Add support for moving fence waiting
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available after the moving
fence is signaled, and pinning a cpu map will only work after
the moving fence signals.
This should close all holes where userspace can read a buffer
before it's fully migrated.
v2:
- Fix a couple of SPARSE warnings
v3:
- Fix a NULL pointer dereference
v4:
- Ditch the moving fence waiting for i915_vma_pin_iomap() and
replace with a verification that the vma is already bound.
(Matthew Auld)
- Squash with a previous patch introducing moving fence waiting and
accessing interfaces (Matthew Auld)
- Rename to indicated that we also add support for sync waiting.
v5:
- Fix check for NULL and unreferencing i915_vma_verify_bind_complete()
(Matthew Auld)
- Fix compilation failure if !CONFIG_DRM_I915_DEBUG_GEM
- Fix include ordering. (Matthew Auld)
v7:
- Fix yet another compilation failure with clang if
!CONFIG_DRM_I915_DEBUG_GEM
Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122214554.371864-2-thomas.hellstrom@linux.intel.com
Tvrtko Ursulin [Mon, 22 Nov 2021 13:57:58 +0000 (13:57 +0000)]
Revert "drm/i915/dmabuf: fix broken build"
This reverts commit
777226dac058 ("drm/i915/dmabuf: fix broken build").
Approach taken in the patch was rejected by Linus and the upstream tree
now already contains the required include directive via
304ac8032d3f
("Merge tag 'drm-next-2021-11-12' of git://anongit.freedesktop.org/drm/drm").
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes:
777226dac058 ("drm/i915/dmabuf: fix broken build")
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122135758.85444-1-tvrtko.ursulin@linux.intel.com
[tursulin: fixup commit message sha format]
Tejas Upadhyay [Wed, 17 Nov 2021 06:03:21 +0000 (11:33 +0530)]
drm/i915/gt: Hold RPM wakelock during PXP suspend
selftest --r live shows failure in suspend tests when
RPM wakelock is not acquired during suspend.
This changes addresses below error :
<4> [154.177535] RPM wakelock ref not held during HW access
<4> [154.177575] WARNING: CPU: 4 PID: 5772 at
drivers/gpu/drm/i915/intel_runtime_pm.h:113
fwtable_write32+0x240/0x320 [i915]
<4> [154.177974] Modules linked in: i915(+) vgem drm_shmem_helper
fuse snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
ledtrig_audio mei_hdcp mei_pxp x86_pkg_temp_thermal coretemp
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_intel_dspcfg
snd_hda_codec snd_hwdep igc snd_hda_core ttm mei_me ptp
snd_pcm prime_numbers mei i2c_i801 pps_core i2c_smbus intel_lpss_pci
btusb btrtl btbcm btintel bluetooth ecdh_generic ecc [last unloaded: i915]
<4> [154.178143] CPU: 4 PID: 5772 Comm: i915_selftest Tainted: G
U 5.15.0-rc6-CI-Patchwork_21432+ #1
<4> [154.178154] Hardware name: ASUS System Product Name/TUF GAMING
Z590-PLUS WIFI, BIOS 0811 04/06/2021
<4> [154.178160] RIP: 0010:fwtable_write32+0x240/0x320 [i915]
<4> [154.178604] Code: 15 7b e1 0f 0b e9 34 fe ff ff 80 3d a9 89 31
00 00 0f 85 31 fe ff ff 48 c7 c7 88 9e 4f a0 c6 05 95 89 31 00 01 e8
c0 15 7b e1 <0f> 0b e9 17 fe ff ff 8b 05 0f 83 58 e2 85 c0 0f 85 8d
00 00 00 48
<4> [154.178614] RSP: 0018:
ffffc900016279f0 EFLAGS:
00010286
<4> [154.178626] RAX:
0000000000000000 RBX:
ffff888204fe0ee0
RCX:
0000000000000001
<4> [154.178634] RDX:
0000000080000001 RSI:
ffffffff823142b5
RDI:
00000000ffffffff
<4> [154.178641] RBP:
00000000000320f0 R08:
0000000000000000
R09:
c0000000ffffcd5a
<4> [154.178647] R10:
00000000000f8c90 R11:
ffffc90001627808
R12:
0000000000000000
<4> [154.178654] R13:
0000000040000000 R14:
ffffffffa04d12e0
R15:
0000000000000000
<4> [154.178660] FS:
00007f7390aa4c00(0000) GS:
ffff88844f000000(0000)
knlGS:
0000000000000000
<4> [154.178669] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4> [154.178675] CR2:
000055bc40595028 CR3:
0000000204474005
CR4:
0000000000770ee0
<4> [154.178682] PKRU:
55555554
<4> [154.178687] Call Trace:
<4> [154.178706] intel_pxp_fini_hw+0x23/0x30 [i915]
<4> [154.179284] intel_pxp_suspend+0x1f/0x30 [i915]
<4> [154.179807] live_gt_resume+0x5b/0x90 [i915]
Changes since V2 :
- Remove boolean in intel_pxp_runtime_preapre for
non-pxp configs. Solves build error
Changes since V2 :
- Open-code intel_pxp_runtime_suspend - Daniele
- Remove boolean in intel_pxp_runtime_preapre - Daniele
Changes since V1 :
- split the HW access parts in gt_suspend_late - Daniele
- Remove default PXP configs
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Fixes:
0cfab4cb3c4e ("drm/i915/pxp: Enable PXP power management")
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117060321.3729343-1-tejaskumarx.surendrakumar.upadhyay@intel.com
Umesh Nerlige Ramappa [Mon, 15 Nov 2021 22:16:40 +0000 (14:16 -0800)]
drm/i915/pmu: Increase the live_engine_busy_stats sample period
Irrespective of the backend for request submissions, busyness for an
engine with an active context is calculated using:
busyness = total + (current_time - context_switch_in_time)
In execlists mode of operation, the context switch events are handled
by the CPU. Context switch in/out time and current_time are captured
in CPU time domain using ktime_get().
In GuC mode of submission, context switch events are handled by GuC and
the times in the above formula are captured in GT clock domain. This
information is shared with the CPU through shared memory. This results
in 2 caveats:
1) The time taken between start of a batch and the time that CPU is able
to see the context_switch_in_time in shared memory is dependent on GuC
and memory bandwidth constraints.
2) Determining current_time requires an MMIO read that can take anywhere
between a few us to a couple ms. A reference CPU time is captured soon
after reading the MMIO so that the caller can compare the cpu delta
between 2 busyness samples. The issue here is that the CPU delta and the
busyness delta can be skewed because of the time taken to read the
register.
These 2 factors affect the accuracy of the selftest -
live_engine_busy_stats. For (1) the selftest waits until busyness stats
are visible to the CPU. The effects of (2) are more prominent for the
current busyness sample period of 100 us. Increase the busyness sample
period from 100 us to 10 ms to overccome (2).
v2: Fix checkpatch issues
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211115221640.30793-1-umesh.nerlige.ramappa@intel.com
Matthew Auld [Tue, 23 Nov 2021 12:58:14 +0000 (12:58 +0000)]
drm/i915/ttm: fixup build failure
drm-intel-gt-next fails to build with:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘vm_fault_ttm’:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:862:23: error: too many arguments to function ‘ttm_bo_vm_fault_reserved’
862 | ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
| ^~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211123125814.1703220-1-matthew.auld@intel.com
Randy Dunlap [Tue, 23 Nov 2021 05:09:28 +0000 (21:09 -0800)]
drm/i915/gem: placate scripts/kernel-doc
Correct kernel-doc warnings in i915_drm_object.c:
i915_gem_object.c:103: warning: expecting prototype for i915_gem_object_fini(). Prototype was for __i915_gem_object_fini() instead
i915_gem_object.c:110: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Mark up the object's coherency levels for a given cache_level
i915_gem_object.c:110: warning: missing initial short description on line:
* Mark up the object's coherency levels for a given cache_level
i915_gem_object.c:457: warning: No description found for return value of 'i915_gem_object_read_from_page'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211123050928.20434-1-rdunlap@infradead.org
Dave Airlie [Mon, 22 Nov 2021 23:38:29 +0000 (09:38 +1000)]
Merge tag 'drm-misc-next-2021-11-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.17:
UAPI Changes:
* Remove restrictions on DMA_BUF_SET_NAME ioctl
* connector: State of privacy screen
* sysfs: Send hotplug uevent
Cross-subsystem Changes:
* clk/bmc-2835: Fixes
* dma-buf: Add dma_resv selftest; Error-handling fixes; Add debugfs
helpers; Remove dma_resv_get_excl_unlocked(); Documentation fixes
* pwm: Introduce of_pwm_single_xlate()
Core Changes:
* Support for privacy screens
* Make drm_irq.c legacy
* Fix __stack_depot_* name conflict
* Documentation fixes
* Fixes and cleanups
* dp-helper: Reuse 8b/10b link-training delay helpers
* format-helper: Update interfaces
* fb-helper: Allocate shadow buffer of correct size
* gem: Link GEM SHMEM and CMA helpers into separate modules; Use
dma_resv iterator; Import DMA_BUF namespace into GEM-helper modules
* gem/shmem-helper: Interface cleanups
* scheduler: Grab fence in drm_sched_job_add_implicit_dependencies();
Lockdep fixes
* kms-helpers: Link several files from core into the KMS-helper module
Driver Changes:
* Use dma_resv_iter in several places
* Fixes and cleanups
* amdgpu: Use drm_kms_helper_connector_hotplug_event(); Get all fences
at once
* bridge: Switch to managed MIPI DSI helpers in several places; Register
and attach during probe in several places; Convert to YAML in several
places
* bridge/anx7625: Support MIPI DPI input; Support HDMI audio; Fixes
* bridge/dw-hdmi: Allow interlace on bridge
* bridge/ps8640: Enable PM; Support aux-bus
* bridge/tc358768: Enabled reference clock; Support pulse mode;
Modesetting fixes
* bridge/ti-sn65dsi86: Use regmap_bulk_write(); Implement PWM
* etnaviv: Get all fences at once
* gma500: GEM object cleanups; Remove generic drivers in probe function
* i915: Support VESA panel backlights
* ingenic: Fixes and cleanups
* kirin: Adjust probe order
* kmb: Enable framebuffer console
* lima: Kconfig fixes
* meson: Refactoring to supperot DRM_BRIDGE_ATTACH_NO_ENCODER
* msm: Fixes and cleanups
* msm/dsi: Adjust probe order
* omap: Fixes and cleanups
* nouveau: CRC fixes; Validate LUTs in atomic check; Set HDMI AVI RGB
quantization to FULL; Fixes and cleanups
* panel: Support Innolux G070Y2-T02, Vivax TPC-9150, JDI R63452,
Newhaven 1.8-
128160EF, Wanchanglong W552964ABA, Novatek NT35950,
BOE BF060Y8M, Sony Tulip Truly NT35521; Use dev_err_probe() throughout
drivers; Fixes and cleanups
* panel/ili9881c: Orientation fixes
* radeon: Use dma_resv_wait_timeout()
* rockchip: Add timeout for DSP hold; Suspend/resume fixes; PLL clock
fixes; Implement mmap in GEM object functions
* simpledrm: Support FB_DAMAGE_CLIPS and virtual screen sizes
* sun4i: Use CMA helpers without vmap support
* tidss: Fixes and cleanups
* v3d: Cleanups
* vc4: Fix HDMI-CEC hang when display is off; Power on HDMI controller
while disabling; Support 4k@60 Hz modes; Fixes and cleanups
* video: Convert to sysfs_emit() in several places
* video/omapfb: Fix fall-through
* virtio: Overflow fixes
* xen: Implement mmap as GEM object functions
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/YZYZSypIrr+qcih3@linux-uq9g.fritz.box
Dan Carpenter [Mon, 22 Nov 2021 07:41:47 +0000 (10:41 +0300)]
drm/i915/ttm: Fix error code in i915_ttm_eviction_valuable()
This function returns a bool type so returning -EBUSY is equivalent to
returning true. It should return false instead.
Fixes:
7ae034590cea ("drm/i915/ttm: add tt shmem backend")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122061438.GA2492@kili
Tvrtko Ursulin [Mon, 22 Nov 2021 12:18:15 +0000 (12:18 +0000)]
Merge drm/drm-next into drm-intel-gt-next
Thomas needs the dma_resv_for_each_fence API for i915/ttm async migration
work.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Umesh Nerlige Ramappa [Sat, 20 Nov 2021 01:42:01 +0000 (17:42 -0800)]
drm/i915/pmu: Avoid with_intel_runtime_pm within spinlock
When guc timestamp ping worker runs it takes the spinlock and calls
with_intel_runtime_pm. Since with_intel_runtime_pm may sleep, move the
spinlock inside __update_guc_busyness_stats.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211120014201.26480-1-umesh.nerlige.ramappa@intel.com
Linus Torvalds [Sun, 21 Nov 2021 21:47:39 +0000 (13:47 -0800)]
Linux 5.16-rc2
Linus Torvalds [Sun, 21 Nov 2021 19:25:19 +0000 (11:25 -0800)]
Merge tag 'x86-urgent-2021-11-21' of git://git./linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
- Move the command line preparation and the early command line parsing
earlier so that the command line parameters which affect
early_reserve_memory(), e.g. efi=nosftreserve, are taken into
account. This was broken when the invocation of
early_reserve_memory() was moved recently.
- Use an atomic type for the SGX page accounting, which is read and
written locklessly, to plug various race conditions related to it.
* tag 'x86-urgent-2021-11-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/sgx: Fix free page accounting
x86/boot: Pull up cmdline preparation and early param parsing
Linus Torvalds [Sun, 21 Nov 2021 19:17:50 +0000 (11:17 -0800)]
Merge tag 'perf-urgent-2021-11-21' of git://git./linux/kernel/git/tip/tip
Pull x86 perf fixes from Thomas Gleixner:
- Remove unneded PEBS disabling when taking LBR snapshots to prevent an
unchecked MSR access error.
- Fix IIO event constraints for Snowridge and Skylake server chips.
* tag 'perf-urgent-2021-11-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/perf: Fix snapshot_branch_stack warning in VM
perf/x86/intel/uncore: Fix IIO event constraints for Snowridge
perf/x86/intel/uncore: Fix IIO event constraints for Skylake Server
perf/x86/intel/uncore: Fix filter_tid mask for CHA events on Skylake Server
Linus Torvalds [Sun, 21 Nov 2021 18:26:35 +0000 (10:26 -0800)]
Merge tag 'powerpc-5.16-2' of git://git./linux/kernel/git/powerpc/linux
Pull more powerpc fixes from Michael Ellerman:
- Fix a bug in copying of sigset_t for 32-bit systems, which caused X
to not start.
- Fix handling of shared LSIs (rare) with the xive interrupt controller
(Power9/10).
- Fix missing TOC setup in some KVM code, which could result in oopses
depending on kernel data layout.
- Fix DMA mapping when we have persistent memory and only one DMA
window available.
- Fix further problems with STRICT_KERNEL_RWX on 8xx, exposed by a
recent fix.
- A couple of other minor fixes.
Thanks to Alexey Kardashevskiy, Aneesh Kumar K.V, Cédric Le Goater,
Christian Zigotzky, Christophe Leroy, Daniel Axtens, Finn Thain, Greg
Kurz, Masahiro Yamada, Nicholas Piggin, and Uwe Kleine-König.
* tag 'powerpc-5.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/xive: Change IRQ domain to a tree domain
powerpc/8xx: Fix pinned TLBs with CONFIG_STRICT_KERNEL_RWX
powerpc/signal32: Fix sigset_t copy
powerpc/book3e: Fix TLBCAM preset at boot
powerpc/pseries/ddw: Do not try direct mapping with persistent memory and one window
powerpc/pseries/ddw: simplify enable_ddw()
powerpc/pseries/ddw: Revert "Extend upper limit for huge DMA window for persistent memory"
powerpc/pseries: Fix numa FORM2 parsing fallback code
powerpc/pseries: rename numa_dist_table to form2_distances
powerpc: clean vdso32 and vdso64 directories
powerpc/83xx/mpc8349emitx: Drop unused variable
KVM: PPC: Book3S HV: Use GLOBAL_TOC for kvmppc_h_set_dabr/xdabr()
Geert Uytterhoeven [Thu, 18 Nov 2021 18:26:21 +0000 (10:26 -0800)]
pstore/blk: Use "%lu" to format unsigned long
On 32-bit:
fs/pstore/blk.c: In function ‘__best_effort_init’:
include/linux/kern_levels.h:5:18: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
5 | #define KERN_SOH "\001" /* ASCII Start Of Header */
| ^~~~~~
include/linux/kern_levels.h:14:19: note: in expansion of macro ‘KERN_SOH’
14 | #define KERN_INFO KERN_SOH "6" /* informational */
| ^~~~~~~~
include/linux/printk.h:373:9: note: in expansion of macro ‘KERN_INFO’
373 | printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~
fs/pstore/blk.c:314:3: note: in expansion of macro ‘pr_info’
314 | pr_info("attached %s (%zu) (no dedicated panic_write!)\n",
| ^~~~~~~
Cc: stable@vger.kernel.org
Fixes:
7bb9557b48fcabaa ("pstore/blk: Use the normal block device I/O path")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210629103700.1935012-1-geert@linux-m68k.org
Cc: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sat, 20 Nov 2021 21:17:24 +0000 (13:17 -0800)]
Merge branch 'akpm' (patches from Andrew)
Merge misc fixes from Andrew Morton:
"15 patches.
Subsystems affected by this patch series: ipc, hexagon, mm (swap,
slab-generic, kmemleak, hugetlb, kasan, damon, and highmem), and proc"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
proc/vmcore: fix clearing user buffer by properly using clear_user()
kmap_local: don't assume kmap PTEs are linear arrays in memory
mm/damon/dbgfs: fix missed use of damon_dbgfs_lock
mm/damon/dbgfs: use '__GFP_NOWARN' for user-specified size buffer allocation
kasan: test: silence intentional read overflow warnings
hugetlb, userfaultfd: fix reservation restore on userfaultfd error
hugetlb: fix hugetlb cgroup refcounting during mremap
mm: kmemleak: slob: respect SLAB_NOLEAKTRACE flag
hexagon: ignore vmlinux.lds
hexagon: clean up timer-regs.h
hexagon: export raw I/O routines for modules
mm: emit the "free" trace report before freeing memory in kmem_cache_free()
shm: extend forced shm destroy to support objects from several IPC nses
ipc: WARN if trying to remove ipc object which is absent
mm/swap.c:put_pages_list(): reinitialise the page list
Linus Torvalds [Sat, 20 Nov 2021 19:05:10 +0000 (11:05 -0800)]
Merge tag 'block-5.16-2021-11-19' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
- Flip a cap check to avoid a selinux error (Alistair)
- Fix for a regression this merge window where we can miss a queue ref
put (me)
- Un-mark pstore-blk as broken, as the condition that triggered that
change has been rectified (Kees)
- Queue quiesce and sync fixes (Ming)
- FUA insertion fix (Ming)
- blk-cgroup error path put fix (Yu)
* tag 'block-5.16-2021-11-19' of git://git.kernel.dk/linux-block:
blk-mq: don't insert FUA request with data into scheduler queue
blk-cgroup: fix missing put device in error path from blkg_conf_pref()
block: avoid to quiesce queue in elevator_init_mq
Revert "mark pstore-blk as broken"
blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()
block: fix missing queue put in error path
block: Check ADMIN before NICE for IOPRIO_CLASS_RT
Linus Torvalds [Sat, 20 Nov 2021 18:59:03 +0000 (10:59 -0800)]
Merge tag 'pinctrl-v5.16-2' of git://git./linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"There is an ACPI stubs fix which is ACKed by the ACPI maintainer for
merging through my tree.
One item stand out and that is that I delete the <linux/sdb.h> header
that is used by nothing. I deleted this subsystem (through the GPIO
tree) a while back so I feel responsible for tidying up the floor.
Other than that it is the usual mistakes, a bit noisy around build
issue and Kconfig then driver fixes.
Specifics:
- Fix some stubs causing compile issues for ACPI.
- Fix some wakeups on AMD IRQs shared between GPIO and SCI.
- Fix a build warning in the Tegra driver.
- Fix a Kconfig issue in the Qualcomm driver.
- Add a missing include the RALink driver.
- Return a valid type for the Apple pinctrl IRQs.
- Implement some Qualcomm SDM845 dual-edge errata.
- Remove the unused <linux/sdb.h> header. (The subsystem was once
deleted by the pinctrl maintainer...)
- Fix a duplicate initialized in the Tegra driver.
- Fix register offsets for UFS and SDC in the Qualcomm SM8350 driver"
* tag 'pinctrl-v5.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: qcom: sm8350: Correct UFS and SDC offsets
pinctrl: tegra194: remove duplicate initializer again
Remove unused header <linux/sdb.h>
pinctrl: qcom: sdm845: Enable dual edge errata
pinctrl: apple: Always return valid type in apple_gpio_irq_type
pinctrl: ralink: include 'ralink_regs.h' in 'pinctrl-mt7620.c'
pinctrl: qcom: fix unmet dependencies on GPIOLIB for GPIOLIB_IRQCHIP
pinctrl: tegra: Return const pointer from tegra_pinctrl_get_group()
pinctrl: amd: Fix wakeups when IRQ is shared with SCI
ACPI: Add stubs for wakeup handler functions
Linus Torvalds [Sat, 20 Nov 2021 18:55:50 +0000 (10:55 -0800)]
Merge tag 's390-5.16-3' of git://git./linux/kernel/git/s390/linux
Pull s390 updates from Heiko Carstens:
- Add missing Kconfig option for ftrace direct multi sample, so it can
be compiled again, and also add s390 support for this sample.
- Update Christian Borntraeger's email address.
- Various fixes for memory layout setup. Besides other this makes it
possible to load shared DCSS segments again.
- Fix copy to user space of swapped kdump oldmem.
- Remove -mstack-guard and -mstack-size compile options when building
vdso binaries. This can happen when CONFIG_VMAP_STACK is disabled and
results in broken vdso code which causes more or less random
exceptions. Also remove the not needed -nostdlib option.
- Fix memory leak on cpu hotplug and return code handling in kexec
code.
- Wire up futex_waitv system call.
- Replace snprintf with sysfs_emit where appropriate.
* tag 's390-5.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
ftrace/samples: add s390 support for ftrace direct multi sample
ftrace/samples: add missing Kconfig option for ftrace direct multi sample
MAINTAINERS: update email address of Christian Borntraeger
s390/kexec: fix memory leak of ipl report buffer
s390/kexec: fix return code handling
s390/dump: fix copying to user-space of swapped kdump oldmem
s390: wire up sys_futex_waitv system call
s390/vdso: filter out -mstack-guard and -mstack-size
s390/vdso: remove -nostdlib compiler flag
s390: replace snprintf in show functions with sysfs_emit
s390/boot: simplify and fix kernel memory layout setup
s390/setup: re-arrange memblock setup
s390/setup: avoid using memblock_enforce_memory_limit
s390/setup: avoid reserving memory above identity mapping
Linus Torvalds [Sat, 20 Nov 2021 18:47:16 +0000 (10:47 -0800)]
Merge tag '5.16-rc1-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs fixes from Steve French:
"Three small cifs/smb3 fixes: two to address minor coverity issues and
one cleanup"
* tag '5.16-rc1-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
cifs: introduce cifs_ses_mark_for_reconnect() helper
cifs: protect srv_count with cifs_tcp_ses_lock
cifs: move debug print out of spinlock
David Hildenbrand [Sat, 20 Nov 2021 00:43:58 +0000 (16:43 -0800)]
proc/vmcore: fix clearing user buffer by properly using clear_user()
To clear a user buffer we cannot simply use memset, we have to use
clear_user(). With a virtio-mem device that registers a vmcore_cb and
has some logically unplugged memory inside an added Linux memory block,
I can easily trigger a BUG by copying the vmcore via "cp":
systemd[1]: Starting Kdump Vmcore Save Service...
kdump[420]: Kdump is using the default log level(3).
kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/
kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/
kdump[465]: saving vmcore-dmesg.txt complete
kdump[467]: saving vmcore
BUG: unable to handle page fault for address:
00007f2374e01000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0003) - permissions violation
PGD
7a523067 P4D
7a523067 PUD
7a528067 PMD
7a525067 PTE
800000007048f867
Oops: 0003 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86
Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81
RSP: 0018:
ffffc9000073be08 EFLAGS:
00010212
RAX:
0000000000001000 RBX:
00000000002fd000 RCX:
00007f2374e01000
RDX:
0000000000000001 RSI:
00000000ffffdfff RDI:
00007f2374e01008
RBP:
0000000000001000 R08:
0000000000000000 R09:
ffffc9000073bc50
R10:
ffffc9000073bc48 R11:
ffffffff829461a8 R12:
000000000000f000
R13:
00007f2374e01000 R14:
0000000000000000 R15:
ffff88807bd421e8
FS:
00007f2374e12140(0000) GS:
ffff88807f000000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f2374e01000 CR3:
000000007a4aa000 CR4:
0000000000350eb0
Call Trace:
read_vmcore+0x236/0x2c0
proc_reg_read+0x55/0xa0
vfs_read+0x95/0x190
ksys_read+0x4f/0xc0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access
Prevention (SMAP)", which is used to detect wrong access from the kernel
to user buffers like this: SMAP triggers a permissions violation on
wrong access. In the x86-64 variant of clear_user(), SMAP is properly
handled via clac()+stac().
To fix, properly use clear_user() when we're dealing with a user buffer.
Link: https://lkml.kernel.org/r/20211112092750.6921-1-david@redhat.com
Fixes:
997c136f518c ("fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages")
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Philipp Rudo <prudo@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ard Biesheuvel [Sat, 20 Nov 2021 00:43:55 +0000 (16:43 -0800)]
kmap_local: don't assume kmap PTEs are linear arrays in memory
The kmap_local conversion broke the ARM architecture, because the new
code assumes that all PTEs used for creating kmaps form a linear array
in memory, and uses array indexing to look up the kmap PTE belonging to
a certain kmap index.
On ARM, this cannot work, not only because the PTE pages may be
non-adjacent in memory, but also because ARM/!LPAE interleaves hardware
entries and extended entries (carrying software-only bits) in a way that
is not compatible with array indexing.
Fortunately, this only seems to affect configurations with more than 8
CPUs, due to the way the per-CPU kmap slots are organized in memory.
Work around this by permitting an architecture to set a Kconfig symbol
that signifies that the kmap PTEs do not form a lineary array in memory,
and so the only way to locate the appropriate one is to walk the page
tables.
Link: https://lore.kernel.org/linux-arm-kernel/20211026131249.3731275-1-ardb@kernel.org/
Link: https://lkml.kernel.org/r/20211116094737.7391-1-ardb@kernel.org
Fixes:
2a15ba82fa6c ("ARM: highmem: Switch to generic kmap atomic")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reported-by: Quanyang Wang <quanyang.wang@windriver.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
SeongJae Park [Sat, 20 Nov 2021 00:43:52 +0000 (16:43 -0800)]
mm/damon/dbgfs: fix missed use of damon_dbgfs_lock
DAMON debugfs is supposed to protect dbgfs_ctxs, dbgfs_nr_ctxs, and
dbgfs_dirs using damon_dbgfs_lock. However, some of the code is
accessing the variables without the protection. This fixes it by
protecting all such accesses.
Link: https://lkml.kernel.org/r/20211110145758.16558-3-sj@kernel.org
Fixes:
75c1c2b53c78 ("mm/damon/dbgfs: support multiple contexts")
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
SeongJae Park [Sat, 20 Nov 2021 00:43:49 +0000 (16:43 -0800)]
mm/damon/dbgfs: use '__GFP_NOWARN' for user-specified size buffer allocation
Patch series "DAMON fixes".
This patch (of 2):
DAMON users can trigger below warning in '__alloc_pages()' by invoking
write() to some DAMON debugfs files with arbitrarily high count
argument, because DAMON debugfs interface allocates some buffers based
on the user-specified 'count'.
if (unlikely(order >= MAX_ORDER)) {
WARN_ON_ONCE(!(gfp & __GFP_NOWARN));
return NULL;
}
Because the DAMON debugfs interface code checks failure of the
'kmalloc()', this commit simply suppresses the warnings by adding
'__GFP_NOWARN' flag.
Link: https://lkml.kernel.org/r/20211110145758.16558-1-sj@kernel.org
Link: https://lkml.kernel.org/r/20211110145758.16558-2-sj@kernel.org
Fixes:
4bc05954d007 ("mm/damon: implement a debugfs-based user space interface")
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / platform / kernel / linux-rpi.git / log