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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> 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