On Nov 28, 2006, at 3:17 AM, Amos Waterland wrote:
To summarize the situation, I found two problems.
1. Core Xen has a bug (I believe) in which they do not mark their cpu
mask volatile, so the compiler generates an infinite loop in
I will send some patches upstream to resolve this issue.
This was PPc specific bug covered by:
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID a8e67a19c3255a6bbc0aaa5c9e1736f1ddd76f6c
# Parent cc45282daf3d242fdcf6e858c0b18b7f1086a318
cpu_relax() needs to call barrier()
2. Xen/PPC has a problem in that its IPI callbacks (remote function
invocations) do not actually happen in parallel, which breaks the
design of read_clocks. Our IPI callbacks are serialized by the
design we copied from Xen/x86, which is to acquire a per-vector
very early in the EE handling path (see do_external).
I guess my real question is: will Xen/PPC ever in the future run
IPI remote function callbacks with EE enabled? If the plan is to
keep things the way they are now, then we should remove the
per-vector lock entirely.
The lock protects the vector handler which theoretically could be
However we should not be calling the action with the lock held unless
The following is a patch that implements the above two conclusions and
which allows 'C-aC-aC-at' to work properly. Comments?
arch/powerpc/external.c | 2 --
common/keyhandler.c | 2 +-
include/xen/cpumask.h | 2 +-
3 files changed, 2 insertions(+), 4 deletions(-)
diff -r 305751a5281e xen/arch/powerpc/external.c
--- a/xen/arch/powerpc/external.c Wed Nov 22 16:29:25 2006 -0500
+++ b/xen/arch/powerpc/external.c Tue Nov 28 03:07:10 2006 -0500
@@ -86,11 +86,9 @@ void do_external(struct cpu_user_regs *r
/* do_IRQ is fundamentally broken for reliable IPI
irq_desc_t *desc = &irq_desc[vec];
regs->entry_vector = vec;
Please add a:
BUG_ON(!(desc->status & IRQ_PER_CPU));
If you trip this then we will need:
- locking around the desc
- tickle some status bits
- unlock the action
- lock again
- tickle status bits.
Xen-ppc-devel mailing list