WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] regression from c/s 22071:c5aed2e049bc (ept: Put locks a

To: "Keir Fraser" <keir@xxxxxxx>
Subject: Re: [Xen-devel] regression from c/s 22071:c5aed2e049bc (ept: Put locks around ept_get_entry) ?
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 16 Dec 2010 16:22:17 +0000
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 16 Dec 2010 08:23:10 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C92FEAE2.D1B5%keir@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D0A439802000078000286FC@xxxxxxxxxxxxxxxxxx> <C92FEAE2.D1B5%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 16.12.10 at 17:12, Keir Fraser <keir@xxxxxxx> wrote:
> On 16/12/2010 15:51, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> 
>>>>> On 14.12.10 at 11:47, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> 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?

Oh, yes. I didn't even consider there might be more places.

What I'm surprised about is you suggesting to take the "volatile"
route instead of the barrier() one...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>