linux-toradex.git/include/linux/intel-iommu.h, branch v4.1.14

iommu/vt-d: Change PASID support to bit 40 of Extended Capability Register

2015-06-09T14:06:55+00:00

The existing hardware implementations with PASID support advertised in
bit 28? Forget them. They do not exist. Bit 28 means nothing. When we
have something that works, it'll use bit 40. Do not attempt to infer
anything meaningful from bit 28.

This will be reflected in an updated VT-d spec in the extremely near
future.

Signed-off-by: David Woodhouse

iommu/vt-d: Add new extended capabilities from v2.3 VT-d specification

2015-03-25T15:43:39+00:00

Signed-off-by: David Woodhouse

iommu/vt-d: kill bogus ecap_niotlb_iunits()

2015-03-25T15:35:01+00:00

As far back as I can see (which right now is a draft of the v1.2 spec
dating from September 2008), bits 24-31 of the Extended Capability Register
have already been reserved. I have no idea why anyone ever thought there
would be multiple sets of IOTLB registers, but we've never supported them
and all we do is make sure we map enough MMIO space for them.

Kill it dead. Those bits do actually have a different meaning now.

Signed-off-by: David Woodhouse

iommu/vt-d: Make use of IOMMU sysfs support

2014-07-04T10:35:59+00:00

Register our DRHD IOMMUs, cross link devices, and provide a base set
of attributes for the IOMMU.  Note that IRQ remapping support parses
the DMAR table very early in boot, well before the iommu_class can
reasonably be setup, so our registration is split between
intel_iommu_init(), which occurs later, and alloc_iommu(), which
typically occurs much earlier, but may happen at any time later
with IOMMU hot-add support.

On a typical desktop system, this provides the following (pruned):

$ find /sys | grep dmar
/sys/devices/virtual/iommu/dmar0
/sys/devices/virtual/iommu/dmar0/devices
/sys/devices/virtual/iommu/dmar0/devices/0000:00:02.0
/sys/devices/virtual/iommu/dmar0/intel-iommu
/sys/devices/virtual/iommu/dmar0/intel-iommu/cap
/sys/devices/virtual/iommu/dmar0/intel-iommu/ecap
/sys/devices/virtual/iommu/dmar0/intel-iommu/address
/sys/devices/virtual/iommu/dmar0/intel-iommu/version
/sys/devices/virtual/iommu/dmar1
/sys/devices/virtual/iommu/dmar1/devices
/sys/devices/virtual/iommu/dmar1/devices/0000:00:00.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:01.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:16.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1a.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1b.0
/sys/devices/virtual/iommu/dmar1/devices/0000:00:1c.0
...
/sys/devices/virtual/iommu/dmar1/intel-iommu
/sys/devices/virtual/iommu/dmar1/intel-iommu/cap
/sys/devices/virtual/iommu/dmar1/intel-iommu/ecap
/sys/devices/virtual/iommu/dmar1/intel-iommu/address
/sys/devices/virtual/iommu/dmar1/intel-iommu/version
/sys/class/iommu/dmar0
/sys/class/iommu/dmar1

(devices also link back to the dmar units)

This makes address, version, capabilities, and extended capabilities
available, just like printed on boot.  I've tried not to duplicate
data that can be found in the DMAR table, with the exception of the
address, which provides an easy way to associate the sysfs device with
a DRHD entry in the DMAR.  It's tempting to add scopes and RMRR data
here, but the full DMAR table is already exposed under /sys/firmware/
and therefore already provides a way for userspace to learn such
details.

Signed-off-by: Alex Williamson 
Signed-off-by: Joerg Roedel

iommu/vt-d: Store PCI segment number in struct intel_iommu

2014-03-24T14:07:31+00:00

Signed-off-by: David Woodhouse

iommu/vt-d: keep shared resources when failed to initialize iommu devices

2014-01-09T11:43:40+00:00

Data structure drhd->iommu is shared between DMA remapping driver and
interrupt remapping driver, so DMA remapping driver shouldn't release
drhd->iommu when it failed to initialize IOMMU devices. Otherwise it
may cause invalid memory access to the interrupt remapping driver.

