From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: regression from c/s 22071:c5aed2e049bc (ept: Put locks around ept_get_entry) ? Date: Thu, 16 Dec 2010 16:12:18 +0000 Message-ID: References: <4D0A439802000078000286FC@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D0A439802000078000286FC@vpn.id2.novell.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: Jan Beulich , George Dunlap Cc: Christoph Egger , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 16/12/2010 15:51, "Jan Beulich" wrote: >>>> On 14.12.10 at 11:47, George Dunlap wrote: >> Attached is a ported patch that removes locking in ept_get_entry(), >> and implements access-once semantics for reading and writing. This >> solves the original problem (a race between reading and writing the >> table) without causing deadlocks. I haven't had a chance to test it >> -- can you give it a spin? > > I think this is missing some barrier() instances (or volatile > qualifiers). Without them, I don't think there's a guarantee > that the single memory access in the source won't be > converted to multiple ones at the compiler's discretion. Probably a similar assumption to what we make in x86_64's pte_write_atomic() implementation? Possibly pte_{read,write}_atomic() should cast the pte pointer to volatile, and the EPT reads/writes should be similarly wrapped in macros which do casting. I'm sure we make various other assumptions about read/write atomicity in Xen, but aiming to fix them as we find them is maybe not a bad idea. If that sounds good, I can propose a patch? -- Keir > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel