[RFC PATCH 13/17] x86: allow the irq-vector translation to be determined outside of ioapic

2009-03-31 Thread Gregory Haskins
The ioapic code currently privately manages the mapping between irq
and vector.  This results in some layering violations as the support
for certain MSI operations need this info.  As a result, the MSI
code itself was moved to the ioapic module.  This is not really
optimal.

We now have another need to gain access to the vector assignment on
x86.  However, rather than put yet another inappropriately placed
function into io-apic, lets create a way to export this simple data
and therefore allow the logic to sit closer to where it belongs.

Ideally we should abstract the entire notion of irq-vector management
out of io-apic, but we leave that as an excercise for another day.

Signed-off-by: Gregory Haskins ghask...@novell.com
---

 arch/x86/include/asm/irq.h |6 ++
 arch/x86/kernel/io_apic.c  |   25 +
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/irq.h b/arch/x86/include/asm/irq.h
index 592688e..b1726d8 100644
--- a/arch/x86/include/asm/irq.h
+++ b/arch/x86/include/asm/irq.h
@@ -40,6 +40,12 @@ extern unsigned int do_IRQ(struct pt_regs *regs);
 extern void init_IRQ(void);
 extern void native_init_IRQ(void);
 
+#ifdef CONFIG_SMP
+extern int set_irq_affinity(int irq, cpumask_t mask);
+#endif
+
+extern int irq_to_vector(int irq);
+
 /* Interrupt vector management */
 extern DECLARE_BITMAP(used_vectors, NR_VECTORS);
 extern int vector_used_by_percpu_irq(unsigned int vector);
diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
index bc7ac4d..86a2c36 100644
--- a/arch/x86/kernel/io_apic.c
+++ b/arch/x86/kernel/io_apic.c
@@ -614,6 +614,14 @@ set_ioapic_affinity_irq(unsigned int irq, const struct 
cpumask *mask)
 
set_ioapic_affinity_irq_desc(desc, mask);
 }
+
+int set_irq_affinity(int irq, cpumask_t mask)
+{
+   set_ioapic_affinity_irq(irq, mask);
+
+   return 0;
+}
+
 #endif /* CONFIG_SMP */
 
 /*
@@ -3249,6 +3257,23 @@ void destroy_irq(unsigned int irq)
spin_unlock_irqrestore(vector_lock, flags);
 }
 
+int irq_to_vector(int irq)
+{
+   struct irq_cfg *cfg;
+   unsigned long flags;
+   int ret = -ENOENT;
+
+   spin_lock_irqsave(vector_lock, flags);
+
+   cfg = irq_cfg(irq);
+   if (cfg  cfg-vector != 0)
+   ret = cfg-vector;
+
+   spin_unlock_irqrestore(vector_lock, flags);
+
+   return ret;
+}
+
 /*
  * MSI message composition
  */

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH 13/17] x86: allow the irq-vector translation to be determined outside of ioapic

2009-03-31 Thread Alan Cox
On Tue, 31 Mar 2009 14:43:55 -0400
Gregory Haskins ghask...@novell.com wrote:

 The ioapic code currently privately manages the mapping between irq
 and vector.  This results in some layering violations as the support
 for certain MSI operations need this info.  As a result, the MSI
 code itself was moved to the ioapic module.  This is not really
 optimal.

This appears to have been muddled in with the vnet patches ?
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH 13/17] x86: allow the irq-vector translation to be determined outside of ioapic

2009-03-31 Thread Gregory Haskins
Alan Cox wrote:
 On Tue, 31 Mar 2009 14:43:55 -0400
 Gregory Haskins ghask...@novell.com wrote:

   
 The ioapic code currently privately manages the mapping between irq
 and vector.  This results in some layering violations as the support
 for certain MSI operations need this info.  As a result, the MSI
 code itself was moved to the ioapic module.  This is not really
 optimal.
 

 This appears to have been muddled in with the vnet patches ?
   
Its needed for the kvm-connector patches later in the series, so it was
included intentionally.

On that topic, I probably should have had a TOC of some kind.  Hmm..let
me hack one together now:

Patch 1: Stand-alone shared-memory signal construct, used by various
components in vbus/venet
Patches 2-5: Basic vbus infrastructure
Patches 6-7: IOQ construct, similar to virtio-ring.  Used to overlay
ring-like behavior over the shm interface in vbus
Patches 8-12: virtual-ethernet front and backends
Patch 13: io-apic work to expose the irq-vector in x86, needed for
dynirq support
Patches 14-16: KVM host side support
Patch 17: KVM guest side support

Sorry for the confusion :(

Regards,
-Greg



signature.asc
Description: OpenPGP digital signature