Thread (48 messages) 48 messages, 8 authors, 2025-03-12

Re: [RFC PATCH 0/5] drm/panthor: Protected mode support for Mali CSF GPUs

From: Maxime Ripard <mripard@kernel.org>
Date: 2025-01-30 16:38:32
Also in: dmaengine, dri-devel, linux-arm-kernel, linux-devicetree, linux-media, lkml

Hi Nicolas,

On Thu, Jan 30, 2025 at 10:59:56AM -0500, Nicolas Dufresne wrote:
Le jeudi 30 janvier 2025 à 14:46 +0100, Maxime Ripard a écrit :
quoted
Hi,

I started to review it, but it's probably best to discuss it here.

On Thu, Jan 30, 2025 at 01:08:56PM +0000, Florent Tomasin wrote:
quoted
Hi,

This is a patch series covering the support for protected mode execution in
Mali Panthor CSF kernel driver.

The Mali CSF GPUs come with the support for protected mode execution at the
HW level. This feature requires two main changes in the kernel driver:

1) Configure the GPU with a protected buffer. The system must provide a DMA
   heap from which the driver can allocate a protected buffer.
   It can be a carved-out memory or dynamically allocated protected memory region.
   Some system includes a trusted FW which is in charge of the protected memory.
   Since this problem is integration specific, the Mali Panthor CSF kernel
   driver must import the protected memory from a device specific exporter.
Why do you need a heap for it in the first place? My understanding of
your series is that you have a carved out memory region somewhere, and
you want to allocate from that carved out memory region your buffers.

How is that any different from using a reserved-memory region, adding
the reserved-memory property to the GPU device and doing all your
allocation through the usual dma_alloc_* API?
How do you then multiplex this region so it can be shared between
GPU/Camera/Display/Codec drivers and also userspace ?
You could point all the devices to the same reserved memory region, and
they would all allocate from there, including for their userspace-facing
allocations.
Also, how the secure memory is allocted / obtained is a process that
can vary a lot between SoC, so implementation details assumption
should not be coded in the driver.
But yeah, we agree there, it's also the point I was trying to make :)

Maxime

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help