drm/i915/i915_file_private.h

0001 /* SPDX-License-Identifier: MIT */
0002 /*
0003  * Copyright © 2021 Intel Corporation
0004  */
0005
0006 #ifndef __I915_FILE_PRIVATE_H__
0007 #define __I915_FILE_PRIVATE_H__
0008
0009 #include <linux/mutex.h>
0010 #include <linux/types.h>
0011 #include <linux/xarray.h>
0012
0013 struct drm_i915_private;
0014 struct drm_file;
0015 struct i915_drm_client;
0016
0017 struct drm_i915_file_private {
0018     struct drm_i915_private *dev_priv;
0019
0020     union {
0021         struct drm_file *file;
0022         struct rcu_head rcu;
0023     };
0024
0025     /** @proto_context_lock: Guards all struct i915_gem_proto_context
0026      * operations
0027      *
0028      * This not only guards @proto_context_xa, but is always held
0029      * whenever we manipulate any struct i915_gem_proto_context,
0030      * including finalizing it on first actual use of the GEM context.
0031      *
0032      * See i915_gem_proto_context.
0033      */
0034     struct mutex proto_context_lock;
0035
0036     /** @proto_context_xa: xarray of struct i915_gem_proto_context
0037      *
0038      * Historically, the context uAPI allowed for two methods of
0039      * setting context parameters: SET_CONTEXT_PARAM and
0040      * CONTEXT_CREATE_EXT_SETPARAM.  The former is allowed to be called
0041      * at any time while the later happens as part of
0042      * GEM_CONTEXT_CREATE.  Everything settable via one was settable
0043      * via the other.  While some params are fairly simple and setting
0044      * them on a live context is harmless such as the context priority,
0045      * others are far trickier such as the VM or the set of engines.
0046      * In order to swap out the VM, for instance, we have to delay
0047      * until all current in-flight work is complete, swap in the new
0048      * VM, and then continue.  This leads to a plethora of potential
0049      * race conditions we'd really rather avoid.
0050      *
0051      * We have since disallowed setting these more complex parameters
0052      * on active contexts.  This works by delaying the creation of the
0053      * actual context until after the client is done configuring it
0054      * with SET_CONTEXT_PARAM.  From the perspective of the client, it
0055      * has the same u32 context ID the whole time.  From the
0056      * perspective of i915, however, it's a struct i915_gem_proto_context
0057      * right up until the point where we attempt to do something which
0058      * the proto-context can't handle.  Then the struct i915_gem_context
0059      * gets created.
0060      *
0061      * This is accomplished via a little xarray dance.  When
0062      * GEM_CONTEXT_CREATE is called, we create a struct
0063      * i915_gem_proto_context, reserve a slot in @context_xa but leave
0064      * it NULL, and place the proto-context in the corresponding slot
0065      * in @proto_context_xa.  Then, in i915_gem_context_lookup(), we
0066      * first check @context_xa.  If it's there, we return the struct
0067      * i915_gem_context and we're done.  If it's not, we look in
0068      * @proto_context_xa and, if we find it there, we create the actual
0069      * context and kill the proto-context.
0070      *
0071      * In order for this dance to work properly, everything which ever
0072      * touches a struct i915_gem_proto_context is guarded by
0073      * @proto_context_lock, including context creation.  Yes, this
0074      * means context creation now takes a giant global lock but it
0075      * can't really be helped and that should never be on any driver's
0076      * fast-path anyway.
0077      */
0078     struct xarray proto_context_xa;
0079
0080     /** @context_xa: xarray of fully created i915_gem_context
0081      *
0082      * Write access to this xarray is guarded by @proto_context_lock.
0083      * Otherwise, writers may race with finalize_create_context_locked().
0084      *
0085      * See @proto_context_xa.
0086      */
0087     struct xarray context_xa;
0088     struct xarray vm_xa;
0089
0090     unsigned int bsd_engine;
0091
0092 /*
0093  * Every context ban increments per client ban score. Also
0094  * hangs in short succession increments ban score. If ban threshold
0095  * is reached, client is considered banned and submitting more work
0096  * will fail. This is a stop gap measure to limit the badly behaving
0097  * clients access to gpu. Note that unbannable contexts never increment
0098  * the client ban score.
0099  */
0100 #define I915_CLIENT_SCORE_HANG_FAST 1
0101 #define   I915_CLIENT_FAST_HANG_JIFFIES (60 * HZ)
0102 #define I915_CLIENT_SCORE_CONTEXT_BAN   3
0103 #define I915_CLIENT_SCORE_BANNED    9
0104     /** ban_score: Accumulated score of all ctx bans and fast hangs. */
0105     atomic_t ban_score;
0106     unsigned long hang_timestamp;
0107
0108     struct i915_drm_client *client;
0109 };
0110
0111 #endif /* __I915_FILE_PRIVATE_H__ */