On 4/16/19 8:04 AM, Chris Wilson wrote:
> Quoting Fernando Pacheco (2019-04-16 15:51:15)
>> 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.
> Oh I see a stray comment above the function, and not about why you
> allocate a second pinned vma. Comments are for describing why you do
Sorry, I thought I was providing an explanation. I'll revise!
> things in the code; function doc are for telling users how to use the
> iface.
Very true. Thanks for pointing this out.
Fernando
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
