From: ebiederm@xmission.com (Eric W. Biederman)
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: mingo@elte.hu, hpa@zytor.com, tglx@linutronix.de,
akpm@linux-foundation.org, arjan@linux.intel.com,
andi@firstfloor.org, ebiederm@xmission.com,
jbarnes@virtuousgeek.org, steiner@sgi.com,
linux-kernel@vger.kernel.org
Subject: Re: [patch 23/26] x64, x2apic/intr-remap: MSI and MSI-X support for interrupt remapping infrastructure
Date: Thu, 10 Jul 2008 18:22:57 -0700 [thread overview]
Message-ID: <m1fxqhdxji.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <20080710182239.205057000@linux-os.sc.intel.com> (Suresh Siddha's message of "Thu, 10 Jul 2008 11:16:57 -0700")
Suresh Siddha <suresh.b.siddha@intel.com> writes:
> 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.
A couple of things. I believe MSI edge triggered irqs can always be migrated
safely outside of irq context.
Flushing the hardware cache sounds like it will flush the irqs towards the cpu.
How do we flush the inflight irqs flushed to the apic. Does a register read work?
For MSI irqs going directly to the cpu it should, as long as the cpu and local
apic count as the same device from the perspective of pci ordering rules.
> Index: tree-x86/arch/x86/kernel/io_apic_64.c
> ===================================================================
> --- tree-x86.orig/arch/x86/kernel/io_apic_64.c 2008-07-10 09:52:31.000000000
> -0700
> +++ tree-x86/arch/x86/kernel/io_apic_64.c 2008-07-10 09:52:34.000000000 -0700
> @@ -2289,6 +2289,9 @@
>
> dynamic_irq_cleanup(irq);
>
> +#ifdef CONFIG_INTR_REMAP
> + free_irte(irq);
> +#endif
> spin_lock_irqsave(&vector_lock, flags);
> __clear_irq_vector(irq);
> spin_unlock_irqrestore(&vector_lock, flags);
> @@ -2307,11 +2310,42 @@
>
> tmp = TARGET_CPUS;
> err = assign_irq_vector(irq, tmp);
> - if (!err) {
> - cpus_and(tmp, cfg->domain, tmp);
> - dest = cpu_mask_to_apicid(tmp);
> + if (err)
> + return err;
> +
> + cpus_and(tmp, cfg->domain, tmp);
> + dest = cpu_mask_to_apicid(tmp);
Can we simplify this a little. In particular have a function
struct IOAPIC_ROUTE_entry x86_map_irq(irq, mask);
Where x86_map_irq would ultimately figure out the path to the cpu.
In the simple case it would just call assign_irq_vector();
When irqs are remapped it would perform the additional
map_irq_to_irte_handle();
modify_irte(irq, &irte);
And then have the generic msi code and the ioapic code.
Map from the struct IOAPIC_ROUTE_entry or whatever to the appropriate bits for the hardware
they control.
That should allows us a lot more flexibility going forward with less code then is in your
patches.
> +#ifdef CONFIG_INTR_REMAP
> + if (irq_remapped(irq)) {
> + struct irte irte;
> + int ir_index;
> + u16 sub_handle;
> +
> + ir_index = map_irq_to_irte_handle(irq, &sub_handle);
> + BUG_ON(ir_index == -1);
> +
> + memset (&irte, 0, sizeof(irte));
> +
> + irte.present = 1;
> + irte.dst_mode = INT_DEST_MODE;
> + irte.trigger_mode = 0; /* edge */
> + irte.dlvry_mode = INT_DELIVERY_MODE;
> + irte.vector = cfg->vector;
> + irte.dest_id = IRTE_DEST(dest);
> +
> + modify_irte(irq, &irte);
>
> msg->address_hi = MSI_ADDR_BASE_HI;
> + msg->data = sub_handle;
> + msg->address_lo = MSI_ADDR_BASE_LO | MSI_ADDR_IR_EXT_INT |
> + MSI_ADDR_IR_SHV |
> + MSI_ADDR_IR_INDEX1(ir_index) |
> + MSI_ADDR_IR_INDEX2(ir_index);
> + } else
> +#endif
> + {
> + msg->address_hi = MSI_ADDR_BASE_HI;
> msg->address_lo =
> MSI_ADDR_BASE_LO |
> ((INT_DEST_MODE == 0) ?
> @@ -2361,6 +2395,55 @@
> write_msi_msg(irq, &msg);
> irq_desc[irq].affinity = mask;
> }
> +
> +#ifdef CONFIG_INTR_REMAP
> +/*
> + * Migrate the MSI irq to another cpumask. This migration is
> + * done in the process context using interrupt-remapping hardware.
> + */
> +static void ir_set_msi_irq_affinity(unsigned int irq, cpumask_t mask)
> +{
> + struct irq_cfg *cfg = irq_cfg + irq;
> + unsigned int dest;
> + cpumask_t tmp, cleanup_mask;
> + struct irte irte;
> +
> + cpus_and(tmp, mask, cpu_online_map);
> + if (cpus_empty(tmp))
> + return;
> +
> + if (get_irte(irq, &irte))
> + return;
> +
> + if (assign_irq_vector(irq, mask))
> + return;
> +
> + cpus_and(tmp, cfg->domain, mask);
> + dest = cpu_mask_to_apicid(tmp);
> +
> + irte.vector = cfg->vector;
> + irte.dest_id = IRTE_DEST(dest);
> +
> + /*
> + * atomically update the IRTE with the new destination and vector.
> + */
> + modify_irte(irq, &irte);
> +
> + /*
> + * After this point, all the interrupts will start arriving
> + * at the new destination. So, time to cleanup the previous
> + * vector allocation.
> + */
> + if (cfg->move_in_progress) {
> + cpus_and(cleanup_mask, cfg->old_domain, cpu_online_map);
> + cfg->move_cleanup_count = cpus_weight(cleanup_mask);
> + send_IPI_mask(cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
> + cfg->move_in_progress = 0;
> + }
> +
> + irq_desc[irq].affinity = mask;
> +}
> +#endif
> #endif /* CONFIG_SMP */
>
> /*
> @@ -2378,26 +2461,157 @@
> .retrigger = ioapic_retrigger_irq,
> };
next prev parent reply other threads:[~2008-07-11 1:32 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 18:16 [patch 00/26] x64, x2apic/intr-remap: Interrupt-remapping and x2apic support Suresh Siddha
2008-07-10 18:16 ` [patch 01/26] x64, x2apic/intr-remap: Intel vt-d, IOMMU code reorganization Suresh Siddha
2008-07-10 18:16 ` [patch 02/26] x64, x2apic/intr-remap: fix the need for sequential array allocation of iommus Suresh Siddha
2008-07-10 18:16 ` [patch 03/26] x64, x2apic/intr-remap: code re-structuring, to be used by both DMA and Interrupt remapping Suresh Siddha
2008-07-10 18:16 ` [patch 04/26] x64, x2apic/intr-remap: use CONFIG_DMAR for DMA-remapping specific code Suresh Siddha
2008-07-10 18:16 ` [patch 05/26] x64, x2apic/intr-remap: Fix the need for RMRR in the DMA-remapping detection Suresh Siddha
2008-07-10 18:16 ` [patch 06/26] x64, x2apic/intr-remap: parse ioapic scope under vt-d structures Suresh Siddha
2008-07-10 18:16 ` [patch 07/26] x64, x2apic/intr-remap: move IOMMU_WAIT_OP() macro to intel-iommu.h Suresh Siddha
2008-07-10 18:16 ` [patch 08/26] x64, x2apic/intr-remap: Queued invalidation infrastructure (part of VT-d) Suresh Siddha
2008-07-10 18:16 ` [patch 09/26] x64, x2apic/intr-remap: Interrupt remapping infrastructure Suresh Siddha
2008-07-10 18:16 ` [patch 10/26] x64, x2apic/intr-remap: routines managing Interrupt remapping table entries Suresh Siddha
2008-07-10 18:16 ` [patch 11/26] x64, x2apic/intr-remap: generic irq migration support from process context Suresh Siddha
2008-07-10 23:08 ` Eric W. Biederman
2008-07-11 5:41 ` Suresh Siddha
2008-07-11 9:19 ` Eric W. Biederman
2008-07-10 18:16 ` [patch 12/26] x64, x2apic/intr-remap: 8259 specific mask/unmask routines Suresh Siddha
2008-07-10 18:16 ` [patch 13/26] x64, x2apic/intr-remap: ioapic routines which deal with initial io-apic RTE setup Suresh Siddha
2008-07-10 18:16 ` [patch 14/26] x64, x2apic/intr-remap: introduce read_apic_id() to genapic routines Suresh Siddha
2008-07-10 18:16 ` [patch 15/26] x64, x2apic/intr-remap: basic apic ops support Suresh Siddha
2008-07-10 18:16 ` [patch 16/26] x64, x2apic/intr-remap: cpuid bits for x2apic feature Suresh Siddha
2008-07-10 18:16 ` [patch 17/26] x64, x2apic/intr-remap: disable DMA-remapping if Interrupt-remapping is detected (temporary quirk) Suresh Siddha
2008-07-10 18:16 ` [patch 18/26] x64, x2apic/intr-remap: x2apic ops for x2apic mode support Suresh Siddha
2008-07-10 18:16 ` [patch 19/26] x64, x2apic/intr-remap: introcude self IPI to genapic routines Suresh Siddha
2008-07-10 23:34 ` Eric W. Biederman
2008-07-11 2:29 ` Mike Travis
2008-07-11 3:50 ` Eric W. Biederman
2008-07-11 13:55 ` Mike Travis
2008-07-10 18:16 ` [patch 20/26] x64, x2apic/intr-remap: x2apic cluster mode support Suresh Siddha
2008-07-10 18:16 ` [patch 21/26] x64, x2apic/intr-remap: setup init_apic_ldr for UV Suresh Siddha
2008-07-11 0:14 ` Andrew Morton
2008-07-11 1:56 ` Suresh Siddha
2008-07-10 18:16 ` [patch 22/26] x64, x2apic/intr-remap: IO-APIC support for interrupt-remapping Suresh Siddha
2008-07-10 18:16 ` [patch 23/26] x64, x2apic/intr-remap: MSI and MSI-X support for interrupt remapping infrastructure Suresh Siddha
2008-07-11 1:22 ` Eric W. Biederman [this message]
2008-07-11 6:07 ` Suresh Siddha
2008-07-11 8:59 ` Eric W. Biederman
2008-07-11 23:07 ` Suresh Siddha
2008-07-11 23:50 ` Eric W. Biederman
2008-07-10 18:16 ` [patch 24/26] x64, x2apic/intr-remap: add x2apic support, including enabling interrupt-remapping Suresh Siddha
2008-07-10 18:16 ` [patch 25/26] x64, x2apic/intr-remap: support for x2apic physical mode support Suresh Siddha
2008-07-10 18:17 ` [patch 26/26] x64, x2apic/intr-remap: introduce CONFIG_INTR_REMAP Suresh Siddha
2008-07-10 23:29 ` Eric W. Biederman
2008-07-10 23:37 ` Yong Wang
2008-07-11 1:50 ` Suresh Siddha
2008-07-11 1:53 ` Eric W. Biederman
2008-07-10 19:53 ` [patch 00/26] x64, x2apic/intr-remap: Interrupt-remapping and x2apic support Ingo Molnar
2008-07-10 20:22 ` Suresh Siddha
2008-07-10 21:56 ` Suresh Siddha
2008-07-11 10:28 ` Ingo Molnar
2008-07-11 20:09 ` Ingo Molnar
2008-07-11 20:31 ` Suresh Siddha
2008-07-11 20:42 ` Yinghai Lu
2008-07-11 20:45 ` Ingo Molnar
2008-07-11 21:24 ` Suresh Siddha
2008-07-11 22:02 ` Yinghai Lu
2008-07-12 3:16 ` Yinghai Lu
2008-07-12 3:52 ` Eric W. Biederman
2008-07-12 6:17 ` Yinghai Lu
2008-07-12 7:02 ` Eric W. Biederman
2008-07-12 7:49 ` Yinghai Lu
2008-07-12 8:11 ` Eric W. Biederman
2008-07-12 8:37 ` Yinghai Lu
2008-07-12 9:46 ` Eric W. Biederman
2008-07-13 1:02 ` Suresh Siddha
2008-07-13 1:01 ` Suresh Siddha
2008-07-13 1:32 ` Suresh Siddha
2008-07-13 1:00 ` Suresh Siddha
2008-07-13 0:55 ` Suresh Siddha
2008-07-12 5:37 ` Ingo Molnar
2008-07-12 6:06 ` Yinghai Lu
2008-07-12 6:45 ` Ingo Molnar
2008-07-11 20:49 ` Ingo Molnar
2008-07-16 14:37 ` Yong Wang
2008-07-16 14:53 ` Ingo Molnar
2008-07-22 20:49 ` Andrew Morton
2008-07-22 21:00 ` Mike Travis
2008-07-22 21:14 ` Andrew Morton
2008-07-24 5:03 ` Ingo Molnar
2008-07-10 20:05 ` Eric W. Biederman
2008-07-10 20:18 ` Ingo Molnar
2008-07-10 21:07 ` Eric W. Biederman
2008-07-10 21:15 ` Suresh Siddha
2008-07-10 22:52 ` Eric W. Biederman
2008-07-11 2:35 ` Suresh Siddha
2008-07-11 3:15 ` Eric W. Biederman
2008-07-10 22:09 ` Arjan van de Ven
2008-07-10 22:54 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1fxqhdxji.fsf@frodo.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arjan@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=steiner@sgi.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox