From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Subject: Re: [PATCH v7 22/22] iommu/dma: Avoid PCI host bridge windows Date: Wed, 14 Sep 2016 14:35:30 +0200 Message-ID: References: <5f7bfee298f98d29a35933d3e0252d32b83d62b8.1473695704.git.robin.murphy@arm.com> <49c51c4f-cb00-445d-b8f8-b632babf2b3e@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <49c51c4f-cb00-445d-b8f8-b632babf2b3e-5wv7dgnIgG8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Robin Murphy , will.deacon-5wv7dgnIgG8@public.gmane.org, joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org, jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org, punit.agrawal-5wv7dgnIgG8@public.gmane.org, thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Inki Dae List-Id: devicetree@vger.kernel.org Hi Robin, On 2016-09-14 13:10, Robin Murphy wrote: > On 14/09/16 11:55, Marek Szyprowski wrote: >> On 2016-09-12 18:14, Robin Murphy wrote: >>> With our DMA ops enabled for PCI devices, we should avoid allocating >>> IOVAs which a host bridge might misinterpret as peer-to-peer DMA and >>> lead to faults, corruption or other badness. To be safe, punch out holes >>> for all of the relevant host bridge's windows when initialising a DMA >>> domain for a PCI device. >>> >>> CC: Marek Szyprowski >>> CC: Inki Dae >>> Reported-by: Lorenzo Pieralisi >>> Signed-off-by: Robin Murphy >> I don't know much about PCI and their IOMMU integration, but can't we use >> the direct mapping region feature of iommu core for it? There are already >> iommu_get_dm_regions(), iommu_put_dm_regions() and >> iommu_request_dm_for_dev() >> functions for handling them... > It's rather the opposite problem - in the direct-mapping case, we're > making sure the iommu_domain has translations installed for the given > IOVAs (which are also the corresponding physical address) before it goes > live, whereas what we need to do here is make sure the these addresses > never get used as IOVAs at all, because any attempt to do so them will > likely go wrong. Thus we carve them out of the iova_domain such that > they will never get near an actual IOMMU API call. > > This is a slightly generalised equivalent of e.g. amd_iommu.c's > init_reserved_iova_ranges(). Hmmm. Each dm_region have protection parameter. Can't we reuse them to create prohibited/reserved regions by setting it to 0 (no read / no write) and mapping to physical 0 address? That's just a quick idea, because dm_regions and the proposed code for pci looks a bit similar for me... [...] Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.szyprowski@samsung.com (Marek Szyprowski) Date: Wed, 14 Sep 2016 14:35:30 +0200 Subject: [PATCH v7 22/22] iommu/dma: Avoid PCI host bridge windows In-Reply-To: <49c51c4f-cb00-445d-b8f8-b632babf2b3e@arm.com> References: <5f7bfee298f98d29a35933d3e0252d32b83d62b8.1473695704.git.robin.murphy@arm.com> <49c51c4f-cb00-445d-b8f8-b632babf2b3e@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Robin, On 2016-09-14 13:10, Robin Murphy wrote: > On 14/09/16 11:55, Marek Szyprowski wrote: >> On 2016-09-12 18:14, Robin Murphy wrote: >>> With our DMA ops enabled for PCI devices, we should avoid allocating >>> IOVAs which a host bridge might misinterpret as peer-to-peer DMA and >>> lead to faults, corruption or other badness. To be safe, punch out holes >>> for all of the relevant host bridge's windows when initialising a DMA >>> domain for a PCI device. >>> >>> CC: Marek Szyprowski >>> CC: Inki Dae >>> Reported-by: Lorenzo Pieralisi >>> Signed-off-by: Robin Murphy >> I don't know much about PCI and their IOMMU integration, but can't we use >> the direct mapping region feature of iommu core for it? There are already >> iommu_get_dm_regions(), iommu_put_dm_regions() and >> iommu_request_dm_for_dev() >> functions for handling them... > It's rather the opposite problem - in the direct-mapping case, we're > making sure the iommu_domain has translations installed for the given > IOVAs (which are also the corresponding physical address) before it goes > live, whereas what we need to do here is make sure the these addresses > never get used as IOVAs at all, because any attempt to do so them will > likely go wrong. Thus we carve them out of the iova_domain such that > they will never get near an actual IOMMU API call. > > This is a slightly generalised equivalent of e.g. amd_iommu.c's > init_reserved_iova_ranges(). Hmmm. Each dm_region have protection parameter. Can't we reuse them to create prohibited/reserved regions by setting it to 0 (no read / no write) and mapping to physical 0 address? That's just a quick idea, because dm_regions and the proposed code for pci looks a bit similar for me... [...] Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland