From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: x86-64 tools fix question Date: Wed, 02 Mar 2005 00:52:05 -0600 Message-ID: <42256295.9020906@us.ibm.com> References: <1109707006.13010.15.camel@thinkpad> <42255FFB.2030900@blueyonder.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <42255FFB.2030900@blueyonder.co.uk> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: david.nospam.hopwood@blueyonder.co.uk Cc: xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org David Hopwood wrote: > Jerone Young wrote: > See volume 1, section 3.9.2 of the AMD64 architecture manual > (http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html), > > quoted below for convenience. > > This should be guaranteed to work: > > #define rmb() __asm__ __volatile__ ( "mfence" : : : "memory" ) > #define wmb() __asm__ __volatile__ ( "mfence" : : : "memory" ) sfence and lfence would seem to be more appropriate. mfence would seem to be appropriate for an mb() macro (which is usually also defined--but in this case not necessary). > but may be overkill. Are these macros used in any performance-critical > situations? If not then the overkill wouldn't matter. Not at all. They're currently used to prevent race conditions within the domain control channel ring queue. This queue is relatively low-traffic. The confusion stemmed from the x86-32 code that doesn't actually implement a wmb() since no relevant architecture does out-of-order stores. x86-64 is another story. The linux includes still have the same comments indicating that wmb() is not necessary (an obvious cut-and-paste job) even though wmb() is defined to sfence. To make matters worse, the wmb() is wrapped in the same CONFIG_UNORDERED_IO guarded (that's enabled by default in x86-64 but disabled by default in x86-32). It's understandably confusing. I'm hoping we can do a much better job in Xen in supporting both architectures to avoid these sort of confusions. Regards, Anthony Liguori ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click