Sample stack dump:
[   13.315090] BUG: unable to handle kernel paging request at ffffc9000605a088
[   13.323221] IP: [] qi_submit_sync+0x15c/0x400
[   13.330107] PGD 82f81e067 PUD c2f81e067 PMD 82e846067 PTE 0
[   13.336818] Oops: 0002 [#1] SMP
[   13.340757] Modules linked in:
[   13.344422] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.13.0-rc1-gerry+ #7
[   13.352474] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T,                                               BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[   13.365659] Workqueue: events work_for_cpu_fn
[   13.370774] task: ffff88042ddf00d0 ti: ffff88042ddee000 task.ti: ffff88042dde                                              e000
[   13.379389] RIP: 0010:[]  [] qi_submit_sy                                              nc+0x15c/0x400
[   13.389055] RSP: 0000:ffff88042ddef940  EFLAGS: 00010002
[   13.395151] RAX: 00000000000005e0 RBX: 0000000000000082 RCX: 0000000200000025
[   13.403308] RDX: ffffc9000605a000 RSI: 0000000000000010 RDI: ffff88042ddb8610
[   13.411446] RBP: ffff88042ddef9a0 R08: 00000000000005d0 R09: 0000000000000001
[   13.419599] R10: 0000000000000000 R11: 000000000000005d R12: 000000000000005c
[   13.427742] R13: ffff88102d84d300 R14: 0000000000000174 R15: ffff88042ddb4800
[   13.435877] FS:  0000000000000000(0000) GS:ffff88043de00000(0000) knlGS:00000                                              00000000000
[   13.445168] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   13.451749] CR2: ffffc9000605a088 CR3: 0000000001a0b000 CR4: 00000000000407f0
[   13.459895] Stack:
[   13.462297]  ffff88042ddb85d0 000000000000005d ffff88042ddef9b0 0000000000000                                              5d0
[   13.471147]  00000000000005c0 ffff88042ddb8000 000000000000005c 0000000000000                                              015
[   13.480001]  ffff88042ddb4800 0000000000000282 ffff88042ddefa40 ffff88042ddef                                              ac0
[   13.488855] Call Trace:
[   13.491771]  [] modify_irte+0x9d/0xd0
[   13.497778]  [] intel_setup_ioapic_entry+0x10d/0x290
[   13.505250]  [] ? trace_hardirqs_on_caller+0x16/0x1e0
[   13.512824]  [] ? default_init_apic_ldr+0x60/0x60
[   13.519998]  [] setup_ioapic_remapped_entry+0x20/0x30
[   13.527566]  [] io_apic_setup_irq_pin+0x12a/0x2c0
[   13.534742]  [] ? acpi_pci_irq_find_prt_entry+0x2b9/0x2d8
[   13.544102]  [] io_apic_setup_irq_pin_once+0x85/0xa0
[   13.551568]  [] ? mp_find_ioapic_pin+0x8f/0xf0
[   13.558434]  [] io_apic_set_pci_routing+0x34/0x70
[   13.565621]  [] mp_register_gsi+0xaf/0x1c0
[   13.572111]  [] acpi_register_gsi_ioapic+0xe/0x10
[   13.579286]  [] acpi_register_gsi+0xf/0x20
[   13.585779]  [] acpi_pci_irq_enable+0x171/0x1e3
[   13.592764]  [] pcibios_enable_device+0x31/0x40
[   13.599744]  [] do_pci_enable_device+0x3b/0x60
[   13.606633]  [] pci_enable_device_flags+0xc8/0x120
[   13.613887]  [] pci_enable_device+0x13/0x20
[   13.620484]  [] pcie_port_device_register+0x1e/0x510
[   13.627947]  [] ? trace_hardirqs_on_caller+0x16/0x1e0
[   13.635510]  [] ? trace_hardirqs_on+0xd/0x10
[   13.642189]  [] pcie_portdrv_probe+0x58/0xc0
[   13.648877]  [] local_pci_probe+0x45/0xa0
[   13.655266]  [] work_for_cpu_fn+0x14/0x20
[   13.661656]  [] process_one_work+0x369/0x710
[   13.668334]  [] ? process_one_work+0x2f2/0x710
[   13.675215]  [] ? worker_thread+0x46/0x690
[   13.681714]  [] worker_thread+0x484/0x690
[   13.688109]  [] ? cancel_delayed_work_sync+0x20/0x20
[   13.695576]  [] kthread+0xf0/0x110
[   13.701300]  [] ? local_clock+0x3f/0x50
[   13.707492]  [] ? kthread_create_on_node+0x250/0x250
[   13.714959]  [] ret_from_fork+0x7c/0xb0
[   13.721152]  [] ? kthread_create_on_node+0x250/0x250

Signed-off-by: Jiang Liu 
Signed-off-by: Joerg Roedel

iommu/vt-d: mark internal functions as static

2014-01-09T11:43:33+00:00

Functions alloc_iommu() and parse_ioapics_under_ir()
are only used internally, so mark them as static.

[Joerg: Made detect_intel_iommu() non-static again for IA64]

Signed-off-by: Jiang Liu 
Signed-off-by: Joerg Roedel

iommu/vt-d: use dedicated bitmap to track remapping entry allocation status

2014-01-07T16:16:19+00:00

Currently Intel interrupt remapping drivers uses the "present" flag bit
in remapping entry to track whether an entry is allocated or not.
It works as follow:
1) allocate a remapping entry and set its "present" flag bit to 1
2) compose other fields for the entry
3) update the remapping entry with the composed value

The remapping hardware may access the entry between step 1 and step 3,
which then observers an entry with the "present" flag set but random
values in all other fields.

This patch introduces a dedicated bitmap to track remapping entry
allocation status instead of sharing the "present" flag with hardware,
thus eliminate the race window. It also simplifies the implementation.

Tested-and-reviewed-by: Yijing Wang 
Signed-off-by: Jiang Liu 
Signed-off-by: Joerg Roedel

x86/iommu: correct ICS register offset

2013-09-24T11:04:07+00:00

According to Intel Vt-D specs, the offset of Invalidation complete
status register should be 0x9C, not 0x98.

See Intel's VT-d spec, Revision 1.3, Chapter 10.4, Page 98;

Signed-off-by: Li, Zhen-Hua 
Signed-off-by: Joerg Roedel

iommu/dmar: Reserve mmio space used by the IOMMU, if the BIOS forgets to

2012-06-08T10:15:43+00:00

Intel-iommu initialization doesn't currently reserve the memory
used for the IOMMU registers. This can allow the pci resource
allocator to assign a device BAR to the same address as the
IOMMU registers. This can cause some not so nice side affects
when the driver ioremap's that region.

Introduced two helper functions to map & unmap the IOMMU
registers as well as simplify the init and exit paths.

Signed-off-by: Donald Dutile 
Acked-by: Chris Wright 
Cc: iommu@lists.linux-foundation.org
Cc: suresh.b.siddha@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/1338845342-12464-3-git-send-email-ddutile@redhat.com
Signed-off-by: Ingo Molnar