- 25 Mar, 2014 1 commit
-
-
Joerg Roedel authored
When ir_dev_scope_init() is called via a rootfs initcall it will check for irq_remapping_enabled before it calls (indirectly) into dmar_acpi_dev_scope_init() which uses the dmar_tbl pointer without any checks. The AMD IOMMU driver also sets the irq_remapping_enabled flag which causes the dmar_acpi_dev_scope_init() function to be called on systems with AMD IOMMU hardware too, causing a boot-time kernel crash. Signed-off-by: Joerg Roedel <joro@8bytes.org>
-
- 24 Mar, 2014 30 commits
-
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
It might not be... Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Mostly made redundant by using dev_name() instead of pci_name(), and one instance of using *dev->dma_mask instead of pdev->dma_mask. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Should hopefully never happen (RMRRs are an abomination) but while we're busy eliminating all the PCI assumptions, we might as well do it. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Pass the struct device to it, and also make it return the bus/devfn to use, since that is also stored in the DMAR table. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
It's accessible via info->iommu->segment so this is redundant. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
This was problematic because it works by domain/bus/devfn and we want to make device_to_iommu() use only a struct device * (for handling non-PCI devices). Now that the iommu pointer is reliably stored in the device_domain_info, we don't need to look it up. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Now we store the iommu in the device_domain_info, we don't need to do a lookup. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
By moving this into get_domain_for_dev() we can make dmar_insert_dev_info() suitable for use with "special" domains such as the si_domain, which currently use domain_add_dev_info(). Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
It's not only for PCI devices any more, and the scope information for an ACPI device provides the bus and devfn so that has to be stored here too. It is the device pointer itself which needs to be protected with RCU, so the __rcu annotation follows it into the definition of struct dmar_dev_scope, since we're no longer just passing arrays of device pointers around. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
- 20 Mar, 2014 3 commits
-
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
- 19 Mar, 2014 4 commits
-
-
David Woodhouse authored
In commit 2e12bc29 ("intel-iommu: Default to non-coherent for domains unattached to iommus") we decided to err on the side of caution and always assume that it's possible that a device will be attached which is behind a non-coherent IOMMU. In some cases, however, that just *cannot* happen. If there *are* no IOMMUs in the system which are non-coherent, then we don't need to do it. And flushing the dcache is a *significant* performance hit. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
There is a race condition between the existing clear/free code and the hardware. The IOMMU is actually permitted to cache the intermediate levels of the page tables, and doesn't need to walk the table from the very top of the PGD each time. So the existing back-to-back calls to dma_pte_clear_range() and dma_pte_free_pagetable() can lead to a use-after-free where the IOMMU reads from a freed page table. When freeing page tables we actually need to do the IOTLB flush, with the 'invalidation hint' bit clear to indicate that it's not just a leaf-node flush, after unlinking each page table page from the next level up but before actually freeing it. So in the rewritten domain_unmap() we just return a list of pages (using pg->freelist to make a list of them), and then the caller is expected to do the appropriate IOTLB flush (or tear down the domain completely, whatever), before finally calling dma_free_pagelist() to free the pages. As an added bonus, we no longer need to flush the CPU's data cache for pages which are about to be *removed* from the page table hierarchy anyway, in the non-cache-coherent case. This drastically improves the performance of large unmaps. As a side-effect of all these changes, this also fixes the fact that intel_iommu_unmap() was neglecting to free the page tables for the range in question after clearing them. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
David Woodhouse authored
We have this horrid API where iommu_unmap() can unmap more than it's asked to, if the IOVA in question happens to be mapped with a large page. Instead of propagating this nonsense to the point where we end up returning the page order from dma_pte_clear_range(), let's just do it once and adjust the 'size' parameter accordingly. Augment pfn_to_dma_pte() to return the level at which the PTE was found, which will also be useful later if we end up changing the API for iommu_iova_to_phys() to behave the same way as is being discussed upstream. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
-
- 04 Mar, 2014 2 commits
-
-
Jiang Liu authored
If static identity domain is created, IOMMU driver needs to update si_domain page table when memory hotplug event happens. Otherwise PCI device DMA operations can't access the hot-added memory regions. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
-
Jiang Liu authored
Now we have a PCI bus notification based mechanism to update DMAR device scope array, we could extend the mechanism to support boot time initialization too, which will help to unify and simplify the implementation. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Joerg Roedel <joro@8bytes.org>
-