[PATCH] drm/i915/gvt: free workload in vgpu release
Hang Yuan
hang.yuan at linux.intel.com
Thu Aug 2 09:56:17 UTC 2018
On 08/02/2018 09:37 AM, Zhang, Xiong Y wrote:
>> From: Hang Yuan <hang.yuan at linux.intel.com>
>>
>> Some workloads may be prepared in vgpu's queue but not be scheduled to
>> run yet. If vgpu is released at this time, they will not be freed in workload
>> complete callback and so need to be freed in vgpu release operation.
>>
>> Signed-off-by: Hang Yuan <hang.yuan at linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/gvt/scheduler.c | 7 ++++---
>> drivers/gpu/drm/i915/gvt/scheduler.h | 3 +++
>> drivers/gpu/drm/i915/gvt/vgpu.c | 1 +
>> 3 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
>> b/drivers/gpu/drm/i915/gvt/scheduler.c
>> index 1ead1cc..9e845f1 100644
>> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
>> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
>> @@ -784,7 +784,8 @@ static void update_guest_context(struct
>> intel_vgpu_workload *workload)
>> kunmap(page);
>> }
>>
>> -static void clean_workloads(struct intel_vgpu *vgpu, unsigned long
>> engine_mask)
>> +void intel_vgpu_clean_workloads(struct intel_vgpu *vgpu,
>> + unsigned long engine_mask)
>> {
>> struct intel_vgpu_submission *s = &vgpu->submission;
>> struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv; @@ -879,7
>> +880,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int
>> ring_id)
>> * cleaned up during the resetting process later, so doing
>> * the workload clean up here doesn't have any impact.
>> **/
>> - clean_workloads(vgpu, ENGINE_MASK(ring_id));
>> + intel_vgpu_clean_workloads(vgpu, ENGINE_MASK(ring_id));
>> }
>>
>> workload->complete(workload);
>> @@ -1081,7 +1082,7 @@ void intel_vgpu_reset_submission(struct
>> intel_vgpu *vgpu,
>> if (!s->active)
>> return;
>>
>> - clean_workloads(vgpu, engine_mask);
>> + intel_vgpu_clean_workloads(vgpu, engine_mask);
>> s->ops->reset(vgpu, engine_mask);
>> }
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.h
>> b/drivers/gpu/drm/i915/gvt/scheduler.h
>> index 21eddab..ca5529d 100644
>> --- a/drivers/gpu/drm/i915/gvt/scheduler.h
>> +++ b/drivers/gpu/drm/i915/gvt/scheduler.h
>> @@ -158,4 +158,7 @@ intel_vgpu_create_workload(struct intel_vgpu *vgpu,
>> int ring_id,
>>
>> void intel_vgpu_destroy_workload(struct intel_vgpu_workload *workload);
>>
>> +void intel_vgpu_clean_workloads(struct intel_vgpu *vgpu,
>> + unsigned long engine_mask);
>> +
>> #endif
>> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c
>> b/drivers/gpu/drm/i915/gvt/vgpu.c index 0bc1f1e..8256e54 100644
>> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
>> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
>> @@ -238,6 +238,7 @@ void intel_gvt_deactivate_vgpu(struct intel_vgpu
>> *vgpu)
>> }
>>
>> intel_vgpu_stop_schedule(vgpu);
>> + intel_vgpu_clean_workloads(vgpu, ALL_ENGINES);
>> intel_vgpu_dmabuf_cleanup(vgpu);
> [Zhang, Xiong Y] deactivate_vgpu just stop vgpu, we couldn't clean resource here. This will break live migration as it stop vgpu first then migrate vgpu state.
> But clean_workloads is only used in reset_vgpu(). vgpu_release() and vgpu_destroy() don't do this. We should add it through another way.
So sounds new gvt ops is needed to support vgpu_release which will stop
vgpu and release vgpu's resource. And keep deactivate_vgpu ops to only
stop vgpu for live migration needs. How about this solution? - Henry
>>
>> mutex_unlock(&vgpu->vgpu_lock);
>> --
>> 2.7.4
>>
More information about the intel-gvt-dev
mailing list