From: "Adrián Larumbe" <adrian.larumbe@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: "Adrián Larumbe" <adrian.larumbe@collabora.com>,
"Steven Price" <steven.price@arm.com>,
"Liviu Dudau" <liviu.dudau@arm.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] drm/panthor: Add vm_bind region with kbo range intersection check
Date: Fri, 19 Jun 2026 03:16:37 +0100 [thread overview]
Message-ID: <178183539797.1716788.5917731920154470392.b4-reply@b4> (raw)
In-Reply-To: <20260617205003.07e4275e@fedora-2.home>
On 2026-06-17 20:50:03+02:00, Boris Brezillon wrote:
> On Tue, 16 Jun 2026 15:46:43 +0100
> Adrián Larumbe <adrian.larumbe@collabora.com> wrote:
>
> > When a VM is created, caller has to specify the range of the address space
> > carve-out set aside for mapping kernel BO's. That means vm_bind mappings of
> > UM-exposed BO's should not intersect with that region, but at the moment
> > we're not checking this.
> >
> > At first, I thought of giving these values to drm_gpuvm_init() through its
> > reserve_{offset, range} arguments, but it turns out that is meant for VM
> > address spans that are not managed through the usual drm_gpuvm split/merge
> > circuit, so I had no choice but to sort of duplicate that functionality in
> > Panthor. That means we also need to keep that interval recorded in the VM.
> >
> > Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
> > ---
> > drivers/gpu/drm/panthor/panthor_mmu.c | 33 +++++++++++++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> > index 31cc57029c12..5625f3d34031 100644
> > --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> > +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> > @@ -301,6 +301,15 @@ struct panthor_vm {
> > /** @mm_lock: Lock protecting the @mm field. */
> > struct mutex mm_lock;
> >
> > + /** @kernel_va: VA-range reserved for kernel BOs. */
> > + struct {
> > + /** @kernel_va.start: Start of the VA-range for kernel BOs. */
> > + u64 start;
> > +
> > + /** @kernel_va.range: Size of the automatic VA-range for kernel BOs. */
> > + u64 range;
> > + } kernel_va;
>
> We can do with a single user_va_end.
>
> > +
> > /** @kernel_auto_va: Automatic VA-range for kernel BOs. */
> > struct {
> > /** @kernel_auto_va.start: Start of the automatic VA-range for kernel BOs. */
> > @@ -1309,6 +1318,24 @@ static int panthor_vm_op_ctx_prealloc_pts(struct panthor_vm_op_ctx *op_ctx)
> > return 0;
> > }
> >
> > +static bool
> > +panthor_vm_is_kernel_address(struct panthor_vm *vm,
> > + const struct drm_panthor_vm_bind_op *op)
>
> Rather than checking if the VA is not in the kernel range, I'd check
> that the VA is in the user range, since that's what we want to enforce,
> and if we ever decide to carve out extra sections above the user-range
> that the UMD is not supposed to access, we would still catch invalid
> map/unmap ops.
>
> > +{
> > + u32 op_type = op->flags & DRM_PANTHOR_VM_BIND_OP_TYPE_MASK;
> > + u64 end, kstart, krange, kend;
> > +
> > + if (op_type == DRM_PANTHOR_VM_BIND_OP_TYPE_SYNC_ONLY)
> > + return false;
>
> IIRC, we force op->va and op->size to be zero in that case[1], so no
> need for this extra check IMHO.
>
> > +
> > + end = op->va + op->size;
> > + kstart = vm->kernel_va.start;
> > + krange = vm->kernel_va.range;
> > + kend = kstart + krange;
> > +
> > + return krange && op->va < kend && kstart < end;
>
> A single
>
> op->va + op->size <= vm->user_va_end;
>
> would do, at which point I'm not too sure adding a helper makes sense.
I'll do this for v2.
> > +}
> > +
> > #define PANTHOR_VM_BIND_OP_MAP_FLAGS \
> > (DRM_PANTHOR_VM_BIND_OP_MAP_READONLY | \
> > DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC | \
> > @@ -2891,6 +2918,8 @@ panthor_vm_create(struct panthor_device *ptdev, bool for_mcu,
> > } else {
> > min_va = 0;
> > va_range = full_va_range;
> > + vm->kernel_va.start = kernel_va_start;
> > + vm->kernel_va.range = kernel_va_size;
> > }
> >
> > mutex_init(&vm->mm_lock);
> > @@ -2981,6 +3010,10 @@ panthor_vm_bind_prepare_op_ctx(struct drm_file *file,
> > if (!IS_ALIGNED(op->va | op->size | op->bo_offset, vm_pgsz))
> > return -EINVAL;
> >
> > + /* We don't allow mappings that intersect with kbo's reserved range */
> > + if (panthor_vm_is_kernel_address(vm, op))
> > + return -EINVAL;
> > +
> > switch (op->flags & DRM_PANTHOR_VM_BIND_OP_TYPE_MASK) {
> > case DRM_PANTHOR_VM_BIND_OP_TYPE_MAP:
> > if (!(op->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE)) {
>
> [1]https://elixir.bootlin.com/linux/v7.0.11/source/include/uapi/drm/panthor_drm.h#L588
next prev parent reply other threads:[~2026-06-19 2:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 14:46 [PATCH 0/2] Add vm_bind param check to ensure no overlap with kbo AS carveout Adrián Larumbe
2026-06-16 14:46 ` [PATCH 1/2] drm/panthor: Add vm_bind region with kbo range intersection check Adrián Larumbe
2026-06-17 18:50 ` Boris Brezillon
2026-06-19 2:16 ` Adrián Larumbe [this message]
2026-06-16 14:46 ` [PATCH 2/2] drm/panthor: Fix comment to reflect actual struct field name Adrián Larumbe
2026-06-17 18:50 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178183539797.1716788.5917731920154470392.b4-reply@b4 \
--to=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®