From: Alyssa Rosenzweig <alyssa@rosenzweig.io> To: Robin Murphy <robin.murphy@arm.com> Cc: Sven Peter <sven@svenpeter.dev>, Sven Peter <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@kernel.org>, Mohamed Mediouni <mohamed.mediouni@caramail.com>, Alexander Graf <graf@amazon.com>, Hector Martin <marcan@marcan.st>, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/8] iommu/dma: Disable get_sgtable for granule > PAGE_SIZE Date: Fri, 3 Sep 2021 09:11:14 -0400 [thread overview] Message-ID: <YTIe8t8ImNfZtAyO@sunset> (raw) In-Reply-To: <74621c69-ef68-c12a-3770-319cb7a0db73@arm.com> > > On the IOMMU API level you have much more information available about the actual > > hardware and can prepare the buffers in a way that makes both devices happy. > > That's why iommu_map_sgtable combined with iovad->granule aligned sgt entries > > can actually guarantee to map the entire list to a single contiguous IOVA block. > > Essentially there are two reasonable options, and doing pretend dma-buf > export/import between two devices effectively owned by the same driver is > neither of them. Handily, DRM happens to be exactly where all the precedent > is, too; unsurprisingly this is not a new concern. > > One is to go full IOMMU API, like rockchip or tegra, attaching the relevant > devices to your own unmanaged domain(s) and mapping pages exactly where you > choose. You still make dma_map/dma_unmap calls for the sake of cache > maintenance and other housekeeping on the underlying memory, but you ignore > the provided DMA addresses in favour of your own IOVAs when it comes to > programming the devices. I guess this is the way to go for DCP. > The lazier option if you can rely on all relevant devices having equal DMA > and IOMMU capabilities is to follow exynos, and herd the devices into a > common default domain. Instead of allocating you own domain, you grab the > current domain for one device (which will be its default domain) and > manually attach the other devices to that. Then you forget all about IOMMUs > but make sure to do all your regular DMA API calls using that first device, > and the DMA addresses which come back should be magically valid for the > other devices too. It was a bit of a cheeky hack TBH, but I'd still much > prefer more of that over any usage of get_sgtable outside of actual > dma-buf... It'd probably be *possible* to get away with this for DCP but it'd probably involve more hacks, since the DARTs are not 100% symmetric and there are some contraints on the different DARTs involved. It'd also be less desirable -- there is no reason for the display coprocessor to know the actual *contents* of the framebuffer, only the IOVA valid only for the actual display hardware. These are two devices in hardware with two independent DARTs, by modeling as such we reduce the amount we need to trust the coprocessor firmware blob. > Note that where multiple IOMMU instances are involved, the latter approach > does depend on the IOMMU driver being able to support sharing a single > domain across them; I think that might sort-of-work for DART already, but > may need a little more attention. I think this already works (for USB-C).
WARNING: multiple messages have this Message-ID (diff)
From: Alyssa Rosenzweig <alyssa@rosenzweig.io> To: Robin Murphy <robin.murphy@arm.com> Cc: Arnd Bergmann <arnd@kernel.org>, Hector Martin <marcan@marcan.st>, linux-kernel@vger.kernel.org, Sven Peter <iommu@lists.linux-foundation.org>, Alexander Graf <graf@amazon.com>, Mohamed Mediouni <mohamed.mediouni@caramail.com>, Will Deacon <will@kernel.org> Subject: Re: [PATCH v2 3/8] iommu/dma: Disable get_sgtable for granule > PAGE_SIZE Date: Fri, 3 Sep 2021 09:11:14 -0400 [thread overview] Message-ID: <YTIe8t8ImNfZtAyO@sunset> (raw) In-Reply-To: <74621c69-ef68-c12a-3770-319cb7a0db73@arm.com> > > On the IOMMU API level you have much more information available about the actual > > hardware and can prepare the buffers in a way that makes both devices happy. > > That's why iommu_map_sgtable combined with iovad->granule aligned sgt entries > > can actually guarantee to map the entire list to a single contiguous IOVA block. > > Essentially there are two reasonable options, and doing pretend dma-buf > export/import between two devices effectively owned by the same driver is > neither of them. Handily, DRM happens to be exactly where all the precedent > is, too; unsurprisingly this is not a new concern. > > One is to go full IOMMU API, like rockchip or tegra, attaching the relevant > devices to your own unmanaged domain(s) and mapping pages exactly where you > choose. You still make dma_map/dma_unmap calls for the sake of cache > maintenance and other housekeeping on the underlying memory, but you ignore > the provided DMA addresses in favour of your own IOVAs when it comes to > programming the devices. I guess this is the way to go for DCP. > The lazier option if you can rely on all relevant devices having equal DMA > and IOMMU capabilities is to follow exynos, and herd the devices into a > common default domain. Instead of allocating you own domain, you grab the > current domain for one device (which will be its default domain) and > manually attach the other devices to that. Then you forget all about IOMMUs > but make sure to do all your regular DMA API calls using that first device, > and the DMA addresses which come back should be magically valid for the > other devices too. It was a bit of a cheeky hack TBH, but I'd still much > prefer more of that over any usage of get_sgtable outside of actual > dma-buf... It'd probably be *possible* to get away with this for DCP but it'd probably involve more hacks, since the DARTs are not 100% symmetric and there are some contraints on the different DARTs involved. It'd also be less desirable -- there is no reason for the display coprocessor to know the actual *contents* of the framebuffer, only the IOVA valid only for the actual display hardware. These are two devices in hardware with two independent DARTs, by modeling as such we reduce the amount we need to trust the coprocessor firmware blob. > Note that where multiple IOMMU instances are involved, the latter approach > does depend on the IOMMU driver being able to support sharing a single > domain across them; I think that might sort-of-work for DART already, but > may need a little more attention. I think this already works (for USB-C). _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-09-03 16:16 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-28 15:36 [PATCH v2 0/8] Support IOMMU page sizes larger than the CPU page size Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-28 15:36 ` [PATCH v2 1/8] iommu/dma: Align size for untrusted devs to IOVA granule Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-28 15:36 ` [PATCH v2 2/8] iommu/dma: Fail unaligned map requests for untrusted devs Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-28 19:00 ` Sven Peter 2021-08-28 19:00 ` Sven Peter via iommu 2021-08-28 15:36 ` [PATCH v2 3/8] iommu/dma: Disable get_sgtable for granule > PAGE_SIZE Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-31 21:30 ` Alyssa Rosenzweig 2021-08-31 21:30 ` Alyssa Rosenzweig 2021-09-01 17:06 ` Sven Peter 2021-09-01 17:06 ` Sven Peter via iommu 2021-09-01 21:10 ` Alyssa Rosenzweig 2021-09-01 21:10 ` Alyssa Rosenzweig 2021-09-02 18:19 ` Sven Peter 2021-09-02 18:19 ` Sven Peter via iommu 2021-09-02 19:42 ` Robin Murphy 2021-09-02 19:42 ` Robin Murphy 2021-09-03 13:11 ` Alyssa Rosenzweig [this message] 2021-09-03 13:11 ` Alyssa Rosenzweig 2021-09-03 15:16 ` Sven Peter 2021-09-03 15:16 ` Sven Peter via iommu 2021-09-03 15:45 ` Robin Murphy 2021-09-03 15:45 ` Robin Murphy 2021-09-03 16:51 ` Sven Peter 2021-09-03 16:51 ` Sven Peter via iommu 2021-08-28 15:36 ` [PATCH v2 4/8] iommu/dma: Support granule > PAGE_SIZE in dma_map_sg Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-28 21:10 ` kernel test robot 2021-08-28 21:10 ` kernel test robot 2021-08-28 21:10 ` kernel test robot 2021-08-28 22:31 ` kernel test robot 2021-08-28 22:31 ` kernel test robot 2021-08-28 22:33 ` kernel test robot 2021-08-28 22:33 ` kernel test robot 2021-08-28 22:33 ` kernel test robot 2021-08-28 15:36 ` [PATCH v2 5/8] iommu/dma: Support PAGE_SIZE < iovad->granule allocations Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-28 15:36 ` [PATCH v2 6/8] iommu: Move IOMMU pagesize check to attach_device Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-31 21:39 ` Alyssa Rosenzweig 2021-08-31 21:39 ` Alyssa Rosenzweig 2021-09-01 17:14 ` Sven Peter 2021-09-01 17:14 ` Sven Peter via iommu 2021-09-01 18:53 ` Robin Murphy 2021-09-01 18:53 ` Robin Murphy 2021-08-28 15:36 ` [PATCH v2 7/8] iommu: Introduce __IOMMU_DOMAIN_LP Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-28 15:36 ` [PATCH v2 8/8] iommu/dart: Remove force_bypass logic Sven Peter 2021-08-28 15:36 ` Sven Peter via iommu 2021-08-31 21:40 ` Alyssa Rosenzweig 2021-08-31 21:40 ` Alyssa Rosenzweig 2021-08-31 21:32 ` [PATCH v2 0/8] Support IOMMU page sizes larger than the CPU page size Alyssa Rosenzweig 2021-08-31 21:32 ` Alyssa Rosenzweig
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=YTIe8t8ImNfZtAyO@sunset \ --to=alyssa@rosenzweig.io \ --cc=arnd@kernel.org \ --cc=graf@amazon.com \ --cc=iommu@lists.linux-foundation.org \ --cc=joro@8bytes.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marcan@marcan.st \ --cc=mohamed.mediouni@caramail.com \ --cc=robin.murphy@arm.com \ --cc=sven@svenpeter.dev \ --cc=will@kernel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.