Linux IOMMU Development
 help / color / mirror / Atom feed
From: Jordan Crouse <jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [Freedreno] [PATCH 0/7] RFC: iommu/arm-smmu-v2: Dynamic domains
Date: Tue, 7 Mar 2017 10:22:41 -0700	[thread overview]
Message-ID: <20170307172241.GB20962@jcrouse-lnx.qualcomm.com> (raw)
In-Reply-To: <1488904795-870-1-git-send-email-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

On Tue, Mar 07, 2017 at 09:39:48AM -0700, Jordan Crouse wrote:
> Pursuant to the arm-smmu-v3 SVM support:
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2017-February/020599.html
> 
> I felt it would be helpful if I would demonstrate how Qualcomm implements
> per-process pagetables for several generations of SoCs and GPUs focusing on the
> Adreno A540 GPU and an arm-smmu-v2 IOMMU on the Snapdragon 820 SoC.
> 
> The requirement is to implement per-process GPU address spaces for security
> reasons. Though some very crude SVM support is possible we focus mainly on
> individual address spaces that are maintained and mapped by the GPU driver.
> 
> In a nutshell, the solution is to create special virtual or "dynamic" domains
> that are associated with a real domain. The dynamic domains allocate pagetables
> but do not reprogram the hardware. When a command is submitted, the kernel
> driver provides the physial address of the pagetable (TTBR0) to the GPU which
> reprograms the TTBR0 register in context bank 0 of the GPMU SMMU on the fly (and
> does the requisite flushing and stalling).
> 
> The TTBR1 address space is used to maintain a split between the process and the
> global GPU buffers (ringbuffers, etc). This greatly facilitates the switching
> process.
> 
> In more detail this is the workflow:
> 
>  - The kernel driver attaches a UNMANAGED domain to context bank 0
> 
>  - Global GPU buffers are allocated in the TTBR1 address space
>  
>  - Each new process creates a dynamic domain cloned from the "real" domain
> 
>  - New buffers for the process are mapped into the dynamic domain
> 
>  - The kernel driver gets the TTBR0/ASID register value from the dynamic domain
>    via an attribute
> 
>  - At command submission time, the kernel driver sends the TTBR0/ASID value to
>    the GPU before the command. The GPU switches the pagetable by programming
>    the SMMU hardware before executing the command.
> 
> I'll be uploading the series to implement this in the MSM DRM driver to show how
> it works from the GPU perspective. I'm adding it as a separate thread to avoid
> crossing the streams and confusing folks - I'll reply to this email with a link.

Here is a link to the GPU implementation. I'll leave the link here but if
enough folks think it is useful I can reply append the actual patches to this
thread too.

https://lists.freedesktop.org/archives/freedreno/2017-March/001049.html

Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

      parent reply	other threads:[~2017-03-07 17:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-07 16:39 [PATCH 0/7] RFC: iommu/arm-smmu-v2: Dynamic domains Jordan Crouse
     [not found] ` <1488904795-870-1-git-send-email-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-03-07 16:39   ` [PATCH 1/7] iommu/arm-smmu: save the pgtbl_cfg in the domain Jordan Crouse
2017-03-07 16:39   ` [PATCH 2/7] iommu: Add DOMAIN_ATTR_ENABLE_TTBR1 Jordan Crouse
2017-03-07 16:39   ` [PATCH 3/7] iommu/arm-smmu: Add support for TTBR1 Jordan Crouse
2017-03-07 16:39   ` [PATCH 4/7] iommu: introduce TTBR0 domain attribute Jordan Crouse
2017-03-07 16:39   ` [PATCH 5/7] iommu/arm-smmu: add support for TTBR0 attribute Jordan Crouse
2017-03-07 16:39   ` [PATCH 6/7] iommu: Add dynamic domains Jordan Crouse
2017-03-07 16:39   ` [PATCH 7/7] iommu/arm-smmu: add support for " Jordan Crouse
     [not found]     ` <1488904795-870-8-git-send-email-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-03-07 18:11       ` Mark Rutland
2017-03-07 20:40         ` Jordan Crouse
2017-03-07 17:22   ` Jordan Crouse [this message]

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=20170307172241.GB20962@jcrouse-lnx.qualcomm.com \
    --to=jcrouse-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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