FreeBSD-current/Xen doesn't function with more than one CPU configured. How-To-Repeat: Run freebsd-current/xen with more than one virtual CPU.
Author: adrian Date: Sat May 30 08:53:13 2009 New Revision: 193085 URL: http://svn.freebsd.org/changeset/base/193085 Log: Make ipi_cpu() function as intended. IPI's in Xen are implemented through hypervisor event channels. The MP code creates a pair of IRQs for each base IPI per CPU (one for IPI function dispatch calls, one for IPI bitmap dispatch calls.) Using PCPU_GET() was returning the IRQ of the IPI handler for the current CPU; thus calls to ipi_cpu() were sending itself a message. Instead, looking up the IPI in the target CPU ipi-to-irq map is needed. Note: This doesn't fix Xen SMP (far from it!) but it at least sends IPI's to the right places. Next - sending IPIs.. PR: 135069 Modified: head/sys/xen/evtchn/evtchn.c Modified: head/sys/xen/evtchn/evtchn.c ============================================================================== --- head/sys/xen/evtchn/evtchn.c Sat May 30 07:33:32 2009 (r193084) +++ head/sys/xen/evtchn/evtchn.c Sat May 30 08:53:13 2009 (r193085) @@ -225,12 +225,15 @@ evtchn_do_upcall(struct trapframe *frame } } +/* + * Send an IPI from the current CPU to the destination CPU. + */ void ipi_pcpu(unsigned int cpu, int vector) { int irq; - irq = PCPU_GET(ipi_to_irq[vector]); + irq = pcpu_find(cpu)->pc_ipi_to_irq[vector]; notify_remote_via_irq(irq); } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Author: adrian Date: Sun May 31 08:11:39 2009 New Revision: 193154 URL: http://svn.freebsd.org/changeset/base/193154 Log: Fix the MP IPI code to differentiate between bitmapped IPIs and function IPIs. This attempts to fix the IPI handling code to correctly differentiate between bitmapped IPIs and function IPIs. The Xen IPIs were on low numbers which clashed with the bitmapped IPIs. This commit bumps those IPI numbers up to 240 and above (just like in the i386 code) and fiddles with the ipi_vectors[] logic to call the correct function. This still isn't "right". Specifically, the IPI code may work fine for TLB shootdown events but the rendezvous/lazypmap IPIs are thrown by calling ipi_*() routines which don't set the call_func stuff (function id, addr1, addr2) that the TLB shootdown events are. So the Xen SMP support is still broken. PR: 135069 Modified: head/sys/i386/include/apicvar.h head/sys/i386/xen/mp_machdep.c Modified: head/sys/i386/include/apicvar.h ============================================================================== --- head/sys/i386/include/apicvar.h Sun May 31 07:25:24 2009 (r193153) +++ head/sys/i386/include/apicvar.h Sun May 31 08:11:39 2009 (r193154) @@ -114,14 +114,14 @@ #define APIC_IPI_INTS (APIC_LOCAL_INTS + 2) #ifdef XEN -#define IPI_RENDEZVOUS (2) /* Inter-CPU rendezvous. */ -#define IPI_INVLTLB (3) /* TLB Shootdown IPIs */ -#define IPI_INVLPG (4) -#define IPI_INVLRNG (5) -#define IPI_INVLCACHE (6) -#define IPI_LAZYPMAP (7) /* Lazy pmap release. */ +#define IPI_RENDEZVOUS (APIC_IPI_INTS) /* Inter-CPU rendezvous. */ +#define IPI_INVLTLB (APIC_IPI_INTS + 1) /* TLB Shootdown IPIs */ +#define IPI_INVLPG (APIC_IPI_INTS + 2) +#define IPI_INVLRNG (APIC_IPI_INTS + 3) +#define IPI_INVLCACHE (APIC_IPI_INTS + 4) +#define IPI_LAZYPMAP (APIC_IPI_INTS + 5) /* Lazy pmap release. */ /* Vector to handle bitmap based IPIs */ -#define IPI_BITMAP_VECTOR (8) +#define IPI_BITMAP_VECTOR (APIC_IPI_INTS + 6) #else #define IPI_RENDEZVOUS (APIC_IPI_INTS) /* Inter-CPU rendezvous. */ Modified: head/sys/i386/xen/mp_machdep.c ============================================================================== --- head/sys/i386/xen/mp_machdep.c Sun May 31 07:25:24 2009 (r193153) +++ head/sys/i386/xen/mp_machdep.c Sun May 31 08:11:39 2009 (r193154) @@ -350,17 +350,11 @@ iv_lazypmap(uintptr_t a, uintptr_t b) atomic_add_int(&smp_tlb_wait, 1); } - -static void -iv_noop(uintptr_t a, uintptr_t b) -{ - atomic_add_int(&smp_tlb_wait, 1); -} - -static call_data_func_t *ipi_vectors[IPI_BITMAP_VECTOR] = +/* + * These start from "IPI offset" APIC_IPI_INTS + */ +static call_data_func_t *ipi_vectors[6] = { - iv_noop, - iv_noop, iv_rendezvous, iv_invltlb, iv_invlpg, @@ -419,10 +413,11 @@ smp_call_function_interrupt(void *unused atomic_t *started = &call_data->started; atomic_t *finished = &call_data->finished; - if (call_data->func_id > IPI_BITMAP_VECTOR) + /* We only handle function IPIs, not bitmap IPIs */ + if (call_data->func_id < APIC_IPI_INTS || call_data->func_id > IPI_BITMAP_VECTOR) panic("invalid function id %u", call_data->func_id); - func = ipi_vectors[call_data->func_id]; + func = ipi_vectors[call_data->func_id - APIC_IPI_INTS]; /* * Notify initiating CPU that I've grabbed the data and am * about to execute the function _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Responsible Changed From-To: freebsd-bugs->freebsd-emulation Over to maintainer(s).
Responsible Changed From-To: freebsd-emulation->freebsd-xen more specific assignment.
State Changed From-To: open->patched committed in head (r193154)
The i386 Xen PV port is broken and unmaintained, closing the issue.