| Age | Commit message (Collapse) | Author |
|---|
|
Promote intel_os.c helpers to igt_os.c, so that I can re-use them for
some additional msm tests. Just big churny rename, no functional change.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
This test will try to detect a missing bounds check in the kernels
vm_access(), which can potentially lead to an out-of-bounds access in
the adjacent memory area.
Changes Since V1:
- Incorporated minor changes as suggested in feedback [Chris/Matthew].
- Fixed build failures.
Signed-off-by: Mastan Katragadda <mastanx.katragadda@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
|
|
When relocations are not available tests must assign addresses to objects
by themselves instead of relying on the driver. We use allocator for
that purpose.
Signed-off-by: Ch Sai Gowtham <sai.gowtham.ch@intel.com>
Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
Add a wrapper for gem_create_ext ioctl (a version of gem_create that
accepts extensions). In preparation for the driver change implementing it,
a local definition of its id and necessary structs have been added,
which are to be erased as soon as those definitions
appear in the i915_drm.h file.
The new ioctl wrapper is added to a separate file.
For consistency the wrapper of the old ioctl, gem_create
is moved from ioctl_wrappers to gem_create.
Signed-off-by: Andrzej Turko <andrzej.turko@linux.intel.com>
Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Chris P Wilson <chris.p.wilson@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
Generally when playing with intel_buf we should use wrapper code
instead of adding it to intel_bb directly. Code checks required
alignment on specific gens so protects us from passing unaligned
properly addresses.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
Refactor the intel-bb interface to introduce the IGT allocator for
specifying the position of objects within the ppGTT.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
Fix nasty bug which leads to SIGSEGV in blt-coherency test.
Instead of pointer unmap was done on intel_buf what was wrong.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
With upcoming of allocator code we need to ensure batch will execute
with appropriate context. If mismatch between allocator data and batch
could lead to strange or wrong results. All functions which could change
context in execbuf called from intel_bb were removed.
As an allocator requires size (which was not previously required in
intel_bb) adding object to intel_bb is now mandatory.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Likely on !llc we have problem with too late flush. Verify we have
buffer coherent before execbuf.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
igt_require_gem() is a pecularity of i915/, move it out of the core.
Similar opportunistic move of gem_reopen_driver() and
gem_quiescent_gpu().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
gdb uses ptrace() to peek and poke bytes of the target's address space.
The kernel must implement an vm_ops->access() handler or else gdb will
be unable to inspect the pointer and report it as out-of-bounds. Worse
than useless as it causes immediate suspicion of the valid GPU pointer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be still repeated for each known mmap-offset
mapping type while effectively exercising GTT mapping type only. As
that may be confusing, fix it.
It has been assumed that the modified macro is still suitable for use
inside gem_mmap_offset test itself. Would that not be case,
gem_mmap_offset could redefine the macro back to its initial form for
internal use.
v2: Move extra condition to a separate function and call it via
for_each_if(), in case we need to fix it again in future (Chris)
v3: Fix blind copy-paste
Suggested-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Pull the increasingly replicated for loop over the possible mmap offset
types into a library helper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Dixit Ashutosh <ashutosh.dixit@intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
It is legal for mmap_offset_ioctl to return the same offset for
different clients, so long as that offset is only valid for use with the
client's fd and no one elses.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
|
Just keep on generating a new mmap_offset for the same old buffer, but
for different handles and so exercise the scaling of the obj->mmo lists.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
|
The offsets were meant to be created with the local fd, not i915!
Reported-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Few simple tests which tries to create / mmap buffer objects
using GEM_MMAP_OFFSET uAPI.
v2: change from WC -> WB (according to Chris review comment)
v3: add mmap-offset-close-race test
Signed-off-by: Lukasz Kalamarz <lukasz.kalamarz@intel.com>
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Vanshidhar Konda <vanshidhar.r.konda@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
