1. 17 12月, 2008 1 次提交
  2. 08 12月, 2008 1 次提交
    • Y
      sparse irq_desc[] array: core kernel and x86 changes · 0b8f1efa
      Yinghai Lu 提交于
      Impact: new feature
      
      Problem on distro kernels: irq_desc[NR_IRQS] takes megabytes of RAM with
      NR_CPUS set to large values. The goal is to be able to scale up to much
      larger NR_IRQS value without impacting the (important) common case.
      
      To solve this, we generalize irq_desc[NR_IRQS] to an (optional) array of
      irq_desc pointers.
      
      When CONFIG_SPARSE_IRQ=y is used, we use kzalloc_node to get irq_desc,
      this also makes the IRQ descriptors NUMA-local (to the site that calls
      request_irq()).
      
      This gets rid of the irq_cfg[] static array on x86 as well: irq_cfg now
      uses desc->chip_data for x86 to store irq_cfg.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b8f1efa
  3. 16 10月, 2008 7 次提交
  4. 15 10月, 2008 1 次提交
  5. 12 7月, 2008 5 次提交
    • S
      x64, x2apic/intr-remap: MSI and MSI-X support for interrupt remapping infrastructure · 75c46fa6
      Suresh Siddha 提交于
      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: NSuresh Siddha <suresh.b.siddha@intel.com>
      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: NIngo Molnar <mingo@elte.hu>
      75c46fa6
    • S
      x64, x2apic/intr-remap: IO-APIC support for interrupt-remapping · 89027d35
      Suresh Siddha 提交于
      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: NSuresh Siddha <suresh.b.siddha@intel.com>
      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: NIngo Molnar <mingo@elte.hu>
      89027d35
    • S
      x64, x2apic/intr-remap: routines managing Interrupt remapping table entries. · b6fcb33a
      Suresh Siddha 提交于
      Routines handling the management of interrupt remapping table entries.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      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: NIngo Molnar <mingo@elte.hu>
      b6fcb33a
    • S
      x64, x2apic/intr-remap: Interrupt remapping infrastructure · 2ae21010
      Suresh Siddha 提交于
      Interrupt remapping (part of Intel Virtualization Tech for directed I/O)
      infrastructure.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      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: NIngo Molnar <mingo@elte.hu>
      2ae21010
    • S
      x64, x2apic/intr-remap: parse ioapic scope under vt-d structures · ad3ad3f6
      Suresh Siddha 提交于
      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: NSuresh Siddha <suresh.b.siddha@intel.com>
      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: NIngo Molnar <mingo@elte.hu>
      ad3ad3f6