Re: [PATCH] drm/msm: Limit command submission when no IOMMU

From: Lucas Stach <l.stach@pengutronix.de>
To: Rob Clark <robdclark@gmail.com>, dri-devel@lists.freedesktop.org
Cc: Rob Clark <robdclark@chromium.org>,
	David Airlie <airlied@linux.ie>,
	linux-arm-msm@vger.kernel.org,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	open list <linux-kernel@vger.kernel.org>,
	Luca Weiss <luca@z3ntu.xyz>, Sean Paul <sean@poorly.run>,
	freedreno@lists.freedesktop.org
Subject: Re: [PATCH] drm/msm: Limit command submission when no IOMMU
Date: Tue, 03 May 2022 14:12:15 +0200	[thread overview]
Message-ID: <86160889d7be260c5012044643b81d10098943fe.camel@pengutronix.de> (raw)
In-Reply-To: <20220502172908.3569799-1-robdclark@gmail.com>

Am Montag, dem 02.05.2022 um 10:29 -0700 schrieb Rob Clark:
> From: Rob Clark <robdclark@chromium.org>
> 
> Running the GPU without an IOMMU is not really a supported (or sane)
> configuration.  Yet it can be useful during SoC bringup (ie. if the
> iommu driver doesn't work yet).
> 
> Lets limit it to users who already have /dev/mem access, to avoid the
> chance that a user accidentially configures kernel without IOMMU
> support.

I haven't followed MSM too closely, so ctx->aspace may also include the
GPU MMU, but if this really only includes the IOMMU (as the commit
message implies) then this breaks Freedreno on i.MX5.

Regards,
Lucas

> 
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> ---
>  drivers/gpu/drm/msm/msm_gem_submit.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 23b68bc945f6..9cd8c8708990 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -734,6 +734,11 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
>  	if (args->pad)
>  		return -EINVAL;
>  
> +	if (unlikely(!ctx->aspace) && !capable(CAP_SYS_RAWIO)) {
> +		DRM_ERROR_RATELIMITED("IOMMU support or CAP_SYS_RAWIO required!\n");
> +		return -EPERM;
> +	}
> +
>  	/* for now, we just have 3d pipe.. eventually this would need to
>  	 * be more clever to dispatch to appropriate gpu module:
>  	 */