Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Thu, 2013-03-07 at 03:17 +, 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Hi Ian, On Tue, Mar 05, 2013 at 09:29:57AM +, Ian Campbell wrote: > On Tue, 2013-03-05 at 08:08 +, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Hi Ian, On Tue, Mar 05, 2013 at 09:29:57AM +, Ian Campbell wrote: On Tue, 2013-03-05 at 08:08 +, 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Thu, 2013-03-07 at 03:17 +, 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, Mar 05, 2013 at 03:56:41AM +, Ian Campbell wrote:
> > > diff --git a/arch/arm/include/asm/xen/events.h
> > > b/arch/arm/include/asm/xen/events.h
> > > index 94b4e90..5c27696 100644
> > > --- a/arch/arm/include/asm/xen/events.h
> > > +++ b/arch/arm/include/asm/xen/events.h
> > > @@ -15,4 +15,26 @@ 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.
> >
> > Why does atomic64_cmpxchg not work here?
>
> Just that we don't want/need the cmp aspect, we don't mind if an extra
> bit gets set as we read the value, so long as we atomically read and set
> to zero.
>
> > > + */
> > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t
> > > val)
> > > +{
> > > + xen_ulong_t oldval;
> > > + unsigned int tmp;
> > > +
> > > + wmb();
> >
> > Based on atomic64_cmpxchg implementation, you could use smp_mb here
> > which avoids an outer cache flush.
>
> Good point.
>
> > > + asm volatile("@ xchg_xen_ulong\n"
> > > + "1: ldrexd %0, %H0, [%3]\n"
> > > + " strexd %1, %2, %H2, [%3]\n"
> > > + " teq %1, #0\n"
> > > + " bne 1b"
> > > + : "=" (oldval), "=" (tmp)
> > > + : "r" (val), "r" (ptr)
> > > + : "memory", "cc");
> >
> > And a smp_mb is needed here.
>
> I think for the specific caller which we have here it isn't strictly
> necessary, but for generic correctness I think you are right.
>
> Thanks for reviewing.
>
> Konrad, IIRC you have already picked this up (and sent to Linus?) so an
Yes.
> incremental fix is required? See below.
Why don't I wait a bit and wait until you are back from conferences and
can post a nice series that fixes the smp_wmb() and also the atomic one
and has been run-time tested with Xen on ARM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, 2013-03-05 at 08:08 +, 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.
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
+#include
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"
- : "=" (oldval), "=" (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 */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, Mar 05, 2013 at 06:55:46AM +, Rob Herring wrote: > > I also can't immediately see why GCC would allocate oldval to an odd base > > register. Can you share your .config please? > > > > Here's a config: [...] 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. Ian -- this would be fixed if you used our atomic64 routines instead of inventing your own :) Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, Mar 05, 2013 at 06:55:46AM +, Rob Herring wrote: I also can't immediately see why GCC would allocate oldval to an odd base register. Can you share your .config please? Here's a config: [...] 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. Ian -- this would be fixed if you used our atomic64 routines instead of inventing your own :) Will -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, 2013-03-05 at 08:08 +, 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.
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 */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, Mar 05, 2013 at 03:56:41AM +, Ian Campbell wrote:
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ 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.
Why does atomic64_cmpxchg not work here?
Just that we don't want/need the cmp aspect, we don't mind if an extra
bit gets set as we read the value, so long as we atomically read and set
to zero.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t
val)
+{
+ xen_ulong_t oldval;
+ unsigned int tmp;
+
+ wmb();
Based on atomic64_cmpxchg implementation, you could use smp_mb here
which avoids an outer cache flush.
Good point.
+ 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);
And a smp_mb is needed here.
I think for the specific caller which we have here it isn't strictly
necessary, but for generic correctness I think you are right.
Thanks for reviewing.
Konrad, IIRC you have already picked this up (and sent to Linus?) so an
Yes.
incremental fix is required? See below.
Why don't I wait a bit and wait until you are back from conferences and
can post a nice series that fixes the smp_wmb() and also the atomic one
and has been run-time tested with Xen on ARM.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, 2013-03-05 at 06:55 +, Rob Herring wrote: > Here's a config: Was it truncated? oldconfig is asking a ton of questions, far more than I would expect for something like variance between our HEADs etc. If I just answer the default to all the questions then I get a .config with Xen on etc, but I still don't see the issue. Ian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On 03/04/2013 09:04 PM, Will Deacon wrote:
> Hi guys,
>
> On Mon, Mar 04, 2013 at 02:45:33AM +, Rob Herring wrote:
>> On 02/20/2013 05:48 AM, Ian Campbell wrote:
>>> On ARM we want these to be the same size on 32- and 64-bit.
>>>
>>> This is an ABI change on ARM. X86 does not change.
>>>
>>> Signed-off-by: Ian Campbell
>>> Cc: Jan Beulich
>>> Cc: Keir (Xen.org)
>>> Cc: Tim Deegan
>>> Cc: Stefano Stabellini
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: xen-de...@lists.xen.org
>>> Cc: Konrad Rzeszutek Wilk
>
> [...]
>
>> I'm seeing some some build failures on randconfig builds with this change:
>>
>> /tmp/ccJaIZOW.s: Assembler messages:
>> /tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'
>>
>> This is with ubuntu 12.04 cross compiler (gcc version 4.6.3
>> (Ubuntu/Linaro 4.6.3-1ubuntu5)).
>>
>> This register restriction is on ARM, but not Thumb builds. Comparing
>> this to atomic64_cmpxchg, I don't see how to fix this. Perhaps Will or
>> Nico have thoughts.
>
> [...]
>
>>> + asm volatile("@ xchg_xen_ulong\n"
>>> + "1: ldrexd %0, %H0, [%3]\n"
>>> + " strexd %1, %2, %H2, [%3]\n"
>>> + " teq %1, #0\n"
>>> + " bne 1b"
>>> + : "=" (oldval), "=" (tmp)
>>> + : "r" (val), "r" (ptr)
>>> + : "memory", "cc");
>
> I also can't immediately see why GCC would allocate oldval to an odd base
> register. Can you share your .config please?
>
Here's a config:
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_FHANDLE=y
CONFIG_IKCONFIG=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MEMCG=y
CONFIG_MEMCG_KMEM=y
CONFIG_MEMCG_DEBUG_ASYNC_DESTROY=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_BASE_FULL is not set
# CONFIG_EPOLL is not set
# CONFIG_TIMERFD is not set
# CONFIG_SHMEM is not set
# CONFIG_AIO is not set
CONFIG_EMBEDDED=y
# CONFIG_PERF_EVENTS is not set
CONFIG_PROFILING=y
# CONFIG_BLOCK is not set
CONFIG_ARCH_BCM=y
CONFIG_GPIO_PCA953X=y
CONFIG_ARCH_MXC=y
CONFIG_MACH_IMX51_DT=y
CONFIG_MACH_EUKREA_CPUIMX51SD=y
CONFIG_SOC_IMX53=y
CONFIG_ARCH_SOCFPGA=y
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_CPU_ICACHE_DISABLE=y
CONFIG_CPU_DCACHE_DISABLE=y
CONFIG_ARM_ERRATA_430973=y
CONFIG_PL310_ERRATA_727915=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
# CONFIG_COMPACTION is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y
CONFIG_XEN=y
# CONFIG_ATAGS is not set
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_FPE_FASTFPE=y
# CONFIG_BINFMT_ELF is not set
CONFIG_PM_AUTOSLEEP=y
CONFIG_PM_RUNTIME=y
CONFIG_PM_DEBUG=y
CONFIG_APM_EMULATION=y
CONFIG_NET=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_NET_KEY=y
CONFIG_NETWORK_PHY_TIMESTAMPING=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_DECNET_NF_GRABULATOR=y
CONFIG_ATM=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_VLAN_8021Q=y
CONFIG_DECNET=y
CONFIG_DECNET_ROUTER=y
CONFIG_LLC2=y
CONFIG_ATALK=y
CONFIG_DEV_APPLETALK=y
CONFIG_LAPB=y
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_ATM=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_MULTIQ=y
CONFIG_NET_SCH_SFB=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_CHOKE=y
CONFIG_NET_SCH_QFQ=y
CONFIG_NET_SCH_CODEL=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_U32=y
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_SKBEDIT=y
CONFIG_NET_CLS_IND=y
CONFIG_DCB=y
CONFIG_VSOCKETS=y
CONFIG_BT=y
CONFIG_BT_BNEP=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_ATH3K=y
CONFIG_BT_HCIUART_LL=y
CONFIG_BT_HCIBPA10X=y
CONFIG_BT_HCIBFUSB=y
# CONFIG_WIRELESS is not set
CONFIG_WIMAX=y
CONFIG_RFKILL_REGULATOR=y
CONFIG_CAIF=y
CONFIG_CAIF_DEBUG=y
CONFIG_DEVTMPFS=y
# CONFIG_STANDALONE is not set
# CONFIG_FW_LOADER_USER_HELPER is not set
CONFIG_DEBUG_DRIVER=y
CONFIG_CONNECTOR=y
# CONFIG_PROC_EVENTS is not set
CONFIG_ATMEL_PWM=y
CONFIG_ENCLOSURE_SERVICES=y
CONFIG_ISL29003=y
CONFIG_SENSORS_BH1770=y
CONFIG_ARM_CHARLCD=y
CONFIG_BMP085_I2C=y
CONFIG_USB_SWITCH_FSA9480=y
CONFIG_EEPROM_AT24=y
CONFIG_TI_ST=y
CONFIG_ALTERA_STAPL=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_IFB=y
CONFIG_MACVLAN=y
CONFIG_NETCONSOLE=y
CONFIG_VIRTIO_NET=y
CONFIG_CAIF_HSI=y
CONFIG_NET_DSA_MV88E6060=y
# CONFIG_ETHERNET is not set
CONFIG_AMD_PHY=y
CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
CONFIG_QSEMI_PHY=y
CONFIG_VITESSE_PHY=y
CONFIG_BCM87XX_PHY=y
CONFIG_ICPLUS_PHY=y
CONFIG_REALTEK_PHY=y
CONFIG_NATIONAL_PHY=y
CONFIG_LSI_ET1011C_PHY=y
CONFIG_FIXED_PHY=y
CONFIG_PPP=y
CONFIG_PPP_BSDCOMP=y
CONFIG_PPP_DEFLATE=y
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
> > diff --git a/arch/arm/include/asm/xen/events.h
> > b/arch/arm/include/asm/xen/events.h
> > index 94b4e90..5c27696 100644
> > --- a/arch/arm/include/asm/xen/events.h
> > +++ b/arch/arm/include/asm/xen/events.h
> > @@ -15,4 +15,26 @@ 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.
>
> Why does atomic64_cmpxchg not work here?
Just that we don't want/need the cmp aspect, we don't mind if an extra
bit gets set as we read the value, so long as we atomically read and set
to zero.
> > + */
> > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > +{
> > + xen_ulong_t oldval;
> > + unsigned int tmp;
> > +
> > + wmb();
>
> Based on atomic64_cmpxchg implementation, you could use smp_mb here
> which avoids an outer cache flush.
Good point.
> > + asm volatile("@ xchg_xen_ulong\n"
> > + "1: ldrexd %0, %H0, [%3]\n"
> > + " strexd %1, %2, %H2, [%3]\n"
> > + " teq %1, #0\n"
> > + " bne 1b"
> > + : "=" (oldval), "=" (tmp)
> > + : "r" (val), "r" (ptr)
> > + : "memory", "cc");
>
> And a smp_mb is needed here.
I think for the specific caller which we have here it isn't strictly
necessary, but for generic correctness I think you are right.
Thanks for reviewing.
Konrad, IIRC you have already picked this up (and sent to Linus?) so an
incremental fix is required? See below.
Ian.
8<
>From 4ed928274dad4c3ed610e769b2ae11eb2d1ea433 Mon Sep 17 00:00:00 2001
From: Ian Campbell
Date: Tue, 5 Mar 2013 03:37:23 +
Subject: [PATCH] arm: xen: correct barriers in xchg_xen_ulong
We can use an smp_wmb rather than a wmb here and we also need one after the
exchange. Spotted by Rob Herring.
Signed-off-by: Ian Campbell
---
arch/arm/include/asm/xen/events.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 5c27696..0e1f59e 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -25,7 +25,7 @@ static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr,
xen_ulong_t val)
xen_ulong_t oldval;
unsigned int tmp;
- wmb();
+ smp_wmb();
asm volatile("@ xchg_xen_ulong\n"
"1: ldrexd %0, %H0, [%3]\n"
" strexd %1, %2, %H2, [%3]\n"
@@ -34,6 +34,7 @@ static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr,
xen_ulong_t val)
: "=" (oldval), "=" (tmp)
: "r" (val), "r" (ptr)
: "memory", "cc");
+ smp_wmb();
return oldval;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, 2013-03-05 at 03:04 +, Will Deacon wrote:
> Hi guys,
>
> On Mon, Mar 04, 2013 at 02:45:33AM +, Rob Herring wrote:
> > On 02/20/2013 05:48 AM, Ian Campbell wrote:
> > > On ARM we want these to be the same size on 32- and 64-bit.
> > >
> > > This is an ABI change on ARM. X86 does not change.
> > >
> > > Signed-off-by: Ian Campbell
> > > Cc: Jan Beulich
> > > Cc: Keir (Xen.org)
> > > Cc: Tim Deegan
> > > Cc: Stefano Stabellini
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: xen-de...@lists.xen.org
> > > Cc: Konrad Rzeszutek Wilk
>
> [...]
>
> > I'm seeing some some build failures on randconfig builds with this change:
> >
> > /tmp/ccJaIZOW.s: Assembler messages:
> > /tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'
> >
> > This is with ubuntu 12.04 cross compiler (gcc version 4.6.3
> > (Ubuntu/Linaro 4.6.3-1ubuntu5)).
> >
> > This register restriction is on ARM, but not Thumb builds. Comparing
> > this to atomic64_cmpxchg, I don't see how to fix this. Perhaps Will or
> > Nico have thoughts.
>
> [...]
>
> > > + asm volatile("@ xchg_xen_ulong\n"
> > > + "1: ldrexd %0, %H0, [%3]\n"
> > > + " strexd %1, %2, %H2, [%3]\n"
> > > + " teq %1, #0\n"
> > > + " bne 1b"
> > > + : "=" (oldval), "=" (tmp)
> > > + : "r" (val), "r" (ptr)
> > > + : "memory", "cc");
>
> I also can't immediately see why GCC would allocate oldval to an odd base
> register. Can you share your .config please?
I fixed something along these lines before v5 of this patch, although I
must confess I don't recall what it was that I changed (and looking at
the older versions of the patch isn't giving me any clues). I can't
reproduce it now though :-(
I'm using the 4.6.3 cross compiler from kernel.org:
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Hi guys,
On Mon, Mar 04, 2013 at 02:45:33AM +, Rob Herring wrote:
> On 02/20/2013 05:48 AM, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> >
> > This is an ABI change on ARM. X86 does not change.
> >
> > Signed-off-by: Ian Campbell
> > Cc: Jan Beulich
> > Cc: Keir (Xen.org)
> > Cc: Tim Deegan
> > Cc: Stefano Stabellini
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: xen-de...@lists.xen.org
> > Cc: Konrad Rzeszutek Wilk
[...]
> I'm seeing some some build failures on randconfig builds with this change:
>
> /tmp/ccJaIZOW.s: Assembler messages:
> /tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'
>
> This is with ubuntu 12.04 cross compiler (gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5)).
>
> This register restriction is on ARM, but not Thumb builds. Comparing
> this to atomic64_cmpxchg, I don't see how to fix this. Perhaps Will or
> Nico have thoughts.
[...]
> > + asm volatile("@ xchg_xen_ulong\n"
> > + "1: ldrexd %0, %H0, [%3]\n"
> > + " strexd %1, %2, %H2, [%3]\n"
> > + " teq %1, #0\n"
> > + " bne 1b"
> > + : "=" (oldval), "=" (tmp)
> > + : "r" (val), "r" (ptr)
> > + : "memory", "cc");
I also can't immediately see why GCC would allocate oldval to an odd base
register. Can you share your .config please?
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Hi guys, On Mon, Mar 04, 2013 at 02:45:33AM +, Rob Herring wrote: On 02/20/2013 05:48 AM, Ian Campbell wrote: On ARM we want these to be the same size on 32- and 64-bit. This is an ABI change on ARM. X86 does not change. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir (Xen.org) k...@xen.org Cc: Tim Deegan t...@xen.org Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: linux-arm-ker...@lists.infradead.org Cc: xen-de...@lists.xen.org Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com [...] I'm seeing some some build failures on randconfig builds with this change: /tmp/ccJaIZOW.s: Assembler messages: /tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]' This is with ubuntu 12.04 cross compiler (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)). This register restriction is on ARM, but not Thumb builds. Comparing this to atomic64_cmpxchg, I don't see how to fix this. Perhaps Will or Nico have thoughts. [...] + 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); I also can't immediately see why GCC would allocate oldval to an odd base register. Can you share your .config please? Will -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, 2013-03-05 at 03:04 +, Will Deacon wrote: Hi guys, On Mon, Mar 04, 2013 at 02:45:33AM +, Rob Herring wrote: On 02/20/2013 05:48 AM, Ian Campbell wrote: On ARM we want these to be the same size on 32- and 64-bit. This is an ABI change on ARM. X86 does not change. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir (Xen.org) k...@xen.org Cc: Tim Deegan t...@xen.org Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: linux-arm-ker...@lists.infradead.org Cc: xen-de...@lists.xen.org Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com [...] I'm seeing some some build failures on randconfig builds with this change: /tmp/ccJaIZOW.s: Assembler messages: /tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]' This is with ubuntu 12.04 cross compiler (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)). This register restriction is on ARM, but not Thumb builds. Comparing this to atomic64_cmpxchg, I don't see how to fix this. Perhaps Will or Nico have thoughts. [...] + 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); I also can't immediately see why GCC would allocate oldval to an odd base register. Can you share your .config please? I fixed something along these lines before v5 of this patch, although I must confess I don't recall what it was that I changed (and looking at the older versions of the patch isn't giving me any clues). I can't reproduce it now though :-( I'm using the 4.6.3 cross compiler from kernel.org: ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/ Ian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ 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.
Why does atomic64_cmpxchg not work here?
Just that we don't want/need the cmp aspect, we don't mind if an extra
bit gets set as we read the value, so long as we atomically read and set
to zero.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+ xen_ulong_t oldval;
+ unsigned int tmp;
+
+ wmb();
Based on atomic64_cmpxchg implementation, you could use smp_mb here
which avoids an outer cache flush.
Good point.
+ 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);
And a smp_mb is needed here.
I think for the specific caller which we have here it isn't strictly
necessary, but for generic correctness I think you are right.
Thanks for reviewing.
Konrad, IIRC you have already picked this up (and sent to Linus?) so an
incremental fix is required? See below.
Ian.
8
From 4ed928274dad4c3ed610e769b2ae11eb2d1ea433 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@hellion.org.uk
Date: Tue, 5 Mar 2013 03:37:23 +
Subject: [PATCH] arm: xen: correct barriers in xchg_xen_ulong
We can use an smp_wmb rather than a wmb here and we also need one after the
exchange. Spotted by Rob Herring.
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/include/asm/xen/events.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 5c27696..0e1f59e 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -25,7 +25,7 @@ static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr,
xen_ulong_t val)
xen_ulong_t oldval;
unsigned int tmp;
- wmb();
+ smp_wmb();
asm volatile(@ xchg_xen_ulong\n
1: ldrexd %0, %H0, [%3]\n
strexd %1, %2, %H2, [%3]\n
@@ -34,6 +34,7 @@ static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr,
xen_ulong_t val)
: =r (oldval), =r (tmp)
: r (val), r (ptr)
: memory, cc);
+ smp_wmb();
return oldval;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On 03/04/2013 09:04 PM, Will Deacon wrote: Hi guys, On Mon, Mar 04, 2013 at 02:45:33AM +, Rob Herring wrote: On 02/20/2013 05:48 AM, Ian Campbell wrote: On ARM we want these to be the same size on 32- and 64-bit. This is an ABI change on ARM. X86 does not change. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir (Xen.org) k...@xen.org Cc: Tim Deegan t...@xen.org Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: linux-arm-ker...@lists.infradead.org Cc: xen-de...@lists.xen.org Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com [...] I'm seeing some some build failures on randconfig builds with this change: /tmp/ccJaIZOW.s: Assembler messages: /tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]' This is with ubuntu 12.04 cross compiler (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)). This register restriction is on ARM, but not Thumb builds. Comparing this to atomic64_cmpxchg, I don't see how to fix this. Perhaps Will or Nico have thoughts. [...] + 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); I also can't immediately see why GCC would allocate oldval to an odd base register. Can you share your .config please? Here's a config: CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_FHANDLE=y CONFIG_IKCONFIG=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y CONFIG_MEMCG_KMEM=y CONFIG_MEMCG_DEBUG_ASYNC_DESTROY=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_UIDGID_STRICT_TYPE_CHECKS=y CONFIG_SCHED_AUTOGROUP=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set # CONFIG_BASE_FULL is not set # CONFIG_EPOLL is not set # CONFIG_TIMERFD is not set # CONFIG_SHMEM is not set # CONFIG_AIO is not set CONFIG_EMBEDDED=y # CONFIG_PERF_EVENTS is not set CONFIG_PROFILING=y # CONFIG_BLOCK is not set CONFIG_ARCH_BCM=y CONFIG_GPIO_PCA953X=y CONFIG_ARCH_MXC=y CONFIG_MACH_IMX51_DT=y CONFIG_MACH_EUKREA_CPUIMX51SD=y CONFIG_SOC_IMX53=y CONFIG_ARCH_SOCFPGA=y CONFIG_ARCH_SUNXI=y CONFIG_ARCH_VEXPRESS_CA9X4=y CONFIG_CPU_ICACHE_DISABLE=y CONFIG_CPU_DCACHE_DISABLE=y CONFIG_ARM_ERRATA_430973=y CONFIG_PL310_ERRATA_727915=y CONFIG_HAVE_ARM_ARCH_TIMER=y # CONFIG_COMPACTION is not set # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR=y CONFIG_XEN=y # CONFIG_ATAGS is not set CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_FPE_FASTFPE=y # CONFIG_BINFMT_ELF is not set CONFIG_PM_AUTOSLEEP=y CONFIG_PM_RUNTIME=y CONFIG_PM_DEBUG=y CONFIG_APM_EMULATION=y CONFIG_NET=y CONFIG_XFRM_SUB_POLICY=y CONFIG_XFRM_MIGRATE=y CONFIG_NET_KEY=y CONFIG_NETWORK_PHY_TIMESTAMPING=y CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_DECNET_NF_GRABULATOR=y CONFIG_ATM=y CONFIG_BRIDGE=y CONFIG_BRIDGE_VLAN_FILTERING=y CONFIG_VLAN_8021Q=y CONFIG_DECNET=y CONFIG_DECNET_ROUTER=y CONFIG_LLC2=y CONFIG_ATALK=y CONFIG_DEV_APPLETALK=y CONFIG_LAPB=y CONFIG_NET_SCHED=y CONFIG_NET_SCH_HTB=y CONFIG_NET_SCH_HFSC=y CONFIG_NET_SCH_ATM=y CONFIG_NET_SCH_PRIO=y CONFIG_NET_SCH_MULTIQ=y CONFIG_NET_SCH_SFB=y CONFIG_NET_SCH_TBF=y CONFIG_NET_SCH_GRED=y CONFIG_NET_SCH_NETEM=y CONFIG_NET_SCH_CHOKE=y CONFIG_NET_SCH_QFQ=y CONFIG_NET_SCH_CODEL=y CONFIG_NET_CLS_TCINDEX=y CONFIG_NET_CLS_U32=y CONFIG_NET_CLS_RSVP=y CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_SKBEDIT=y CONFIG_NET_CLS_IND=y CONFIG_DCB=y CONFIG_VSOCKETS=y CONFIG_BT=y CONFIG_BT_BNEP=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HCIUART=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_ATH3K=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBPA10X=y CONFIG_BT_HCIBFUSB=y # CONFIG_WIRELESS is not set CONFIG_WIMAX=y CONFIG_RFKILL_REGULATOR=y CONFIG_CAIF=y CONFIG_CAIF_DEBUG=y CONFIG_DEVTMPFS=y # CONFIG_STANDALONE is not set # CONFIG_FW_LOADER_USER_HELPER is not set CONFIG_DEBUG_DRIVER=y CONFIG_CONNECTOR=y # CONFIG_PROC_EVENTS is not set CONFIG_ATMEL_PWM=y CONFIG_ENCLOSURE_SERVICES=y CONFIG_ISL29003=y CONFIG_SENSORS_BH1770=y CONFIG_ARM_CHARLCD=y CONFIG_BMP085_I2C=y CONFIG_USB_SWITCH_FSA9480=y CONFIG_EEPROM_AT24=y CONFIG_TI_ST=y CONFIG_ALTERA_STAPL=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y CONFIG_IFB=y CONFIG_MACVLAN=y CONFIG_NETCONSOLE=y CONFIG_VIRTIO_NET=y CONFIG_CAIF_HSI=y CONFIG_NET_DSA_MV88E6060=y # CONFIG_ETHERNET is not set CONFIG_AMD_PHY=y CONFIG_MARVELL_PHY=y CONFIG_DAVICOM_PHY=y CONFIG_QSEMI_PHY=y CONFIG_VITESSE_PHY=y CONFIG_BCM87XX_PHY=y CONFIG_ICPLUS_PHY=y CONFIG_REALTEK_PHY=y CONFIG_NATIONAL_PHY=y CONFIG_LSI_ET1011C_PHY=y CONFIG_FIXED_PHY=y CONFIG_PPP=y CONFIG_PPP_BSDCOMP=y CONFIG_PPP_DEFLATE=y
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Tue, 2013-03-05 at 06:55 +, Rob Herring wrote: Here's a config: Was it truncated? oldconfig is asking a ton of questions, far more than I would expect for something like variance between our HEADs etc. If I just answer the default to all the questions then I get a .config with Xen on etc, but I still don't see the issue. Ian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On 02/20/2013 05:48 AM, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
>
> This is an ABI change on ARM. X86 does not change.
>
> Signed-off-by: Ian Campbell
> Cc: Jan Beulich
> Cc: Keir (Xen.org)
> Cc: Tim Deegan
> Cc: Stefano Stabellini
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: xen-de...@lists.xen.org
> Cc: Konrad Rzeszutek Wilk
> ---
> Changes since V4
> Rebase onto v3.8
> Fix wording of comment
> Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
> sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
> Changes since V3
> s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
> Add comments about the correct bitops to use, and on the ordering/barrier
> requirements on xchg_xen_ulong.
> Changes since V1
> use find_first_set not __ffs
> fix some more unsigned long -> xen_ulong_t
> use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
> arch/arm/include/asm/xen/events.h | 22 +++
> arch/x86/include/asm/xen/events.h |3 +
> drivers/xen/events.c | 115 +---
> include/xen/interface/xen.h |8 +-
> 4 files changed, 96 insertions(+), 52 deletions(-)
>
I'm seeing some some build failures on randconfig builds with this change:
/tmp/ccJaIZOW.s: Assembler messages:
/tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'
This is with ubuntu 12.04 cross compiler (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5)).
This register restriction is on ARM, but not Thumb builds. Comparing
this to atomic64_cmpxchg, I don't see how to fix this. Perhaps Will or
Nico have thoughts.
> diff --git a/arch/arm/include/asm/xen/events.h
> b/arch/arm/include/asm/xen/events.h
> index 94b4e90..5c27696 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ 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.
Why does atomic64_cmpxchg not work here?
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> + xen_ulong_t oldval;
> + unsigned int tmp;
> +
> + wmb();
Based on atomic64_cmpxchg implementation, you could use smp_mb here
which avoids an outer cache flush.
> + asm volatile("@ xchg_xen_ulong\n"
> + "1: ldrexd %0, %H0, [%3]\n"
> + " strexd %1, %2, %H2, [%3]\n"
> + " teq %1, #0\n"
> + " bne 1b"
> + : "=" (oldval), "=" (tmp)
> + : "r" (val), "r" (ptr)
> + : "memory", "cc");
And a smp_mb is needed here.
Rob
> + return oldval;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On 02/20/2013 05:48 AM, Ian Campbell wrote:
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Keir (Xen.org) k...@xen.org
Cc: Tim Deegan t...@xen.org
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Changes since V4
Rebase onto v3.8
Fix wording of comment
Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
Changes since V3
s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
Changes since V2
Add comments about the correct bitops to use, and on the ordering/barrier
requirements on xchg_xen_ulong.
Changes since V1
use find_first_set not __ffs
fix some more unsigned long - xen_ulong_t
use more generic xchg_xen_ulong instead of ...read_evtchn...
---
arch/arm/include/asm/xen/events.h | 22 +++
arch/x86/include/asm/xen/events.h |3 +
drivers/xen/events.c | 115 +---
include/xen/interface/xen.h |8 +-
4 files changed, 96 insertions(+), 52 deletions(-)
I'm seeing some some build failures on randconfig builds with this change:
/tmp/ccJaIZOW.s: Assembler messages:
/tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'
This is with ubuntu 12.04 cross compiler (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5)).
This register restriction is on ARM, but not Thumb builds. Comparing
this to atomic64_cmpxchg, I don't see how to fix this. Perhaps Will or
Nico have thoughts.
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ 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.
Why does atomic64_cmpxchg not work here?
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+ xen_ulong_t oldval;
+ unsigned int tmp;
+
+ wmb();
Based on atomic64_cmpxchg implementation, you could use smp_mb here
which avoids an outer cache flush.
+ 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);
And a smp_mb is needed here.
Rob
+ return oldval;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Wed, 20 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
>
> This is an ABI change on ARM. X86 does not change.
>
> Signed-off-by: Ian Campbell
> Cc: Jan Beulich
> Cc: Keir (Xen.org)
> Cc: Tim Deegan
> Cc: Stefano Stabellini
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: xen-de...@lists.xen.org
> Cc: Konrad Rzeszutek Wilk
Acked-by: Stefano Stabellini
> Changes since V4
> Rebase onto v3.8
> Fix wording of comment
> Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
> sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
> Changes since V3
> s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
> Add comments about the correct bitops to use, and on the ordering/barrier
> requirements on xchg_xen_ulong.
> Changes since V1
> use find_first_set not __ffs
> fix some more unsigned long -> xen_ulong_t
> use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
> arch/arm/include/asm/xen/events.h | 22 +++
> arch/x86/include/asm/xen/events.h |3 +
> drivers/xen/events.c | 115 +---
> include/xen/interface/xen.h |8 +-
> 4 files changed, 96 insertions(+), 52 deletions(-)
>
> diff --git a/arch/arm/include/asm/xen/events.h
> b/arch/arm/include/asm/xen/events.h
> index 94b4e90..5c27696 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ 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"
> + : "=" (oldval), "=" (tmp)
> + : "r" (val), "r" (ptr)
> + : "memory", "cc");
> + return oldval;
> +}
> +
> #endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/x86/include/asm/xen/events.h
> b/arch/x86/include/asm/xen/events.h
> index cc146d5..ca842f2 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> return raw_irqs_disabled_flags(regs->flags);
> }
>
> +/* No need for a barrier -- XCHG is a barrier on x86. */
> +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> +
> #endif /* _ASM_X86_XEN_EVENTS_H */
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 74d77df..dfd62b5 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
> #endif
> static bool (*pirq_needs_eoi)(unsigned irq);
>
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +/*
> + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> + * careful to only use bitops which allow for this (e.g
> + * test_bit/find_first_bit and friends but not __ffs) and to pass
> + * BITS_PER_EVTCHN_WORD as the bitmask length.
> + */
> +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> +/*
> + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> + * array. Primarily to avoid long lines (hence the terse name).
> + */
> +#define BM(x) (unsigned long *)(x)
> +/* Find the first set bit in a evtchn mask */
> +#define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_EVTCHN_WORD)
> +
> +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
> cpu_evtchn_mask);
>
> /* Xen will never allocate port zero for any purpose. */
> @@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
> return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> }
>
> -static inline unsigned long active_evtchns(unsigned int cpu,
> - struct shared_info *sh,
> - unsigned int idx)
> +static inline xen_ulong_t active_evtchns(unsigned int cpu,
> +struct shared_info *sh,
> +unsigned int idx)
> {
> return sh->evtchn_pending[idx] &
> per_cpu(cpu_evtchn_mask, cpu)[idx] &
> @@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned
> int cpu)
> cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
> #endif
>
> - clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
> -
Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On Wed, 20 Feb 2013, Ian Campbell wrote:
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Keir (Xen.org) k...@xen.org
Cc: Tim Deegan t...@xen.org
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Changes since V4
Rebase onto v3.8
Fix wording of comment
Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
Changes since V3
s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
Changes since V2
Add comments about the correct bitops to use, and on the ordering/barrier
requirements on xchg_xen_ulong.
Changes since V1
use find_first_set not __ffs
fix some more unsigned long - xen_ulong_t
use more generic xchg_xen_ulong instead of ...read_evtchn...
---
arch/arm/include/asm/xen/events.h | 22 +++
arch/x86/include/asm/xen/events.h |3 +
drivers/xen/events.c | 115 +---
include/xen/interface/xen.h |8 +-
4 files changed, 96 insertions(+), 52 deletions(-)
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ 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;
+}
+
#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h
b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs-flags);
}
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
#endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 74d77df..dfd62b5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
#endif
static bool (*pirq_needs_eoi)(unsigned irq);
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g
+ * test_bit/find_first_bit and friends but not __ffs) and to pass
+ * BITS_PER_EVTCHN_WORD as the bitmask length.
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+/*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+/* Find the first set bit in a evtchn mask */
+#define EVTCHN_FIRST_BIT(w) find_first_bit(BM((w)), BITS_PER_EVTCHN_WORD)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
cpu_evtchn_mask);
/* Xen will never allocate port zero for any purpose. */
@@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
return info-u.pirq.flags PIRQ_NEEDS_EOI;
}
-static inline unsigned long active_evtchns(unsigned int cpu,
- struct shared_info *sh,
- unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+struct shared_info *sh,
+unsigned int idx)
{
return sh-evtchn_pending[idx]
per_cpu(cpu_evtchn_mask, cpu)[idx]
@@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned
int cpu)
cpumask_copy(irq_to_desc(irq)-irq_data.affinity, cpumask_of(cpu));
#endif
- clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
- set_bit(chn,
[PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell
Cc: Jan Beulich
Cc: Keir (Xen.org)
Cc: Tim Deegan
Cc: Stefano Stabellini
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk
---
Changes since V4
Rebase onto v3.8
Fix wording of comment
Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
Changes since V3
s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
Changes since V2
Add comments about the correct bitops to use, and on the ordering/barrier
requirements on xchg_xen_ulong.
Changes since V1
use find_first_set not __ffs
fix some more unsigned long -> xen_ulong_t
use more generic xchg_xen_ulong instead of ...read_evtchn...
---
arch/arm/include/asm/xen/events.h | 22 +++
arch/x86/include/asm/xen/events.h |3 +
drivers/xen/events.c | 115 +---
include/xen/interface/xen.h |8 +-
4 files changed, 96 insertions(+), 52 deletions(-)
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ 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"
+ : "=" (oldval), "=" (tmp)
+ : "r" (val), "r" (ptr)
+ : "memory", "cc");
+ return oldval;
+}
+
#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h
b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs->flags);
}
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
#endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 74d77df..dfd62b5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
#endif
static bool (*pirq_needs_eoi)(unsigned irq);
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g
+ * test_bit/find_first_bit and friends but not __ffs) and to pass
+ * BITS_PER_EVTCHN_WORD as the bitmask length.
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+/*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+/* Find the first set bit in a evtchn mask */
+#define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_EVTCHN_WORD)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
cpu_evtchn_mask);
/* Xen will never allocate port zero for any purpose. */
@@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
return info->u.pirq.flags & PIRQ_NEEDS_EOI;
}
-static inline unsigned long active_evtchns(unsigned int cpu,
- struct shared_info *sh,
- unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+struct shared_info *sh,
+unsigned int idx)
{
return sh->evtchn_pending[idx] &
per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned
int cpu)
cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
#endif
- clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
- set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+ clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq;
+ set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
info_for_irq(irq)->cpu = cpu;
}
@@ -339,19 +354,19 @@ static void init_evtchn_cpu_bindings(void)
static inline void clear_evtchn(int
[PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Keir (Xen.org) k...@xen.org
Cc: Tim Deegan t...@xen.org
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Changes since V4
Rebase onto v3.8
Fix wording of comment
Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
Changes since V3
s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
Changes since V2
Add comments about the correct bitops to use, and on the ordering/barrier
requirements on xchg_xen_ulong.
Changes since V1
use find_first_set not __ffs
fix some more unsigned long - xen_ulong_t
use more generic xchg_xen_ulong instead of ...read_evtchn...
---
arch/arm/include/asm/xen/events.h | 22 +++
arch/x86/include/asm/xen/events.h |3 +
drivers/xen/events.c | 115 +---
include/xen/interface/xen.h |8 +-
4 files changed, 96 insertions(+), 52 deletions(-)
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 94b4e90..5c27696 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ 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;
+}
+
#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h
b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs-flags);
}
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
#endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 74d77df..dfd62b5 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
#endif
static bool (*pirq_needs_eoi)(unsigned irq);
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+/*
+ * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
+ * careful to only use bitops which allow for this (e.g
+ * test_bit/find_first_bit and friends but not __ffs) and to pass
+ * BITS_PER_EVTCHN_WORD as the bitmask length.
+ */
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+/*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+/* Find the first set bit in a evtchn mask */
+#define EVTCHN_FIRST_BIT(w) find_first_bit(BM((w)), BITS_PER_EVTCHN_WORD)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
cpu_evtchn_mask);
/* Xen will never allocate port zero for any purpose. */
@@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
return info-u.pirq.flags PIRQ_NEEDS_EOI;
}
-static inline unsigned long active_evtchns(unsigned int cpu,
- struct shared_info *sh,
- unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+struct shared_info *sh,
+unsigned int idx)
{
return sh-evtchn_pending[idx]
per_cpu(cpu_evtchn_mask, cpu)[idx]
@@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned
int cpu)
cpumask_copy(irq_to_desc(irq)-irq_data.affinity, cpumask_of(cpu));
#endif
- clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
- set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+ clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq;
+ set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
info_for_irq(irq)-cpu = cpu;
}
@@ -339,19 +354,19
