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: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

Remove dead code from VT-d related files.
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

Conflicts:

	drivers/iommu/dmar.c

Flag irq_remapping_enabled is only set by intel_enable_irq_remapping(),
which is called after detect_intel_iommu(). So moving pr_info() from
detect_intel_iommu() to intel_enable_irq_remapping(), which also
slightly simplifies implementation.
Reviewed-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

Function dmar_parse_dev_scope() should release the PCI device reference
count gained in function dmar_parse_one_dev_scope() on error recovery,
otherwise it will cause PCI device object leakage.

This patch also introduces dmar_free_dev_scope(), which will be used
to support DMAR device hotplug.
Reviewed-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

Mark the functions check_zero_address() and dmar_get_fault_reason() as
static in dmar.c because they are not used outside this file.

This eliminates the following warnings in dmar.c:
drivers/iommu/dmar.c:491:12: warning: no previous prototype for ‘check_zero_address’ [-Wmissing-prototypes]
drivers/iommu/dmar.c:1116:13: warning: no previous prototype for ‘dmar_get_fault_reason’ [-Wmissing-prototypes]
Signed-off-by: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

Use for_each_drhd_unit() instead of list_for_each_entry for
better readability.
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

This patch updates DMAR table header definitions as such enhancement
has been made in ACPICA upstream already.  It ports that change to
the Linux source to reduce source code differences between Linux and
ACPICA upstream.

Build test done on x86-64 machine with the following configs enabled:
  CONFIG_DMAR_TABLE
  CONFIG_IRQ_REMAP
  CONFIG_INTEL_IOMMU

This patch does not affect the generation of the Linux kernel binary.

[rjw: Changelog]
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In intel vt-d spec , chapter 8.1 , DMA Remapping Reporting Structure.
In the end of the table, it says:

Remapping Structures[]
-
A list of structures. The list will contain one or
more DMA Remapping Hardware Unit Definition
(DRHD) structures, and zero or more Reserved
Memory Region Reporting (RMRR) and Root Port
ATS Capability Reporting (ATSR) structures.
These structures are described below.

So, there should be at least one DRHD structure in DMA Remapping
reporting table. If there is no DRHD found, a warning is necessary.
Signed-off-by: NLi, Zhen-Hua <zhen-hual@hp.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

ACPI_DMAR_SCOPE_TYPE_HPET is parsed by ir_parse_ioapic_hpet_scope() and
should not be flagged as an unsupported type.
Signed-off-by: NLinn Crosetto <linn@hp.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

ACPI_DMAR_SCOPE_TYPE_HPET is parsed by
ir_parse_ioapic_hpet_scope() and should not be flagged as an
unsupported type.
Signed-off-by: NLinn Crosetto <linn@hp.com>
Cc: joro@8bytes.org
Cc: ddutile@redhat.com
Cc: suresh.b.siddha@intel.com
Link: http://lkml.kernel.org/r/1366741605-71293-1-git-send-email-linn@hp.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

This patch disables translation(dma-remapping) before its initialization
if it is already enabled.

This is needed for kexec/kdump boot. If dma-remapping is enabled in the
first kernel, it need to be disabled before initializing its page table
during second kernel boot. Wei Hu also reported that this is needed
when second kernel boots with intel_iommu=off.

Basically iommu->gcmd is used to know whether translation is enabled or
disabled, but it is always zero at boot time even when translation is
enabled since iommu->gcmd is initialized without considering such a
case. Therefor this patch synchronizes iommu->gcmd value with global
command register when iommu structure is allocated.
Signed-off-by: NTakao Indoh <indou.takao@jp.fujitsu.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

When there is a dmar irq, dmar_fault is called and all of the fields
in FSTS are cleared. But ICE/IQE/ITE should not be cleared here,
they need to be processed and cleared in function qi_check_fault.

[Minor cleanup by Joerg Roedel]
Signed-off-by: NLi, Zhen-Hua <zhen-hual@hp.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

The number of DMA fault reasons in intel's document are from 1
to 0xD, but in dmar.c fault reason 0xD is not printed out.

In this document:

 "Intel Virtualization Technology for Directed I/O Architecture Specification"
 http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf

Chapter 4. Support For Device-IOTLBs

Table 6. Unsuccessful Translated Requests

There is fault reason for 0xD not listed in kernel:

    Present context-entry used to process translation request
    specifies blocking of Translation Requests (Translation Type (T)
    field value not equal to 01b).

This patch adds reason 0xD as well.
Signed-off-by: NLi, Zhen-Hua <zhen-hual@hp.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Donald Dutile <ddutile@redhat.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Link: http://lkml.kernel.org/r/1362537797-6034-1-git-send-email-zhen-hual@hp.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

