| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] regression from c/s 22071:c5aed2e049bc (ept: Put locks a
>>> 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
|
|
|
| |
|
Home