[LINUX,v5] xen: event channel arrays are xen_ulong_t and not unsigned long

Commit Message

Ian Campbell March 5, 2013, 9:29 a.m. UTC

On Tue, 2013-03-05 at 08:08 +0000, Will Deacon wrote:
> Cheers Rob, that was enough to reproduce for me. The problem is likely that
> CONFIG_AEABI=n, so the ABI doesn't actually mandate even base registers for
> 64-bit values in registers.

Me too.

> Ian -- this would be fixed if you used our atomic64 routines instead of
> inventing your own :)

I looked and couldn't see an existing 64 bit xchg, was I looking in the
wrong place? Ah, wait, I see atomic64_xchg now. But that needs an
atomic64_t while I have a xen_ulong_t (which == 64 bits on ARM). This is
a kernel<->hypervisor ABI so I can't just change it to an atomic64_t. I
suppose I could cast (see below, untested) but that seems rather icky.

Ian.

Comments

Will Deacon March 7, 2013, 3:17 a.m. UTC | #1

Hi Ian,

On Tue, Mar 05, 2013 at 09:29:57AM +0000, Ian Campbell wrote:
> On Tue, 2013-03-05 at 08:08 +0000, Will Deacon wrote:
> > Cheers Rob, that was enough to reproduce for me. The problem is likely that
> > CONFIG_AEABI=n, so the ABI doesn't actually mandate even base registers for
> > 64-bit values in registers.
> 
> Me too.
> 
> > Ian -- this would be fixed if you used our atomic64 routines instead of
> > inventing your own :)
> 
> I looked and couldn't see an existing 64 bit xchg, was I looking in the
> wrong place? Ah, wait, I see atomic64_xchg now. But that needs an
> atomic64_t while I have a xen_ulong_t (which == 64 bits on ARM). This is
> a kernel<->hypervisor ABI so I can't just change it to an atomic64_t. I
> suppose I could cast (see below, untested) but that seems rather icky.

You can play some container_of tricks, like we do in cmpxchg64 to get this
right. Alternatively, we could look at an xchg8 implementation which some
other architectures have (although they seem to be 64-bit machines).

Will

Ian Campbell March 7, 2013, 7:17 a.m. UTC | #2

On Thu, 2013-03-07 at 03:17 +0000, Will Deacon wrote:
> > I looked and couldn't see an existing 64 bit xchg, was I looking in the
> > wrong place? Ah, wait, I see atomic64_xchg now. But that needs an
> > atomic64_t while I have a xen_ulong_t (which == 64 bits on ARM). This is
> > a kernel<->hypervisor ABI so I can't just change it to an atomic64_t. I
> > suppose I could cast (see below, untested) but that seems rather icky.
> 
> You can play some container_of tricks, like we do in cmpxchg64 to get this
> right. Alternatively, we could look at an xchg8 implementation which some
> other architectures have (although they seem to be 64-bit machines).

I went with the container of trick + appropriate Kconfig depends and
sent a patch out a couple of seconds ago.

Thanks for your help/advice!

Ian.

Patch

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 0e1f59e..e86a1b3 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -2,6 +2,7 @@ 
 #define _ASM_ARM_XEN_EVENTS_H
 
 #include <asm/ptrace.h>
+#include <asm/atomic.h>
 
 enum ipi_vector {
 	XEN_PLACEHOLDER_VECTOR,
@@ -15,27 +16,6 @@  static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
-/*
- * We cannot use xchg because it does not support 8-byte
- * values. However it is safe to use {ldr,dtd}exd directly because all
- * platforms which Xen can run on support those instructions.
- */
-static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
-{
-	xen_ulong_t oldval;
-	unsigned int tmp;
-
-	smp_wmb();
-	asm volatile("@ xchg_xen_ulong\n"
-		"1:     ldrexd  %0, %H0, [%3]\n"
-		"       strexd  %1, %2, %H2, [%3]\n"
-		"       teq     %1, #0\n"
-		"       bne     1b"
-		: "=&r" (oldval), "=&r" (tmp)
-		: "r" (val), "r" (ptr)
-		: "memory", "cc");
-	smp_wmb();
-	return oldval;
-}
+#define xchg_xen_ulong(ptr, val) atomic64_xchg((atomic64_t *)(ptr), (val))
 
 #endif /* _ASM_ARM_XEN_EVENTS_H */