[Intel-gfx] [PATCH v7 11/11] drm/i915: Introduce GVT context creation API

[Chris Wilson]

On Tue, Jun 07, 2016 at 11:18:47AM -0400, Zhi Wang wrote:
> GVT workload scheduler needs special host LRC contexts, the so called
> "shadow LRC context" to submit guest workload to host i915. During the
> guest workload submission, workload scheduler fills the shadow LRC
> context with the content of guest LRC context: engine context is copied
> without changes, ring context is mostly owned by host i915.
> 
> v7:
> 
> - Move chart to a better place. (Joonas)
> 
> v6:
> 
> - Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)
> 
> v5:
> - Only compile this feature when CONFIG_DRM_I915_GVT is enabled. (Tvrtko)
> - Rebase the code into new repo.
> - Add a comment about the ring buffer size. (Joonas)
> 
> v2:
> 
> Mostly based on Daniel's idea. Call the refactored core logic of GEM
> context creation service and LRC context creation service to create the GVT
> context.
> 
> Signed-off-by: Zhi Wang <zhi.a.wang at intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem_context.c | 65 +++++++++++++++++++++++++++++++++
>  1 file changed, 65 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
> index b0e82a1..2d8e22a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -343,6 +343,71 @@ i915_gem_create_context(struct drm_device *dev,
>  	return ctx;
>  }
>  
> +/**
> + * i915_gem_create_gvt_context - create a GVT GEM context
> + * @dev: drm device *
> + *
> + * This function is used to create a GVT specific GEM context.
> + *
> + * Returns:
> + * pointer to i915_gem_context on success, error pointer if failed
> + *
> + */
> +/* GVT context usage flow:
> + *
> + *          +-----------+                   +-----------+
> + *          |   vGPU    |                   |   vGPU    |
> + *          +-+-----^---+                   +-+-----^---+
> + *            |     |                         |     |
> + *            |     | GVT-g                   |     | GVT-g
> + * vELSP write|     | emulates     vELSP write|     | emulates
> + *            |     | Execlist/CSB            |     | Execlist/CSB
> + *            |     | Status                  |     | Status
> + *            |     |                         |     |
> + *     +------v-----+-------------------------v-----+---------+
> + *     |           GVT Virtual Execlist Submission            |
> + *     +------+-------------------------------+---------------+
> + *            |                               |
> + *            | Per-VM/Ring Workoad Q         | Per-VM/Ring Workload Q
> + *     +---------------------+--+      +------------------------+
> + *        +---v--------+    ^             +---v--------+
> + *        |GVT Workload|... |             |GVT Workload|...
> + *        +------------+    |             +------------+
> + *                          |
> + *                          | Pick Workload from Q
> + *     +--------------------+---------------------------------+
> + *     |                GVT Workload Scheduler                |
> + *     +--------------------+---------------------------------+
> + *                          |         * Shadow guest LRC context
> + *                   +------v------+  * Shadow guest ring buffer
> + *                   | GVT Context |  * Scan/Patch guest RB instructions
> + *                   +------+------+
> + *                          |
> + *                          v
> + *              Host i915 GEM Submission
> + */

I presume you move this later.

> +struct i915_gem_context *
> +i915_gem_create_gvt_context(struct drm_device *dev)

i915_gem_context_create_gvt

No function declaration in the header, build incomplete. It is worth
making sure that every patch in the series builds and doesn't introduce
new (sparse) warnings.

> +{
> +	struct i915_gem_context *ctx;
> +
> +	if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
> +		return ERR_PTR(-ENODEV);
> +
> +	mutex_lock(&dev->struct_mutex);

User facing? If so, this is the wrong type of mutex_lock.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre