From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH] Fix memory order issue inside pv spinlock Date: Wed, 09 Sep 2009 18:50:05 -0700 Message-ID: <4AA85B4D.8060303@goop.org> References: <4AA4B8FF.9070905@intel.com> <4AA6D3CF.70905@goop.org> <4AA7D808.6010108@intel.com> <4AA7FBB5.3000204@goop.org> <4AA85937.6080001@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4AA85937.6080001@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Yang, Xiaowei" Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 09/09/09 18:41, Yang, Xiaowei wrote: > Jeremy Fitzhardinge wrote: > >> On 09/09/09 09:30, Yang, Xiaowei wrote: >>> Jeremy Fitzhardinge wrote: >>>> On 09/07/09 00:40, Yang, Xiaowei wrote: >>>>> barrier() can't prevent reads after it not being reordered with older >>>>> writes to different locates before it. Because of it, I can't >>>>> bring up >>>>>> 4 HVM guests on one SMP machine. Use mb() instead. >>>> Which read is happening too early? Is it "xl->spinners"? How does >>>> it fail? >>> Yes. If read of xl->spinners happens earlier than write 0 to xl->lock, >>> notifications to wake up other spinners can be omitted incorrectly, >>> resulting in others polling indefinitely (because of poll evtchn not >>> pending) with the lock is uncontended. >> >> OK. And the CPU only guarantees that, without explicit barriers, >> write-read ordering is only maintained between accesses to the same >> memory location, not separate locations? >> > > Exactly! For more details please refer to Chapter 8.2 of Intel SDM 3A. Thanks. I just submitted both fixes to upstream. J