[PATCH v7 22/22] iommu/dma: Avoid PCI host bridge windows

[Marek Szyprowski]

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 <m.szyprowski at samsung.com>
>>> CC: Inki Dae <inki.dae at samsung.com>
>>> Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> 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