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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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?

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

Thanks,
 -George


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