On 4/9/19 3:22 PM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-09 22:31:01)
>> diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
>> index 94c04f16a2ad..89e0b942ae86 100644
>> --- a/drivers/gpu/drm/i915/intel_huc.c
>> +++ b/drivers/gpu/drm/i915/intel_huc.c
>> @@ -40,6 +40,59 @@ int intel_huc_init_misc(struct intel_huc *huc)
>> return 0;
>> }
>>
>> +/*
>> + * The HuC firmware image now sits above GUC_GGTT_TOP and this
>> + * portion does not map through GTT. This means GuC cannot
>> + * perform the HuC auth with the rsa signature sitting in that
>> + * range. We resort to additionally perma-pinning the rsa signature
>> + * below GUC_GGTT_TOP and utilizing this mapping to perform
>> + * the authentication.
>> + */
>> +static int intel_huc_rsa_data_create(struct intel_huc *huc)
>> +{
>> + struct drm_i915_private *i915 = huc_to_i915(huc);
>> + struct intel_guc *guc = &i915->guc;
>> + struct i915_vma *vma;
>> + void *vaddr;
>> +
>> + vma = intel_guc_allocate_vma(guc, PAGE_SIZE);
>> + if (IS_ERR(vma))
>> + return PTR_ERR(vma);
>> +
> Are we not allocating an object for the dma xfer here that is then bound
> to the reserved ggtt node? Why pin it again into the ggtt?
> -Chris
It is not bound to the reserved node. The reserved range is inaccessible by GuC, so I
had to pull the signature back in for the auth stage.
Fernando
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
