| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] regression from c/s 22071:c5aed2e049bc (ept: Put locks a
>>> On 14.12.10 at 11:47, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> Yes, I have to apologize: I have a queue of PoD, p2m, and ept-related
> fixes that I haven't pushed to the list because:
> * they require non-negligible reworking
> * it's been really difficult for me to set up an OSS-based system to test
> them
>
> It actually turns out that doing locking in ept_get_entry() is the
> wrong thing to do anyway; it can cause the following deadlock:
>
> p2m_change_type [grabs p2m lock] -> set_p2m_entry -> ept_set_entry ->
> ept_set_middle_level -> p2m_alloc [grabs hap lock]
>
> write cr4 -> hap_update_paging_modes [grabes hap lock] ->
> hap_update_cr3 -> gfn_to_mfn -> ept_get_entry -> [grabs p2m lock]
>
> 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?
For really giving this a try I'd have to use it on 4.0, where it
doesn't apply at all. Resolving the rejects is non-obvious for me
in some cases, as I don't know this code well enough. Hence
for the moment we'll just drop the bad backport of your first
attempt.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home