kmemcheck complained about the use of uninitialized memory.
Fix by using kzalloc instead of kmalloc.

Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

Remove the last left-over from this flag from x86 code.
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
Acked-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Joe Perches recommended getting rid of the redundant
formatting of adding "PREFIX" to all the uses of pr_*() calls.

The recommendation helps to reduce source and improve
readibility.

While cleaning up the PREFIX's, I saw that one of
the pr_warn() was redundant in dmar_parse_one_dev_scope(),
since the same message was printed after breaking out of the
while loop for the same condition, !pdev.
So, to avoid a duplicate message, I removed the one in the while
loop.
Reported-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDonald Dutile <ddutile@redhat.com>
Cc: iommu@lists.linux-foundation.org
Cc: chrisw@redhat.com
Cc: suresh.b.siddha@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/1339189991-13129-1-git-send-email-ddutile@redhat.com
[ Small whitespace fixes. ]
Signed-off-by: NIngo Molnar <mingo@kernel.org>

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: NDonald Dutile <ddutile@redhat.com>
Acked-by: NChris Wright <chrisw@redhat.com>
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.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Just some cleanup so next patch can keep the info printing
the same way throughout the file.

Replace printk(KERN_*  with pr_*() functions.
Signed-off-by: NDonald Dutile <ddutile@redhat.com>
Cc: iommu@lists.linux-foundation.org
Cc: chrisw@redhat.com
Cc: suresh.b.siddha@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/1338845342-12464-2-git-send-email-ddutile@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

fault_reason - 0x20 == ARRAY_SIZE(irq_remap_fault_reasons) is
one past the end of the array.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Youquan Song <youquan.song@intel.com>
Cc: walter harms <wharms@bfs.de>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/20120513170938.GA4280@elgon.mountainSigned-off-by: NIngo Molnar <mingo@kernel.org>

Make the file names consistent with the naming conventions of irq subsystem.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Make the code consistent with the naming conventions of irq subsystem.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

This patch introduces irq_remap_ops to hold implementation
specific function pointer to handle interrupt remapping. As
the first part the initialization functions for VT-d are
converted to these ops.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: yinghai@kernel.org
Cc: youquan.song@intel.com
Cc: joerg.roedel@amd.com
Cc: tony.luck@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/20110824001456.386003047@sbsiddha-desk.sc.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Before the restructruing of the x86 IOMMU code,
intel_iommu_init() was getting called directly from
pci_iommu_init() and hence needed to explicitly set
dmar_disabled to 1 for the failure conditions of
check_zero_address().

Recent changes don't call intel_iommu_init() if the intel iommu
detection fails as a result of failure in check_zero_address().

So no need for this ifdef and the code inside it.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: yinghai@kernel.org
Cc: youquan.song@intel.com
Cc: joerg.roedel@amd.com
Cc: tony.luck@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/20110824001456.334878686@sbsiddha-desk.sc.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Move the IOMMU specific routines to intel-iommu.c leaving the
dmar.c to the common ACPI dmar code shared between DMA-remapping
and Interrupt-remapping.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: yinghai@kernel.org
Cc: youquan.song@intel.com
Cc: joerg.roedel@amd.com
Cc: tony.luck@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/20110824001456.282401285@sbsiddha-desk.sc.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Both DMA-remapping aswell as Interrupt-remapping depend on the
dmar dev scope to be initialized. When both DMA and
IRQ-remapping are enabled, we depend on DMA-remapping init code
to call dmar_dev_scope_init(). This resulted in not doing this
init when DMA-remapping was turned off but interrupt-remapping
turned on in the kernel config.

This caused interrupt routing to break with CONFIG_INTR_REMAP=y
and CONFIG_DMAR=n.

This issue was introduced by this commit:

 | commit 9d5ce73a
 | Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
 | Date:   Tue Nov 10 19:46:16 2009 +0900
 |
 |    x86: intel-iommu: Convert detect_intel_iommu to use iommu_init hook

Fix this by calling dmar_dev_scope_init() explicitly from the
interrupt remapping code too.
Reported-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: yinghai@kernel.org
Cc: youquan.song@intel.com
Cc: joerg.roedel@amd.com
Cc: tony.luck@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/20110824001456.229207526@sbsiddha-desk.sc.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

On the platforms which are x2apic and interrupt-remapping
capable, Linux kernel is enabling x2apic even if the BIOS
doesn't. This is to take advantage of the features that x2apic
brings in.

Some of the OEM platforms are running into issues because of
this, as their bios is not x2apic aware. For example, this was
resulting in interrupt migration issues on one of the platforms.
Also if the BIOS SMI handling uses APIC interface to send SMI's,
then the BIOS need to be aware of x2apic mode that OS has
enabled.

On some of these platforms, BIOS doesn't have a HW mechanism to
turnoff the x2apic feature to prevent OS from enabling it.

To resolve this mess, recent changes to the VT-d2 specification:

 http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf

includes a mechanism that provides BIOS a way to request system
software to opt out of enabling x2apic mode.

Look at the x2apic optout flag in the DMAR tables before
enabling the x2apic mode in the platform. Also print a warning
that we have disabled x2apic based on the BIOS request.

Kernel boot parameter "intremap=no_x2apic_optout" can be used to
override the BIOS x2apic optout request.
Signed-off-by: NYouquan Song <youquan.song@intel.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: yinghai@kernel.org
Cc: joerg.roedel@amd.com
Cc: tony.luck@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/20110824001456.171766616@sbsiddha-desk.sc.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Mark this lowlevel IRQ handler as non-threaded. This prevents a boot
crash when "threadirqs" is on the kernel commandline. Also the
interrupt handler is handling hardware critical events which should
not be delayed into a thread.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

The qi->q_lock lock can be taken in atomic context and therefore
cannot be preempted on -rt - annotate it.

In mainline this change documents the low level nature of
the lock - otherwise there's no functional difference. Lockdep
and Sparse checking will work as usual.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The iommu->register_lock can be taken in atomic context and therefore
must not be preempted on -rt - annotate it.

In mainline this change documents the low level nature of
the lock - otherwise there's no functional difference. Lockdep
and Sparse checking will work as usual.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.

Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge()
has to move from drivers/pci/pci.h to include/linux/pci.h. This is handled
in this patch, too.

As suggested, also drop DMAR's EXPERIMENTAL tag while we're at it.

Compile-tested on x86_64.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

Since cacd4213, this comment no longer applies.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Scripted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Fault handling is getting enabled after enabling the interrupt-remapping (as
the success of interrupt-remapping can affect the apic mode and hence the
fault handling mode).

Hence there can potentially be some faults between the window of enabling
interrupt-remapping in the vt-d and the fault-handling of the vt-d units.

Handle any previous faults after enabling the vt-d fault handling.

For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the
enable_intr_remapping() and see if we can enable fault handling along with
enabling intr-remapping.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <20101201062244.630417138@intel.com>
Cc: stable@kernel.org [v2.6.32+]
Acked-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NDavid Woodhouse <dwmw2@infradead.org>

We utilize the IOMMU_INIT macros to create this dependency:

               [null]
                 |
       [pci_xen_swiotlb_detect]
                 |
       [pci_swiotlb_detect_override]
                 |
       [pci_swiotlb_detect_4gb]
                 |
         +-------+--------+---------------------+
        /                  \                     \
[detect_calgary]    [gart_iommu_hole_init]   [detect_intel_iommu]
                            |
                    [amd_iommu_detect]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
LKML-Reference: <1282845485-8991-10-git-send-email-konrad.wilk@oracle.com>
CC: Fujita Tomonori <fujita.tomonori@lab.ntt.co.jp>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Woodhouse <David.Woodhouse@intel.com>
CC: Len Brown <len.brown@intel.com>
CC: Chris Wright <chrisw@sous-sol.org>
CC: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

We return 1 if the IOMMU has been detected. Zero or an error number
if we failed to find it. This is in preperation of using the IOMMU_INIT
so that we can detect whether an IOMMU is present. I have not
tested this for regression on Calgary, nor on AMD Vi chipsets as
I don't have that hardware.

CC: Muli Ben-Yehuda <muli@il.ibm.com>
CC: "Jon D. Mason" <jdmason@kudzu.us>
CC: "Darrick J. Wong" <djwong@us.ibm.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Woodhouse <David.Woodhouse@intel.com>
CC: Chris Wright <chrisw@sous-sol.org>
CC: Yinghai Lu <yinghai@kernel.org>
CC: Joerg Roedel <joerg.roedel@amd.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Fujita Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
LKML-Reference: <1282845485-8991-3-git-send-email-konrad.wilk@oracle.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

We now know how to deal with these tables so that they are harmless.
Set TAINT_FIRMWARE_WORKAROUND instead of the default TAINT_WARN.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

We have nearly the same code for warnings repeated four times.  Move
it into a separate function.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Commit 074835f0 ("intel-iommu: Fix
kernel hand if interrupt remapping disabled in BIOS") is adding a check
for interrupt remapping disabled and is dereferencing the dmar_tbl
pointer without checking its value.

Unfortunately, this value is null when booting inside a 64bit virtual
box guest with io-apic disabled, leading to a crash. With a check on it,
the guest is now booting. It's triggering a WARN() in
clockevent_delta2ns but it's better than not booting at all and allows
the user to see there's something wrong on their io-apic setup.
Signed-off-by: NArnaud Patard <apatard@mandriva.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>