From mboxrd@z Thu Jan 1 00:00:00 1970 From: konrad.wilk@oracle.com (Konrad Rzeszutek Wilk) Date: Thu, 7 Mar 2013 09:14:45 -0500 Subject: [PATCH] xen: arm: mandate EABI and use generic atomic operations. In-Reply-To: <1362640645-26564-1-git-send-email-ian.campbell@citrix.com> References: <1362640645-26564-1-git-send-email-ian.campbell@citrix.com> Message-ID: <20130307141445.GB14958@phenom.dumpdata.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Mar 07, 2013 at 07:17:25AM +0000, Ian Campbell wrote: > Rob Herring has observed that c81611c4e96f "xen: event channel arrays are > xen_ulong_t and not unsigned long" introduced a compile failure when building > without CONFIG_AEABI: > > /tmp/ccJaIZOW.s: Assembler messages: > /tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]' > > Will Deacon pointed out that this is because OABI does not require even base > registers for 64-bit values. We can avoid this by simply using the existing > atomic64_xchg operation and the same containerof trick as used by the cmpxchg > macros. However since this code is used on memory which is shared with the > hypervisor we require proper atomic instructions and cannot use the generic > atomic64 callbacks (which are based on spinlocks), therefore add a dependency > on !GENERIC_ATOMIC64. Since we already depend on !CPU_V6 there isn't much > downside to this. > > While thinking about this we also observed that OABI has different struct > alignment requirements to EABI, which is a problem for hypercall argument > structs which are shared with the hypervisor and which must be in EABI layout. > Since I don't expect people to want to run OABI kernels on Xen depend on > CONFIG_AEABI explicitly too (although it also happens to be enforced by the > !GENERIC_ATOMIC64 requirement too). > > Signed-off-by: Ian Campbell > Cc: Will Deacon > Cc: Rob Herring > Cc: Stefano Stabellini > Cc: Konrad Rzeszutek Wilk Stefano, I need your Ack before I can put it in my tree for Linus. > --- > arch/arm/Kconfig | 3 ++- > arch/arm/include/asm/xen/events.h | 25 ++++--------------------- > 2 files changed, 6 insertions(+), 22 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 5b71469..be632ba 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1887,8 +1887,9 @@ config XEN_DOM0 > > config XEN > bool "Xen guest support on ARM (EXPERIMENTAL)" > - depends on ARM && OF > + depends on ARM && AEABI && OF > depends on CPU_V7 && !CPU_V6 > + depends on !GENERIC_ATOMIC64 > help > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h > index 5c27696..8b1f37b 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 > +#include > > enum ipi_vector { > XEN_PLACEHOLDER_VECTOR, > @@ -15,26 +16,8 @@ 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; > - > - 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"); > - return oldval; > -} > +#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr), \ > + atomic64_t, \ > + counter), (val)) > > #endif /* _ASM_ARM_XEN_EVENTS_H */ > -- > 1.7.10.4 >