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 17:03:11 +0000 Message-ID: References: <4D0A516B0200007800028755@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D0A516B0200007800028755@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 Cc: George Dunlap , Christoph Egger , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 16/12/2010 16:50, "Jan Beulich" wrote: >>>> On 16.12.10 at 17:42, Keir Fraser wrote: >> The issue is not one of serialisation or code ordering. It is one of >> memory-access atomicity. Thus it seems to me that volatile is the correct > > Indeed, I agree. > >> approach therefore. Perhaps *(volatile type *)px = x or, really, even better >> I should define some {read,write}_atomic{8,16,32,64} accessor functions >> which use inline asm to absolutely definitely emit a single atomic 'mov' >> instruction. >> >> Make sense? > > Yes. Excellent. I will lay groundwork and fix pte_{read,write}_atomic directly in -unstable and -4.0-testing. I will then post a proposed fix for EPT to the list. I don't know that code so well and I may not otherwise catch all places that require use of the new accessor macros. -- Keir > Jan >