[PATCH 08/10] accel/ivpu: Disable buffer sharing among VPU contexts

Jacek Lawrynowicz jacek.lawrynowicz at linux.intel.com
Wed Jan 10 10:53:32 UTC 2024


On 05.01.2024 17:46, Jeffrey Hugo wrote:
> On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
>> This was not supported properly. A buffer was imported to another VPU
>> context as a separate buffer object with duplicated sgt.
>> Both exported and imported buffers could be DMA mapped causing a double
>> mapping on the same device.
>>
>> Imported buffer from another VPU context will now have just reference
>> increased and there will be a single sgt fixing above problem but
>> buffers still can't be shared among VPU contexts because each context
>> have its own MMU mapping and ivpu_bo supports only single MMU mapping.
>>
>> The solution would be to use a mapping list as in panfrost or etnaviv
>> drivers and it will be implemented in future if required.
>>
>> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz at linux.intel.com>
>> ---
>>   drivers/accel/ivpu/ivpu_gem.c | 44 +++++------------------------------
>>   1 file changed, 6 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/accel/ivpu/ivpu_gem.c b/drivers/accel/ivpu/ivpu_gem.c
>> index 4de454bfbf91..8cb4d337552e 100644
>> --- a/drivers/accel/ivpu/ivpu_gem.c
>> +++ b/drivers/accel/ivpu/ivpu_gem.c
>> @@ -222,6 +222,12 @@ static int ivpu_bo_open(struct drm_gem_object *obj, struct drm_file *file)
>>       struct ivpu_bo *bo = to_ivpu_bo(obj);
>>       struct ivpu_addr_range *range;
>>   +    if (bo->ctx) {
>> +        ivpu_warn(vdev, "Can't add BO (vpu_addr 0x%llx) to ctx %u: already in ctx %u\n",
>> +              bo->vpu_addr, file_priv->ctx.id, bo->ctx->id);
> 
> Looks like the vpu_addr is being used as a unique identifier for the BO.  Is that really the best value to use?  Seems like if I want to attack another context, knowing the device address of something that context owns would be useful information.

OK, I'll remove vpu_addr form the message.


More information about the dri-devel mailing list