All of lore.kernel.org
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Date: Sun, 03 Mar 2013 20:45:33 -0600	[thread overview]
Message-ID: <51340ACD.70904@gmail.com> (raw)
In-Reply-To: <1361360886-2956-1-git-send-email-ian.campbell@citrix.com>

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.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: xen-devel at lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@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;
> +}

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robherring2@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org, "Keir (Xen.org)" <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Tim Deegan <tim@xen.org>,
	linux-kernel@vger.kernel.org, Jan Beulich <JBeulich@suse.com>,
	linux-arm-kernel@lists.infradead.org,
	Nicolas Pitre <nico@fluxnic.net>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Date: Sun, 03 Mar 2013 20:45:33 -0600	[thread overview]
Message-ID: <51340ACD.70904@gmail.com> (raw)
In-Reply-To: <1361360886-2956-1-git-send-email-ian.campbell@citrix.com>

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.campbell@citrix.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Keir (Xen.org) <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: xen-devel@lists.xen.org
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@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;
> +}


  parent reply	other threads:[~2013-03-04  2:45 UTC|newest]

Thread overview: 107+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-19 14:48 [PATCH V2] xen: event channel arrays are xen_ulong_t and not unsigned long Ian Campbell
2013-02-19 14:48 ` Ian Campbell
2013-02-19 14:49 ` [PATCH LINUX] " Ian Campbell
2013-02-19 14:49   ` Ian Campbell
2013-02-19 17:11   ` Stefano Stabellini
2013-02-19 17:11   ` Stefano Stabellini
2013-02-19 17:11     ` Stefano Stabellini
2013-02-19 17:17     ` Ian Campbell
2013-02-19 17:17     ` Ian Campbell
2013-02-19 17:17       ` Ian Campbell
2013-02-19 17:26       ` Tim Deegan
2013-02-19 17:26       ` Tim Deegan
2013-02-19 17:26         ` Tim Deegan
2013-02-19 17:28         ` Ian Campbell
2013-02-19 17:28           ` Ian Campbell
2013-02-19 17:28         ` Ian Campbell
2013-02-19 14:49 ` Ian Campbell
2013-02-19 14:49 ` [PATCH XEN] " Ian Campbell
2013-02-19 14:49 ` Ian Campbell
2013-02-19 14:49   ` Ian Campbell
2013-02-19 16:42   ` Stefano Stabellini
2013-02-19 16:42   ` Stefano Stabellini
2013-02-19 16:42     ` Stefano Stabellini
2013-02-21 17:16   ` Ian Campbell
2013-02-21 17:16   ` Ian Campbell
2013-02-21 17:16     ` Ian Campbell
2013-02-21 18:43     ` Keir Fraser
2013-02-21 18:43     ` Keir Fraser
2013-02-21 18:43       ` Keir Fraser
2013-02-22  8:28       ` Ian Campbell
2013-02-22  8:28         ` Ian Campbell
2013-02-22  8:28       ` Ian Campbell
2013-02-22  8:12     ` Jan Beulich
2013-02-22  8:12       ` Jan Beulich
2013-02-22  8:28       ` Ian Campbell
2013-02-22  8:28       ` Ian Campbell
2013-02-22  8:28         ` Ian Campbell
2013-02-22  8:48         ` Jan Beulich
2013-02-22  8:48         ` Jan Beulich
2013-02-22  8:48           ` Jan Beulich
2013-02-22  8:55           ` Ian Campbell
2013-02-22  8:55             ` Ian Campbell
2013-02-22  9:05             ` Jan Beulich
2013-02-22  9:05             ` Jan Beulich
2013-02-22  9:05               ` Jan Beulich
2013-02-22  8:55           ` Ian Campbell
2013-02-22  8:12     ` Jan Beulich
2013-02-19 17:27 ` [PATCH LINUX v3] " Ian Campbell
2013-02-19 17:27   ` Ian Campbell
2013-02-19 17:27 ` Ian Campbell
2013-02-19 17:29 ` [PATCH LINUX v4] " Ian Campbell
2013-02-19 17:29 ` Ian Campbell
2013-02-19 17:29   ` Ian Campbell
2013-02-19 18:12   ` Stefano Stabellini
2013-02-19 18:12     ` Stefano Stabellini
2013-02-19 18:43     ` Konrad Rzeszutek Wilk
2013-02-19 18:43     ` Konrad Rzeszutek Wilk
2013-02-19 18:43       ` Konrad Rzeszutek Wilk
2013-02-19 18:12   ` Stefano Stabellini
2013-02-20  2:07   ` Konrad Rzeszutek Wilk
2013-02-20  2:07     ` Konrad Rzeszutek Wilk
2013-02-20  3:09     ` Konrad Rzeszutek Wilk
2013-02-20  3:09       ` Konrad Rzeszutek Wilk
2013-02-20  9:13       ` Ian Campbell
2013-02-20  9:13         ` Ian Campbell
2013-02-20  9:13       ` Ian Campbell
2013-02-20  3:09     ` Konrad Rzeszutek Wilk
2013-02-20  2:07   ` Konrad Rzeszutek Wilk
2013-02-20 11:48 ` [PATCH LINUX v5] " Ian Campbell
2013-02-20 11:48   ` Ian Campbell
2013-02-21 17:11   ` Stefano Stabellini
2013-02-21 17:11   ` Stefano Stabellini
2013-02-21 17:11     ` Stefano Stabellini
2013-03-04  2:45   ` Rob Herring
2013-03-04  2:45   ` Rob Herring [this message]
2013-03-04  2:45     ` Rob Herring
2013-03-05  3:04     ` Will Deacon
2013-03-05  3:04     ` Will Deacon
2013-03-05  3:04       ` Will Deacon
2013-03-05  3:45       ` Ian Campbell
2013-03-05  3:45       ` Ian Campbell
2013-03-05  3:45         ` Ian Campbell
2013-03-05  6:55       ` Rob Herring
2013-03-05  6:55         ` Rob Herring
2013-03-05  7:03         ` Ian Campbell
2013-03-05  7:03           ` Ian Campbell
2013-03-05  7:03         ` Ian Campbell
2013-03-05  8:08         ` Will Deacon
2013-03-05  8:08         ` Will Deacon
2013-03-05  8:08           ` Will Deacon
2013-03-05  9:29           ` Ian Campbell
2013-03-05  9:29           ` Ian Campbell
2013-03-05  9:29             ` Ian Campbell
2013-03-07  3:17             ` Will Deacon
2013-03-07  3:17             ` Will Deacon
2013-03-07  3:17               ` Will Deacon
2013-03-07  7:17               ` Ian Campbell
2013-03-07  7:17               ` Ian Campbell
2013-03-07  7:17                 ` Ian Campbell
2013-03-05  6:55       ` Rob Herring
2013-03-05  3:56     ` Ian Campbell
2013-03-05  3:56       ` Ian Campbell
2013-03-05 14:04       ` Konrad Rzeszutek Wilk
2013-03-05 14:04         ` Konrad Rzeszutek Wilk
2013-03-05 14:04       ` Konrad Rzeszutek Wilk
2013-03-05  3:56     ` Ian Campbell
2013-02-20 11:48 ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51340ACD.70904@gmail.com \
    --to=robherring2@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.