Re: [Xen-devel] [PATCH v3 05/13] x86/altp2m: basic data structures and support routines.

["Sahita, Ravi" <ravi.sahita@xxxxxxxxx>]

>From: George Dunlap [mailto:george.dunlap@xxxxxxxxxxxxx]
>Sent: Friday, July 10, 2015 9:35 AM
>
>On 07/09/2015 06:05 PM, Sahita, Ravi wrote:
>>> And Tim, Andrew and I subsequently discussed this specific approach
>>> in a phone meeting.
>>>
>>> Ed
>>
>> Here is a brief description of the approach that was taken -
>>
>> The altp2m design implements a set of p2m's that are derived from the
>> host p2m, by lazy copy, and can then have specific modifications
>> applied. If a change is made to the host p2m when the domain is in
>> altp2m mode, that change must be propagated to any altp2m that
>> contains a valid copy of the old host p2m entry, primarily to
>> guarantee that no altp2m maps a mfn that is not mapped by the host
>> p2m, as that would compromise Xen. Tim suggested that the only safe
>> way to perform that propagation would be in the code that writes the
>> new EPTE, but by that point there is invariably a lock on the host
>> p2m, and that lock was frequently acquired some way higher in the call
>> stack. It is not safe to walk the list of altp2m's without holding the
>> list lock, so in that situation the acquisition order is
>> hostp2m->altp2mlist->altp2m. Although Ed did the implementation, the
>> idea to split the p2m lock type using the macros in mm-locks.h was
>> suggested by Tim and Andrew in a phone meeting attended by Tim,
>Andrew, Ravi, and Ed in early May.
>
>Thanks for the description.  I'd summarize it this way:
>
>Changes made to the host p2m when in altp2m mode are propagated to the
>altp2ms synchronously in ept_set_entry().  At that point, we will hold the host
>p2m lock; propagating this change involves grabbing the altp2m_list lock, and
>the locks of the individual alternate p2ms.  In order to allow us to maintain
>locking order discipline, we split the p2m lock into p2m (for host p2ms) and
>altp2m (for alternate p2ms), putting the altp2mlist lock in the middle.
>
>Is that about right?

Yes that's fine.

>
>If so, please add the above paragraph, or something with the same basic
>information, in the comments in mm-locks.h.

Ok.

>
>Thanks,
> -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel