Eric Lee / smarc-fsl-linux-kernel

01 Nov, 2011

1 commit

  • 6eea69dd8   include/linux/dmar.h: forward-declare struct acpi_dmar_header ... Browse Code »

    x86_64 allnoconfig:

    In file included from arch/x86/kernel/pci-dma.c:3:
    include/linux/dmar.h:248: warning: 'struct acpi_dmar_header' declared inside parameter list
    include/linux/dmar.h:248: warning: its scope is only this definition or declaration, which is probably not what you want

    Cc: Suresh Siddha
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

21 Sep, 2011

3 commits

  • d3f138106   iommu: Rename the DMAR and INTR_REMAP config options ... Browse Code »

    Change the CONFIG_DMAR to CONFIG_INTEL_IOMMU to be consistent
    with the other IOMMU options.

    Rename the CONFIG_INTR_REMAP to CONFIG_IRQ_REMAP to match the
    irq subsystem name.

    And define the CONFIG_DMAR_TABLE for the common ACPI DMAR
    routines shared by both CONFIG_INTEL_IOMMU and CONFIG_IRQ_REMAP.

    Signed-off-by: Suresh Siddha
    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.558630224@sbsiddha-desk.sc.intel.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • 318fe7df9   iommu: Move IOMMU specific code to intel-iommu.c ... Browse Code »

    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: Suresh Siddha
    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.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • 41750d31f   x86, x2apic: Enable the bios request for x2apic optout ... Browse Code »

    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: Youquan Song
    Signed-off-by: Suresh Siddha
    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.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     

26 Nov, 2010

1 commit

  • 4917b284d   dmar, x86: Use function stubs when CONFIG_INTR_REMAP is disabled ... Browse Code »

    The stubs for CONFIG_INTR_REMAP disabled need to be functions
    instead of values to eliminate build warnings.

    arch/x86/kernel/apic/apic.c: In function 'lapic_suspend':
    arch/x86/kernel/apic/apic.c:2060:3: warning: statement with no effect
    arch/x86/kernel/apic/apic.c: In function 'lapic_resume':
    arch/x86/kernel/apic/apic.c:2137:3: warning: statement with no effect

    Reported-and-Tested-by: Fabio Comolli
    Signed-off-by: Randy Dunlap
    Cc: Suresh Siddha
    Cc: Yinghai Lu
    Cc: David Woodhouse
    Cc: Jesse Barnes
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Randy Dunlap
     

22 Oct, 2010

1 commit

  • 157b6ceb1   Merge branch 'x86-iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/… ... Browse Code »

    …git/tip/linux-2.6-tip

    * 'x86-iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86, iommu: Update header comments with appropriate naming
    ia64, iommu: Add a dummy iommu_table.h file in IA64.
    x86, iommu: Fix IOMMU_INIT alignment rules
    x86, doc: Adding comments about .iommu_table and its neighbors.
    x86, iommu: Utilize the IOMMU_INIT macros functionality.
    x86, VT-d: Make Intel VT-d IOMMU use IOMMU_INIT_* macros.
    x86, GART/AMD-VI: Make AMD GART and IOMMU use IOMMU_INIT_* macros.
    x86, calgary: Make Calgary IOMMU use IOMMU_INIT_* macros.
    x86, xen-swiotlb: Make Xen-SWIOTLB use IOMMU_INIT_* macros.
    x86, swiotlb: Make SWIOTLB use IOMMU_INIT_* macros.
    x86, swiotlb: Simplify SWIOTLB pci_swiotlb_detect routine.
    x86, iommu: Add proper dependency sort routine (and sanity check).
    x86, iommu: Make all IOMMU's detection routines return a value.
    x86, iommu: Add IOMMU_INIT macros, .iommu_table section, and iommu_table_entry structure

    Linus Torvalds
     

12 Oct, 2010

4 commits

27 Aug, 2010

1 commit

  • 480125ba4   x86, iommu: Make all IOMMU's detection routines return a value. ... Browse Code »

    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
    CC: "Jon D. Mason"
    CC: "Darrick J. Wong"
    CC: Jesse Barnes
    CC: David Woodhouse
    CC: Chris Wright
    CC: Yinghai Lu
    CC: Joerg Roedel
    CC: H. Peter Anvin
    CC: Fujita Tomonori
    Signed-off-by: Konrad Rzeszutek Wilk
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Konrad Rzeszutek Wilk
     

09 Dec, 2009

1 commit

10 Nov, 2009

1 commit

28 Aug, 2009

1 commit

  • 20f3097bf   intr-remap: generic support for remapping HPET MSIs ... Browse Code »

    Generic support for remapping HPET MSI's by parsing the HPET timer block
    device scope in the ACPI DRHD tables. This is needed for platforms
    supporting interrupt-remapping and MSI capable HPET timer block.

    Signed-off-by: Suresh Siddha
    Cc: David Woodhouse
    Cc: Jesse Barnes
    Cc: Venkatesh Pallipadi
    Cc: Jay Fenlason
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Suresh Siddha
     

24 Jun, 2009

1 commit

  • f007e99c8   Intel-IOMMU, intr-remap: source-id checking ... Browse Code »

    To support domain-isolation usages, the platform hardware must be
    capable of uniquely identifying the requestor (source-id) for each
    interrupt message. Without source-id checking for interrupt remapping
    , a rouge guest/VM with assigned devices can launch interrupt attacks
    to bring down anothe guest/VM or the VMM itself.

    This patch adds source-id checking for interrupt remapping, and then
    really isolates interrupts for guests/VMs with assigned devices.

    Because PCI subsystem is not initialized yet when set up IOAPIC
    entries, use read_pci_config_byte to access PCI config space directly.

    Signed-off-by: Weidong Han
    Signed-off-by: David Woodhouse

    Weidong Han
     

23 Jun, 2009

1 commit

  • 687d68098   Merge git://git.infradead.org/~dwmw2/iommu-2.6.31 ... Browse Code »

    * git://git.infradead.org/~dwmw2/iommu-2.6.31:
    intel-iommu: Fix one last ia64 build problem in Pass Through Support
    VT-d: support the device IOTLB
    VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps
    VT-d: add device IOTLB invalidation support
    VT-d: parse ATSR in DMA Remapping Reporting Structure
    PCI: handle Virtual Function ATS enabling
    PCI: support the ATS capability
    intel-iommu: dmar_set_interrupt return error value
    intel-iommu: Tidy up iommu->gcmd handling
    intel-iommu: Fix tiny theoretical race in write-buffer flush.
    intel-iommu: Clean up handling of "caching mode" vs. IOTLB flushing.
    intel-iommu: Clean up handling of "caching mode" vs. context flushing.
    VT-d: fix invalid domain id for KVM context flush
    Fix !CONFIG_DMAR build failure introduced by Intel IOMMU Pass Through Support
    Intel IOMMU Pass Through Support

    Fix up trivial conflicts in drivers/pci/{intel-iommu.c,intr_remapping.c}

    Linus Torvalds
     

18 May, 2009

1 commit

21 Apr, 2009

1 commit

19 Apr, 2009

1 commit

  • 937582382   x86, intr-remap: enable interrupt remapping early ... Browse Code »

    Currently, when x2apic is not enabled, interrupt remapping
    will be enabled in init_dmars(), where it is too late to remap
    ioapic interrupts, that is, ioapic interrupts are really in
    compatibility mode, not remappable mode.

    This patch always enables interrupt remapping before ioapic
    setup, it guarantees all interrupts will be remapped when
    interrupt remapping is enabled. Thus it doesn't need to set
    the compatibility interrupt bit.

    [ Impact: refactor intr-remap init sequence, enable fuller remap mode ]

    Signed-off-by: Suresh Siddha
    Signed-off-by: Weidong Han
    Acked-by: David Woodhouse
    Cc: iommu@lists.linux-foundation.org
    Cc: allen.m.kay@intel.com
    Cc: fenghua.yu@intel.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Weidong Han
     

04 Apr, 2009

3 commits

18 Mar, 2009

3 commits

03 Jan, 2009

1 commit

16 Oct, 2008

1 commit

  • f6dd5c310   dmar: fix using early fixmap mapping for DMAR table parsing ... Browse Code »

    Very early detection of the DMAR tables will setup fixmap mapping. For
    parsing these tables later (while enabling dma and/or interrupt remapping),
    early fixmap mapping shouldn't be used. Fix it by calling table detection
    routines again, which will call generic apci_get_table() for setting up
    the correct mapping.

    Signed-off-by: Yinghai Lu
    Signed-off-by: Suresh Siddha
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

12 Jul, 2008

6 commits

  • 75c46fa61   x64, x2apic/intr-remap: MSI and MSI-X support for interrupt remapping infrastructure ... Browse Code »

    MSI and MSI-X support for interrupt remapping infrastructure.

    MSI address register will be programmed with interrupt-remapping table
    entry(IRTE) index and the IRTE will contain information about the vector,
    cpu destination, etc.

    For MSI-X, all the IRTE's will be consecutively allocated in the table,
    and the address registers will contain the starting index to the block
    and the data register will contain the subindex with in that block.

    This also introduces a new irq_chip for cleaner irq migration (in the process
    context as opposed to the current irq migration in the context of an interrupt.
    interrupt-remapping infrastructure will help us achieve this).

    As MSI is edge triggered, irq migration is a simple atomic update(of vector
    and cpu destination) of IRTE and flushing the hardware cache.

    Signed-off-by: Suresh Siddha
    Cc: akpm@linux-foundation.org
    Cc: arjan@linux.intel.com
    Cc: andi@firstfloor.org
    Cc: ebiederm@xmission.com
    Cc: jbarnes@virtuousgeek.org
    Cc: steiner@sgi.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • 89027d35a   x64, x2apic/intr-remap: IO-APIC support for interrupt-remapping ... Browse Code »

    IO-APIC support in the presence of interrupt-remapping infrastructure.

    IO-APIC RTE will be programmed with interrupt-remapping table entry(IRTE)
    index and the IRTE will contain information about the vector, cpu destination,
    trigger mode etc, which traditionally was present in the IO-APIC RTE.

    Introduce a new irq_chip for cleaner irq migration (in the process
    context as opposed to the current irq migration in the context of an interrupt.
    interrupt-remapping infrastructure will help us achieve this cleanly).

    For edge triggered, irq migration is a simple atomic update(of vector
    and cpu destination) of IRTE and flush the hardware cache.

    For level triggered, we need to modify the io-apic RTE aswell with the update
    vector information, along with modifying IRTE with vector and cpu destination.
    So irq migration for level triggered is little bit more complex compared to
    edge triggered migration. But the good news is, we use the same algorithm
    for level triggered migration as we have today, only difference being,
    we now initiate the irq migration from process context instead of the
    interrupt context.

    In future, when we do a directed EOI (combined with cpu EOI broadcast
    suppression) to the IO-APIC, level triggered irq migration will also be
    as simple as edge triggered migration and we can do the irq migration
    with a simple atomic update to IO-APIC RTE.

    TBD: some tests/changes needed in the presence of fixup_irqs() for
    level triggered irq migration.

    Signed-off-by: Suresh Siddha
    Cc: akpm@linux-foundation.org
    Cc: arjan@linux.intel.com
    Cc: andi@firstfloor.org
    Cc: ebiederm@xmission.com
    Cc: jbarnes@virtuousgeek.org
    Cc: steiner@sgi.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • b6fcb33ad   x64, x2apic/intr-remap: routines managing Interrupt remapping table entries. ... Browse Code »

    Routines handling the management of interrupt remapping table entries.

    Signed-off-by: Suresh Siddha
    Cc: akpm@linux-foundation.org
    Cc: arjan@linux.intel.com
    Cc: andi@firstfloor.org
    Cc: ebiederm@xmission.com
    Cc: jbarnes@virtuousgeek.org
    Cc: steiner@sgi.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • 2ae210106   x64, x2apic/intr-remap: Interrupt remapping infrastructure ... Browse Code »

    Interrupt remapping (part of Intel Virtualization Tech for directed I/O)
    infrastructure.

    Signed-off-by: Suresh Siddha
    Cc: akpm@linux-foundation.org
    Cc: arjan@linux.intel.com
    Cc: andi@firstfloor.org
    Cc: ebiederm@xmission.com
    Cc: jbarnes@virtuousgeek.org
    Cc: steiner@sgi.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • ad3ad3f6a   x64, x2apic/intr-remap: parse ioapic scope under vt-d structures ... Browse Code »

    Parse the vt-d device scope structures to find the mapping between IO-APICs
    and the interrupt remapping hardware units.

    This will be used later for enabling Interrupt-remapping for IOAPIC devices.

    Signed-off-by: Suresh Siddha
    Cc: akpm@linux-foundation.org
    Cc: arjan@linux.intel.com
    Cc: andi@firstfloor.org
    Cc: ebiederm@xmission.com
    Cc: jbarnes@virtuousgeek.org
    Cc: steiner@sgi.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     
  • 1886e8a90   x64, x2apic/intr-remap: code re-structuring, to be used by both DMA and Interrupt remapping ... Browse Code »

    Allocate the iommu during the parse of DMA remapping hardware
    definition structures. And also, introduce routines for device
    scope initialization which will be explicitly called during
    dma-remapping initialization.

    These will be used for enabling interrupt remapping separately from the
    existing DMA-remapping enabling sequence.

    Signed-off-by: Suresh Siddha
    Cc: akpm@linux-foundation.org
    Cc: arjan@linux.intel.com
    Cc: andi@firstfloor.org
    Cc: ebiederm@xmission.com
    Cc: jbarnes@virtuousgeek.org
    Cc: steiner@sgi.com
    Signed-off-by: Ingo Molnar

    Suresh Siddha
     

09 Feb, 2008

1 commit

  • d94afc6cc   intel-iommu: fault_reason index cleanup ... Browse Code »

    Fix an off by one bug in the fault reason string reporting function, and
    clean up some of the code around this buglet.

    [akpm@linux-foundation.org: cleanup]
    Signed-off-by: mark gross
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    mark gross
     

22 Oct, 2007

3 commits

  • 3460a6d9c   Intel IOMMU: DMAR fault handling support ... Browse Code »

    MSI interrupt handler registrations and fault handling support for Intel-IOMMU
    hadrware.

    This patch enables the MSI interrupts for the DMA remapping units and in the
    interrupt handler read the fault cause and outputs the same on to the console.

    Signed-off-by: Anil S Keshavamurthy
    Cc: Andi Kleen
    Cc: Peter Zijlstra
    Cc: Muli Ben-Yehuda
    Cc: "Siddha, Suresh B"
    Cc: Arjan van de Ven
    Cc: Ashok Raj
    Cc: "David S. Miller"
    Cc: Christoph Lameter
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Keshavamurthy, Anil S
     
  • ba3959276   Intel IOMMU: Intel IOMMU driver ... Browse Code »

    Actual intel IOMMU driver. Hardware spec can be found at:
    http://www.intel.com/technology/virtualization

    This driver sets X86_64 'dma_ops', so hook into standard DMA APIs. In this
    way, PCI driver will get virtual DMA address. This change is transparent to
    PCI drivers.

    [akpm@linux-foundation.org: remove unneeded cast]
    [akpm@linux-foundation.org: build fix]
    [bunk@stusta.de: fix duplicate CONFIG_DMAR Makefile line]
    Signed-off-by: Anil S Keshavamurthy
    Cc: Andi Kleen
    Cc: Peter Zijlstra
    Cc: Muli Ben-Yehuda
    Cc: "Siddha, Suresh B"
    Cc: Arjan van de Ven
    Cc: Ashok Raj
    Cc: "David S. Miller"
    Cc: Christoph Lameter
    Cc: Greg KH
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Keshavamurthy, Anil S
     
  • 10e5247f4   Intel IOMMU: DMAR detection and parsing logic ... Browse Code »

    This patch supports the upcomming Intel IOMMU hardware a.k.a. Intel(R)
    Virtualization Technology for Directed I/O Architecture and the hardware spec
    for the same can be found here
    http://www.intel.com/technology/virtualization/index.htm

    FAQ! (questions from akpm, answers from ak)

    > So... what's all this code for?
    >
    > I assume that the intent here is to speed things up under Xen, etc?

    Yes in some cases, but not this code. That would be the Xen version of this
    code that could potentially assign whole devices to guests. I expect this to
    be only useful in some special cases though because most hardware is not
    virtualizable and you typically want an own instance for each guest.

    Ok at some point KVM might implement this too; i likely would use this code
    for this.

    > Do we
    > have any benchmark results to help us to decide whether a merge would be
    > justified?

    The main advantage for doing it in the normal kernel is not performance, but
    more safety. Broken devices won't be able to corrupt memory by doing random
    DMA.

    Unfortunately that doesn't work for graphics yet, for that need user space
    interfaces for the X server are needed.

    There are some potential performance benefits too:

    - When you have a device that cannot address the complete address range an
    IOMMU can remap its memory instead of bounce buffering. Remapping is likely
    cheaper than copying.

    - The IOMMU can merge sg lists into a single virtual block. This could
    potentially speed up SG IO when the device is slow walking SG lists. [I
    long ago benchmarked 5% on some block benchmark with an old MPT Fusion; but
    it probably depends a lot on the HBA]

    And you get better driver debugging because unexpected memory accesses from
    the devices will cause a trappable event.

    >
    > Does it slow anything down?

    It adds more overhead to each IO so yes.

    This patch:

    Add support for early detection and parsing of DMAR's (DMA Remapping) reported
    to OS via ACPI tables.

    DMA remapping(DMAR) devices support enables independent address translations
    for Direct Memory Access(DMA) from Devices. These DMA remapping devices are
    reported via ACPI tables and includes pci device scope covered by these DMA
    remapping device.

    For detailed info on the specification of "Intel(R) Virtualization Technology
    for Directed I/O Architecture" please see
    http://www.intel.com/technology/virtualization/index.htm

    Signed-off-by: Anil S Keshavamurthy
    Cc: Andi Kleen
    Cc: Peter Zijlstra
    Cc: Muli Ben-Yehuda
    Cc: "Siddha, Suresh B"
    Cc: Arjan van de Ven
    Cc: Ashok Raj
    Cc: "David S. Miller"
    Cc: Christoph Lameter
    Cc: Greg KH
    Cc: Len Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Keshavamurthy, Anil S