MICRADS 2020, Quito, Ecuador | Deadline: December 31

2019-12-21 Thread Maria Lemos
* Proceedings by Springer, indexed by Scopus, ISI, EI-Compendex, Google Scholar, etc. -- MICRADS´20 - The 2020 Multidisciplinary International Conference of Research Applied to Defense and Security Quito, Ecuador, 13 - 15 May 2020

[PATCH 6/8] iommu: allow the dma-iommu api to use bounce buffers

2019-12-21 Thread Tom Murphy
Allow the dma-iommu api to use bounce buffers for untrusted devices. This is a copy of the intel bounce buffer code. Signed-off-by: Tom Murphy --- drivers/iommu/dma-iommu.c | 93 --- drivers/iommu/iommu.c | 10 + include/linux/iommu.h | 9 +++- 3

[PATCH 7/8] iommu/vt-d: Convert intel iommu driver to the iommu ops

2019-12-21 Thread Tom Murphy
Convert the intel iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the intel iommu driver. Signed-off-by: Tom Murphy --- drivers/iommu/Kconfig | 1 + drivers/iommu/intel-iommu.c | 742 +++-

[PATCH 1/8] iommu/vt-d: clean up 32bit si_domain assignment

2019-12-21 Thread Tom Murphy
In the intel iommu driver devices which only support 32bit DMA can't be direct mapped. The implementation of this is weird. Currently we assign it a direct mapped domain and then remove the domain later and replace it with a domain of type IOMMU_DOMAIN_IDENTITY. We should just assign it a domain

[PATCH 0/8] Convert the intel iommu driver to the dma-iommu api

2019-12-21 Thread Tom Murphy
This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here:

[PATCH 3/8] iommu/vt-d: Remove IOVA handling code from non-dma_ops path

2019-12-21 Thread Tom Murphy
Remove all IOVA handling code from the non-dma_ops path in the intel iommu driver. There's no need for the non-dma_ops path to keep track of IOVAs. The whole point of the non-dma_ops path is that it allows the IOVAs to be handled separately. The IOVA handling code removed in this patch is

[PATCH 8/8] DO NOT MERGE: iommu: disable list appending in dma-iommu

2019-12-21 Thread Tom Murphy
ops __finalise_sg Disable combining sg segments in the dma-iommu api. Combining the sg segments exposes a bug in the intel i915 driver which causes visual artifacts and the screen to freeze. This is most likely because of how the i915 handles the returned list. It probably doesn't respect the

[PATCH 2/8] iommu/vt-d: Use default dma_direct_* mapping functions for direct mapped devices

2019-12-21 Thread Tom Murphy
We should only assign intel_dma_ops to devices which will actually use the iommu and let the default fall back dma_direct_* functions handle all other devices. This won't change any behaviour but will just use the generic implementations for direct mapped devices rather than intel specific ones.

[PATCH 5/8] iommu: Add iommu_dma_free_cpu_cached_iovas function

2019-12-21 Thread Tom Murphy
to dma-iommu ops Add a iommu_dma_free_cpu_cached_iovas function to allow drivers which use the dma-iommu ops to free cached cpu iovas. Signed-off-by: Tom Murphy --- drivers/iommu/dma-iommu.c | 9 + include/linux/dma-iommu.h | 3 +++ 2 files changed, 12 insertions(+) diff --git

[PATCH 4/8] iommu: Handle freelists when using deferred flushing in iommu drivers

2019-12-21 Thread Tom Murphy
Allow the iommu_unmap_fast to return newly freed page table pages and pass the freelist to queue_iova in the dma-iommu ops path. This is useful for iommu drivers (in this case the intel iommu driver) which need to wait for the ioTLB to be flushed before newly free/unmapped page table pages can be