Re: [Xen-devel] regression from c/s 22071:c5aed2e049bc (ept: Put locks around ept_get_entry) ?

[Keir Fraser <keir@xxxxxxx>]

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?

 -- Keir

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



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