qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Paul Brook <paul@codesourcery.com>
Cc: Nick Piggin <npiggin@suse.de>, Cam Macdonell <cam@cs.ualberta.ca>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Inter-VM shared memory PCI device
Date: Thu, 11 Mar 2010 03:10:47 +0000	[thread overview]
Message-ID: <20100311031047.GE11663@shareable.org> (raw)
In-Reply-To: <201003100003.38612.paul@codesourcery.com>

Paul Brook wrote:
> > > In a cross environment that becomes extremely hairy.  For example the x86
> > > architecture effectively has an implicit write barrier before every
> > > store, and an implicit read barrier before every load.
> > 
> > Btw, x86 doesn't have any implicit barriers due to ordinary loads.
> > Only stores and atomics have implicit barriers, afaik.
> 
> As of March 2009[1] Intel guarantees that memory reads occur in
> order (they may only be reordered relative to writes). It appears
> AMD do not provide this guarantee, which could be an interesting
> problem for heterogeneous migration..

(Summary: At least on AMD64, it does too, for normal accesses to
naturally aligned addresses in write-back cacheable memory.)

Oh, that's interesting.  Way back when I guess we knew writes were in
order and it wasn't explicit that reads were, hence smp_rmb() using a
locked atomic.

Here is a post by Nick Piggin from 2007 with links to Intel _and_ AMD
documents asserting that reads to cacheable memory are in program order:

    http://lkml.org/lkml/2007/9/28/212
    Subject: [patch] x86: improved memory barrier implementation

Links to documents:

    http://developer.intel.com/products/processor/manuals/318147.pdf
    http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf

The Intel link doesn't work any more, but the AMD one does.

Nick asserts "both manufacturers are committed to in-order loads from
cacheable memory for the x86 architecture".

I have just read the AMD document, and it is in there (but not
completely obviously), in section 7.2.  The implicit load-load and
store-store barriers are only guaranteed for "normal cacheable
accesses on naturally aligned boundaries to WB [write-back cacheable]
memory".  There are also implicit load-store barriers but not
store-load.

Note that the document covers AMD64; it does not say anything about
their (now old) 32-bit processors.

> [*] The most recent docs I have handy. Up to and including Core-2 Duo.

Are you sure the read ordering applies to 32-bit Intel and AMD CPUs too?

Many years ago, before 64-bit x86 existed, I recall discussions on
LKML where it was made clear that stores were performed in program
order.  If it were known at the time that loads were performed in
program order on 32-bit x86s, I would have expected that to have been
mentioned by someone.

-- Jamie

  parent reply	other threads:[~2010-03-11  3:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-05 23:52 [Qemu-devel] [PATCH] Support adding a file to qemu's ram allocation Cam Macdonell
2010-03-05 23:52 ` [Qemu-devel] [PATCH] Inter-VM shared memory PCI device Cam Macdonell
2010-03-07 22:53   ` Paul Brook
2010-03-08  1:45     ` Jamie Lokier
2010-03-08  9:48       ` Alexander Graf
2010-03-08  9:54         ` Jamie Lokier
2010-03-08 10:57           ` Alexander Graf
2010-03-09 21:41           ` Anthony Liguori
2010-03-08 13:04       ` Paul Brook
2010-03-09 19:00         ` Jamie Lokier
2010-03-08  9:52     ` Avi Kivity
2010-03-08 13:03       ` Paul Brook
2010-03-08 13:16         ` Avi Kivity
2010-03-09 20:11           ` Jamie Lokier
2010-03-09 21:44           ` Anthony Liguori
2010-03-10  9:25             ` Avi Kivity
2010-03-10 17:13               ` Anthony Liguori
2010-03-10 17:30                 ` Avi Kivity
2010-03-10 17:41                   ` Paul Brook
2010-03-11  6:33                     ` Avi Kivity
2010-03-11 12:21                       ` Paul Brook
2010-03-09 20:12         ` Jamie Lokier
2010-03-10  0:03           ` Paul Brook
2010-03-10  4:38             ` Cam Macdonell
2010-03-10  9:29               ` Avi Kivity
2010-03-10 11:13                 ` Paul Brook
2010-03-11  3:10             ` Jamie Lokier [this message]
2010-03-11  4:37               ` Nick Piggin
2010-03-11 14:38                 ` malc
2010-03-08  9:56   ` [Qemu-devel] " Avi Kivity
2010-03-08 17:57     ` Cam Macdonell
2010-03-09 10:29       ` Avi Kivity
     [not found]         ` <8286e4ee1003090724m1ef0b571g8b705a24e36e1753@mail.gmail.com>
2010-03-09 15:27           ` [Qemu-devel] " Cam Macdonell
2010-03-09 17:28             ` [Qemu-devel] " Avi Kivity
2010-03-09 17:34               ` Anthony Liguori
2010-03-09 18:34               ` Cam Macdonell
2010-03-10  9:21                 ` Avi Kivity
2010-03-10 16:36                   ` Cam Macdonell
2010-03-11  6:49                     ` Avi Kivity
2010-03-09 12:49       ` Arnd Bergmann
2010-03-09 13:03         ` Avi Kivity
2010-03-09 16:44           ` Cam Macdonell
2010-03-10 14:04             ` Arnd Bergmann
2010-03-11  6:50               ` Avi Kivity
2010-03-11 12:57                 ` Arnd Bergmann
2010-03-11 13:07                   ` Avi Kivity
2010-03-11 14:32                     ` Arnd Bergmann
2010-03-08  9:53 ` [Qemu-devel] Re: [PATCH] Support adding a file to qemu's ram allocation Avi Kivity

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=20100311031047.GE11663@shareable.org \
    --to=jamie@shareable.org \
    --cc=avi@redhat.com \
    --cc=cam@cs.ualberta.ca \
    --cc=kvm@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).