On 9/20/18 1:14 PM, David Hildenbrand wrote: > On 19/09/2018 10:47, Janosch Frank wrote: >> The gmap guest_table_lock is used to protect changes to the guest's >> DAT tables from region 1 to segments. Therefore it also protects the >> host to guest radix tree where each new segment mapping by gmap_link() >> is tracked. Changes to ptes are synchronized through the pte lock, >> which is easyly retrievable, because the gmap shares the page tables >> with userspace. >> >> With huge pages the story changes. PMD tables are not shared and we're >> left with the pmd lock on userspace side and the guest_table_lock on >> the gmap side. Having two locks for an object is a guarantee for >> locking problems. >> >> Therefore the guest_table_lock will only be used for population of the >> gmap tables and hence protecting the host_to_guest tree. While the pmd >> lock will be used for all changes to the pmd from both userspace and >> the gmap. >> >> This means we need to retrieve the vmaddr to retrieve a gmap pmd, >> which takes a bit longer than before. But we can now operate on >> multiple pmds which are in disjoint segment tables instead of having a >> global lock. >> > > Has the time come to document how locking works? (especially also for > gmap shadows) I'll add more locking instructions into the function comments for v1. Also I'll write something longer up after KVM forum and the inclusion of this patch set. Maybe I'll also add a simple GMAP documentation, after all I have ~30 pages of KVM mm documentation flying around.
Attachment:
signature.asc
Description: OpenPGP digital signature
