Commits · d4b709f48ed44d42ed90c1a85dda7fd053d36ce1 · nexedi / linux

24 Mar, 2014 21 commits
- iommu/vt-d: Make get_valid_domain_for_dev() take struct device · d4b709f4
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  d4b709f4
- iommu/vt-d: Make iommu_should_identity_map() take struct device · 3bdb2591
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  3bdb2591
- iommu/vt-d: Handle RMRRs for non-PCI devices · 0b9d9753
  David Woodhouse authored Mar 09, 2014
```
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>
```
  0b9d9753
- iommu/vt-d: Make get_domain_for_dev() take struct device · 146922ec
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  146922ec
- iommu/vt-d: Make domain_context_mapp{ed,ing}() take struct device · e1f167f3
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  e1f167f3
- iommu/vt-d: Make device_to_iommu() cope with non-PCI devices · 156baca8
  David Woodhouse authored Mar 09, 2014
```
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>
```
  156baca8
- iommu/vt-d: Make identity_mapping() take struct device not struct pci_dev · 9b226624
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  9b226624
- iommu/vt-d: Remove segment from struct device_domain_info() · 41e80dca
  David Woodhouse authored Mar 09, 2014
```
It's accessible via info->iommu->segment so this is redundant.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  41e80dca
- iommu/vt-d: Store PCI segment number in struct intel_iommu · 67ccac41
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  67ccac41
- iommu/vt-d: Remove device_to_iommu() call from domain_remove_dev_info() · 7c7faa11
  David Woodhouse authored Mar 09, 2014
```
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>
```
  7c7faa11
- iommu/vt-d: Simplify iommu check in domain_remove_one_dev_info() · 8bbc4410
  David Woodhouse authored Mar 09, 2014
```
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>
```
  8bbc4410
- iommu/vt-d: Always store iommu in device_domain_info · 5a8f40e8
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  5a8f40e8
- iommu/vt-d: Use domain_remove_one_dev_info() in domain_add_dev_info() error path · e2f8c5f6
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  e2f8c5f6
- iommu/vt-d: use dmar_insert_dev_info() from dma_add_dev_info() · 0ac72664
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  0ac72664
- iommu/vt-d: Stop dmar_insert_dev_info() freeing domains on losing race · b718cd3d
  David Woodhouse authored Mar 09, 2014
```
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>
```
  b718cd3d
- iommu/vt-d: Pass iommu to domain_context_mapping_one() and iommu_support_dev_iotlb() · 64ae892b
  David Woodhouse authored Mar 09, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  64ae892b
- iommu/vt-d: Use struct device in device_domain_info, not struct pci_dev · 0bcb3e28
  David Woodhouse authored Mar 06, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  0bcb3e28
- iommu/vt-d: Make dmar_insert_dev_info() take struct device instead of struct pci_dev · 1525a29a
  David Woodhouse authored Mar 06, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  1525a29a
- iommu/vt-d: Make iommu_dummy() take struct device instead of struct pci_dev · 3d89194a
  David Woodhouse authored Mar 06, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  3d89194a
- iommu/vt-d: Add ACPI devices into dmaru->devices[] array · ed40356b
  David Woodhouse authored Mar 07, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  ed40356b
- iommu/vt-d: Change scope lists to struct device, bus, devfn · 832bd858
  David Woodhouse authored Mar 07, 2014
```
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>
```
  832bd858
20 Mar, 2014 3 commits
- iommu/vt-d: Allocate space for ACPI devices · 07cb52ff
  David Woodhouse authored Mar 07, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  07cb52ff
- iommu/vt-d: Parse ANDD records · e625b4a9
  David Woodhouse authored Mar 07, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  e625b4a9
- iommu/vt-d: Add ACPI namespace device reporting structures · 86a54dcc
  David Woodhouse authored Mar 07, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
  86a54dcc
19 Mar, 2014 4 commits

iommu/vt-d: Be less pessimistic about domain coherency where possible · d0501960

David Woodhouse authored Mar 11, 2014

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>

d0501960

iommu/vt-d: Honour intel_iommu=sp_off for non-VMM domains · 214e39aa
David Woodhouse authored Mar 19, 2014
```
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
```
214e39aa

iommu/vt-d: Clean up and fix page table clear/free behaviour · ea8ea460

David Woodhouse authored Mar 05, 2014

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>

ea8ea460

iommu/vt-d: Clean up size handling for intel_iommu_unmap() · 5cf0a76f

David Woodhouse authored Mar 19, 2014

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>

5cf0a76f

04 Mar, 2014 12 commits