All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Isaku Yamahata <yamahata@valinux.co.jp>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xen-ia64-devel@lists.xensource.com,
	Samuel Thibault <samuel.thibault@eu.citrix.com>,
	Keir Fraser <Keir.Fraser@eu.citrix.com>
Subject: Re: [PATCH] xen: Use wmb instead of rmb in xen_evtchn_do_upcall().
Date: Wed, 11 Jun 2008 07:54:51 +0100	[thread overview]
Message-ID: <484F76BB.20507@goop.org> (raw)
In-Reply-To: <200806101815.53729.nickpiggin@yahoo.com.au>

Nick Piggin wrote:
> On Tuesday 10 June 2008 17:57, Jeremy Fitzhardinge wrote:
>   
>> Nick Piggin wrote:
>>     
>>> On Tuesday 10 June 2008 17:35, Isaku Yamahata wrote:
>>>       
>>>> This patch is ported one from 534:77db69c38249 of linux-2.6.18-xen.hg.
>>>> Use wmb instead of rmb to enforce ordering between
>>>> evtchn_upcall_pending and evtchn_pending_sel stores
>>>> in xen_evtchn_do_upcall().
>>>>         
>>> There are a whole load of places in the kernel that should be using
>>> smp_ variants of memory barriers. This seemed to me like one of them,
>>> but I could be wrong.
>>>       
>> No, it needs to be an unconditional barrier.  This is synchronizing with
>> the hypervisor - even if the kernel is compiled UP, the SMP hypervisor
>> may be testing/setting the events pending bits from another (physical) cpu.
>>     
>
> OK. What you *really* want is smp_*mb_even_if_compiled_for_UP() ;)
> That is, a small set of primitives that are compiled with CONFIG_SMP
> (and given some xxx_ prefix to distinguish).
>   

We already have a set of sync_* for atomic ops which are always locked.

> IO barriers are probably the best thing you can use for the moment.
>   

It is conceptually similar, I suppose.

       J

  reply	other threads:[~2008-06-11  6:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-10  7:35 [PATCH] xen: Use wmb instead of rmb in xen_evtchn_do_upcall() Isaku Yamahata
2008-06-10  7:41 ` Nick Piggin
2008-06-10  7:41 ` Nick Piggin
2008-06-10  7:57   ` Jeremy Fitzhardinge
2008-06-10  8:15     ` Nick Piggin
2008-06-10  8:15     ` Nick Piggin
2008-06-11  6:54       ` Jeremy Fitzhardinge [this message]
2008-06-11  6:54       ` Jeremy Fitzhardinge
2008-06-10  7:57   ` Jeremy Fitzhardinge
2008-06-10  8:01   ` Isaku Yamahata
2008-06-10  8:01   ` Isaku Yamahata
  -- strict thread matches above, loose matches on Subject: below --
2008-06-16 21:58 Jeremy Fitzhardinge
2008-06-10  7:35 Isaku Yamahata

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=484F76BB.20507@goop.org \
    --to=jeremy@goop.org \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=samuel.thibault@eu.citrix.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xen-ia64-devel@lists.xensource.com \
    --cc=yamahata@valinux.co.jp \
    /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.