From: konrad.wilk@oracle.com (Konrad Rzeszutek Wilk)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH LINUX v4] xen: event channel arrays are xen_ulong_t and not unsigned long
Date: Tue, 19 Feb 2013 13:43:37 -0500 [thread overview]
Message-ID: <20130219184337.GB18831@phenom.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1302191808110.4654@kaball.uk.xensource.com>
On Tue, Feb 19, 2013 at 06:12:35PM +0000, Stefano Stabellini wrote:
> On Tue, 19 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.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 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...
>
> still doesn't apply to 3.8
Weird. It applied to my tree (stable/for-linus-3.9) without fuss.
>
>
> > do {
> > - unsigned long pending_words;
> > + xen_ulong_t pending_words;
> >
> > vcpu_info->evtchn_upcall_pending = 0;
> >
> > if (__this_cpu_inc_return(xed_nesting_count) - 1)
> > goto out;
> >
> > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > - /* Clear master flag /before/ clearing selector flag. */
> > - wmb();
> > -#endif
> > - pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > + /*
> > + * Master flag must be /before/ clearing selector
> > + * flag. xchg_xen_ulong must contain an appropriate
> > + * barrier.
> > + */
>
> Master flag must be *cleared* ...
>
> > + pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> >
> > start_word_idx = __this_cpu_read(current_word_idx);
> > start_bit_idx = __this_cpu_read(current_bit_idx);
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jan Beulich <JBeulich@suse.com>, "Keir (Xen.org)" <keir@xen.org>,
"Tim (Xen.org)" <tim@xen.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH LINUX v4] xen: event channel arrays are xen_ulong_t and not unsigned long
Date: Tue, 19 Feb 2013 13:43:37 -0500 [thread overview]
Message-ID: <20130219184337.GB18831@phenom.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1302191808110.4654@kaball.uk.xensource.com>
On Tue, Feb 19, 2013 at 06:12:35PM +0000, Stefano Stabellini wrote:
> On Tue, 19 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.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 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...
>
> still doesn't apply to 3.8
Weird. It applied to my tree (stable/for-linus-3.9) without fuss.
>
>
> > do {
> > - unsigned long pending_words;
> > + xen_ulong_t pending_words;
> >
> > vcpu_info->evtchn_upcall_pending = 0;
> >
> > if (__this_cpu_inc_return(xed_nesting_count) - 1)
> > goto out;
> >
> > -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> > - /* Clear master flag /before/ clearing selector flag. */
> > - wmb();
> > -#endif
> > - pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> > + /*
> > + * Master flag must be /before/ clearing selector
> > + * flag. xchg_xen_ulong must contain an appropriate
> > + * barrier.
> > + */
>
> Master flag must be *cleared* ...
>
> > + pending_words = xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> >
> > start_word_idx = __this_cpu_read(current_word_idx);
> > start_bit_idx = __this_cpu_read(current_bit_idx);
next prev parent reply other threads:[~2013-02-19 18:43 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: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 17:26 ` Tim Deegan
2013-02-19 17:17 ` 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 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: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-21 17:16 ` Ian Campbell
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:12 ` Stefano Stabellini
2013-02-19 18:43 ` Konrad Rzeszutek Wilk [this message]
2013-02-19 18:43 ` Konrad Rzeszutek Wilk
2013-02-19 18:43 ` Konrad Rzeszutek Wilk
2013-02-20 2:07 ` Konrad Rzeszutek Wilk
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 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 11:48 ` [PATCH LINUX v5] " Ian Campbell
2013-02-20 11:48 ` 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
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 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 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 8:08 ` Will Deacon
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
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=20130219184337.GB18831@phenom.dumpdata.com \
--to=konrad.wilk@oracle.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.