Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1296804 > unrolled thread

[PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

Back to article view | Back to linux.kernel

Contents

  [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build  dependencies for XEN Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-12-22 15:20 +0100
    Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64  build dependencies for XEN Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-12-22 15:50 +0100
      Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64  build dependencies for XEN Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-12-22 16:50 +0100
        Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64  build dependencies for XEN Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-12-22 17:00 +0100
          Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64  build dependencies for XEN Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-12-22 17:10 +0100

#1296804 — [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

Hello Russell,

Would you please consider this patch for the next merge window? It
is a very old patch (March 2014) which has been left over.

See some of the original threads here:

http://marc.info/?l=linux-arm-kernel&m=138920414402610&w=2
http://marc.info/?l=linux-arm-kernel&m=139031200118436&w=2

Many thanks,

Stefano

---

Remove !GENERIC_ATOMIC64 build dependency:
- introduce xen_atomic64_xchg
- use it to implement xchg_xen_ulong

Remove !CPU_V6 build dependency:
- introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
  CONFIG_CPU_V6
- implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
CC: arnd@arndb.de
CC: will.deacon@arm.com
CC: catalin.marinas@arm.com
CC: linux-arm-kernel@lists.infradead.org
CC: linux-kernel@vger.kernel.org
CC: xen-devel@lists.xenproject.org

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 34e1569..e09ed94 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1807,8 +1807,7 @@ config XEN_DOM0
 config XEN
 	bool "Xen guest support on ARM"
 	depends on ARM && AEABI && OF
-	depends on CPU_V7 && !CPU_V6
-	depends on !GENERIC_ATOMIC64
+	depends on CPU_V7
 	depends on MMU
 	select ARCH_DMA_ADDR_T_64BIT
 	select ARM_PSCI
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index 97882f9..3b342ec 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -152,6 +152,44 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
  * cmpxchg only support 32-bits operands on ARMv6.
  */
 
+static inline unsigned long __cmpxchg8(volatile void *ptr, unsigned long old,
+				      unsigned long new)
+{
+	unsigned long oldval, res;
+
+	do {
+		asm volatile("@ __cmpxchg8\n"
+		"	ldrexb	%1, [%2]\n"
+		"	mov	%0, #0\n"
+		"	teq	%1, %3\n"
+		"	strexbeq %0, %4, [%2]\n"
+			: "=&r" (res), "=&r" (oldval)
+			: "r" (ptr), "Ir" (old), "r" (new)
+			: "memory", "cc");
+	} while (res);
+
+	return oldval;
+}
+
+static inline unsigned long __cmpxchg16(volatile void *ptr, unsigned long old,
+				      unsigned long new)
+{
+	unsigned long oldval, res;
+
+	do {
+		asm volatile("@ __cmpxchg16\n"
+		"	ldrexh	%1, [%2]\n"
+		"	mov	%0, #0\n"
+		"	teq	%1, %3\n"
+		"	strexheq %0, %4, [%2]\n"
+			: "=&r" (res), "=&r" (oldval)
+			: "r" (ptr), "Ir" (old), "r" (new)
+			: "memory", "cc");
+	} while (res);
+
+	return oldval;
+}
+
 static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 				      unsigned long new, int size)
 {
@@ -162,28 +200,10 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 	switch (size) {
 #ifndef CONFIG_CPU_V6	/* min ARCH >= ARMv6K */
 	case 1:
-		do {
-			asm volatile("@ __cmpxchg1\n"
-			"	ldrexb	%1, [%2]\n"
-			"	mov	%0, #0\n"
-			"	teq	%1, %3\n"
-			"	strexbeq %0, %4, [%2]\n"
-				: "=&r" (res), "=&r" (oldval)
-				: "r" (ptr), "Ir" (old), "r" (new)
-				: "memory", "cc");
-		} while (res);
+		oldval = __cmpxchg8(ptr, old, new);
 		break;
 	case 2:
-		do {
-			asm volatile("@ __cmpxchg1\n"
-			"	ldrexh	%1, [%2]\n"
-			"	mov	%0, #0\n"
-			"	teq	%1, %3\n"
-			"	strexheq %0, %4, [%2]\n"
-				: "=&r" (res), "=&r" (oldval)
-				: "r" (ptr), "Ir" (old), "r" (new)
-				: "memory", "cc");
-		} while (res);
+		oldval = __cmpxchg16(ptr, old, new);
 		break;
 #endif
 	case 4:
diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
index 9732b8e..4103319 100644
--- a/arch/arm/include/asm/sync_bitops.h
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -20,7 +20,29 @@
 #define sync_test_and_clear_bit(nr, p)	_test_and_clear_bit(nr, p)
 #define sync_test_and_change_bit(nr, p)	_test_and_change_bit(nr, p)
 #define sync_test_bit(nr, addr)		test_bit(nr, addr)
-#define sync_cmpxchg			cmpxchg
 
+static inline unsigned long sync_cmpxchg(volatile void *ptr,
+										 unsigned long old,
+										 unsigned long new)
+{
+	unsigned long oldval;
+	int size = sizeof(*(ptr));
+
+	smp_mb();
+	switch (size) {
+	case 1:
+		oldval = __cmpxchg8(ptr, old, new);
+		break;
+	case 2:
+		oldval = __cmpxchg16(ptr, old, new);
+		break;
+	default:
+		oldval = __cmpxchg(ptr, old, new, size);
+		break;
+	}
+	smp_mb();
+
+	return oldval;
+}
 
 #endif
diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 71e473d..f646422 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -16,7 +16,37 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
 	return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
-#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr),	\
+#ifdef CONFIG_GENERIC_ATOMIC64
+/* if CONFIG_GENERIC_ATOMIC64 is defined we cannot use the generic
+ * atomic64_xchg function because it is implemented using spin locks.
+ * Here we need proper atomic instructions to read and write memory
+ * shared with the hypervisor.
+ */
+static inline u64 xen_atomic64_xchg(atomic64_t *ptr, u64 new)
+{
+	u64 result;
+	unsigned long tmp;
+
+	smp_mb();
+
+	__asm__ __volatile__("@ xen_atomic64_xchg\n"
+"1:	ldrexd	%0, %H0, [%3]\n"
+"	strexd	%1, %4, %H4, [%3]\n"
+"	teq	%1, #0\n"
+"	bne	1b"
+	: "=&r" (result), "=&r" (tmp), "+Qo" (ptr->counter)
+	: "r" (&ptr->counter), "r" (new)
+	: "cc");
+
+	smp_mb();
+
+	return result;
+}
+#else
+#define xen_atomic64_xchg atomic64_xchg
+#endif
+
+#define xchg_xen_ulong(ptr, val) xen_atomic64_xchg(container_of((ptr),	\
 							    atomic64_t,	\
 							    counter), (val))
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1296813 — Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

On Tue, Dec 22, 2015 at 02:17:17PM +0000, Stefano Stabellini wrote:
> Hello Russell,
> 
> Would you please consider this patch for the next merge window? It
> is a very old patch (March 2014) which has been left over.

This patch has some obvious problems...

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 34e1569..e09ed94 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1807,8 +1807,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM"
>  	depends on ARM && AEABI && OF
> -	depends on CPU_V7 && !CPU_V6
> -	depends on !GENERIC_ATOMIC64
> +	depends on CPU_V7

How sure are we that this won't cause regressions?  How much testing
has been done with these changed dependencies?

> diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
> index 9732b8e..4103319 100644
> --- a/arch/arm/include/asm/sync_bitops.h
> +++ b/arch/arm/include/asm/sync_bitops.h
> @@ -20,7 +20,29 @@
>  #define sync_test_and_clear_bit(nr, p)	_test_and_clear_bit(nr, p)
>  #define sync_test_and_change_bit(nr, p)	_test_and_change_bit(nr, p)
>  #define sync_test_bit(nr, addr)		test_bit(nr, addr)
> -#define sync_cmpxchg			cmpxchg
>  
> +static inline unsigned long sync_cmpxchg(volatile void *ptr,
> +										 unsigned long old,
> +										 unsigned long new)
> +{
> +	unsigned long oldval;
> +	int size = sizeof(*(ptr));

This is buggy.  You're doing sizeof(void) here, which on GCC will always
be 1:

   A consequence of this is that `sizeof' is also allowed on `void' and
  on function types, and returns 1.

> +
> +	smp_mb();
> +	switch (size) {
> +	case 1:
> +		oldval = __cmpxchg8(ptr, old, new);
> +		break;
> +	case 2:
> +		oldval = __cmpxchg16(ptr, old, new);
> +		break;

The ldrexb/ldrexh instructions are not available on ARMv6 CPUs.  __xchg()
and friends avoided these for ARMv6 CPUs, but this does not.

I'd expect anything that uses sync_cmpxchg() will fail to build when a
kernel including ARMv6 is attempted.

So... I don't think this patch is ready.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296857 — Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 02:17:17PM +0000, Stefano Stabellini wrote:
> > Hello Russell,
> > 
> > Would you please consider this patch for the next merge window? It
> > is a very old patch (March 2014) which has been left over.
> 
> This patch has some obvious problems...
> 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 34e1569..e09ed94 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1807,8 +1807,7 @@ config XEN_DOM0
> >  config XEN
> >  	bool "Xen guest support on ARM"
> >  	depends on ARM && AEABI && OF
> > -	depends on CPU_V7 && !CPU_V6
> > -	depends on !GENERIC_ATOMIC64
> > +	depends on CPU_V7
> 
> How sure are we that this won't cause regressions?  How much testing
> has been done with these changed dependencies?

I did build-test a range of combinations of those options, sorry for not
spotting the error below.


> > diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
> > index 9732b8e..4103319 100644
> > --- a/arch/arm/include/asm/sync_bitops.h
> > +++ b/arch/arm/include/asm/sync_bitops.h
> > @@ -20,7 +20,29 @@
> >  #define sync_test_and_clear_bit(nr, p)	_test_and_clear_bit(nr, p)
> >  #define sync_test_and_change_bit(nr, p)	_test_and_change_bit(nr, p)
> >  #define sync_test_bit(nr, addr)		test_bit(nr, addr)
> > -#define sync_cmpxchg			cmpxchg
> >  
> > +static inline unsigned long sync_cmpxchg(volatile void *ptr,
> > +										 unsigned long old,
> > +										 unsigned long new)
> > +{
> > +	unsigned long oldval;
> > +	int size = sizeof(*(ptr));
> 
> This is buggy.  You're doing sizeof(void) here, which on GCC will always
> be 1:
> 
>    A consequence of this is that `sizeof' is also allowed on `void' and
>   on function types, and returns 1.

You are right, thank you very much for looking at the patch and finding
this bug. I think the issue can be solved with something like:

+#define sync_cmpxchg(ptr, o, n) ({					\
+	(__typeof(*ptr))__sync_cmpxchg((ptr),				\
+				        (unsigned long)(o),		\
+				        (unsigned long)(n),		\
+				        sizeof(*(ptr)));		\
+})
 
+static inline unsigned long __sync_cmpxchg(volatile void *ptr,
+										 unsigned long old,
+										 unsigned long new,
+										 int size)
+{


> > +
> > +	smp_mb();
> > +	switch (size) {
> > +	case 1:
> > +		oldval = __cmpxchg8(ptr, old, new);
> > +		break;
> > +	case 2:
> > +		oldval = __cmpxchg16(ptr, old, new);
> > +		break;
> 
> The ldrexb/ldrexh instructions are not available on ARMv6 CPUs.  __xchg()
> and friends avoided these for ARMv6 CPUs, but this does not.
> 
> I'd expect anything that uses sync_cmpxchg() will fail to build when a
> kernel including ARMv6 is attempted.

The code builds, but of course it could not actually run on CPU_V6. But
the use case for me is building drivers/xen/grant-table.c, which can
only run on CPU_V7 anyway, so it is not a problem.

Is that acceptable for you? If not, do you have any other suggestions?


> So... I don't think this patch is ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296865 — Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

On Tue, Dec 22, 2015 at 03:45:19PM +0000, Stefano Stabellini wrote:
> The code builds, but of course it could not actually run on CPU_V6. But
> the use case for me is building drivers/xen/grant-table.c, which can
> only run on CPU_V7 anyway, so it is not a problem.

What I'm concerned about in this case is if you try to use instructions
which are not supported by the CPU, even in assembly, the assembler
will barf.

So, if we're building an ARMv6 + ARMv7 kernel, and you try to use
LDREXB in generic code, even though you may intend it to only be
executed on ARMv7, the assembler will error out.

We used to be able to work around that by passing -Wa,-march=armv7
to the compiler for specific files, which would then tell the assembler
to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops
which override the command line.  So now the only way to do it is to
override the assemblers selected archtecture using .arch pseudo-ops
in the assembly code.

So, what I'm saying is that dropping the !ARMv6 dependency is not as
simple as it would seem, and I'm nervous about including any such
patches this close to Christmas and the merge window.

I've recently been through a run of "apply this patch, no it's wrong,
drop it, apply the next version, no it's still wrong, drop it again."
So, today is the last day I'm accepting _known_ good patches into my
tree for the 4.5 merge window.  This is not yet a known good patch
because it hasn't been through several iterations of testing - and I
don't want to be adding and removing patches from my tree over
Christmas.

I'd rather leave my tree in a known good state before Christmas so
that those who want to fiddle with the kernel over the holiday break
can do so without having the hassle of trees containing partially
tested patches.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296870 — Re: [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 03:45:19PM +0000, Stefano Stabellini wrote:
> > The code builds, but of course it could not actually run on CPU_V6. But
> > the use case for me is building drivers/xen/grant-table.c, which can
> > only run on CPU_V7 anyway, so it is not a problem.
> 
> What I'm concerned about in this case is if you try to use instructions
> which are not supported by the CPU, even in assembly, the assembler
> will barf.
> 
> So, if we're building an ARMv6 + ARMv7 kernel, and you try to use
> LDREXB in generic code, even though you may intend it to only be
> executed on ARMv7, the assembler will error out.
> 
> We used to be able to work around that by passing -Wa,-march=armv7
> to the compiler for specific files, which would then tell the assembler
> to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops
> which override the command line.  So now the only way to do it is to
> override the assemblers selected archtecture using .arch pseudo-ops
> in the assembly code.
> 
> So, what I'm saying is that dropping the !ARMv6 dependency is not as
> simple as it would seem, and I'm nervous about including any such
> patches this close to Christmas and the merge window.
 
Sure, that's understandable.

Merge window aside, do you think that for the future it might be better
to change approach and write a Xen specific implementation of
sync_cmpxchg?  Like this older patch tried to do

http://marc.info/?l=linux-arm-kernel&m=138436406724990&w=2

?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web