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@xxxxxxxxx>
> ---
> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
