[Intel-gfx] [PATCH 3/4] drm/i915/uc: Place uC firmware in upper range of GGTT

Fernando Pacheco fernando.pacheco at intel.com
Tue Apr 16 14:51:15 UTC 2019


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



More information about the Intel-gfx mailing list