> Am 10.02.2020 um 19:41 schrieb Christian Borntraeger <borntraeger@xxxxxxxxxx>: > > > >> On 10.02.20 13:26, David Hildenbrand wrote: >>> On 07.02.20 12:39, Christian Borntraeger wrote: >>> From: Ulrich Weigand <Ulrich.Weigand@xxxxxxxxxx> >>> >>> The adapter interrupt page containing the indicator bits is currently >>> pinned. That means that a guest with many devices can pin a lot of >>> memory pages in the host. This also complicates the reference tracking >>> which is needed for memory management handling of protected virtual >>> machines. >>> We can reuse the pte notifiers to "cache" the page without pinning it. >>> >>> Signed-off-by: Ulrich Weigand <Ulrich.Weigand@xxxxxxxxxx> >>> Suggested-by: Andrea Arcangeli <aarcange@xxxxxxxxxx> >>> [borntraeger@xxxxxxxxxx: patch merging, splitting, fixing] >>> Signed-off-by: Christian Borntraeger <borntraeger@xxxxxxxxxx> >>> --- >> >> So, instead of pinning explicitly, look up the page address, cache it, >> and glue its lifetime to the gmap table entry. When that entry is >> changed, invalidate the cached page. On re-access, look up the page >> again and register the gmap notifier for the table entry again. > > I think I might want to split this into two parts. > part 1: a naive approach that always does get_user_pages_remote/put_page > part 2: do the complex caching > > Ulrich mentioned that this actually could make the map/unmap a no-op as we > have the address and bit already in the irq route. In the end this might be > as fast as todays pinning as we replace a list walk with a page table walk. > Plus it would simplify the code. Will have a look if that is the case. If we could simplify that heavily, that would be awesome!
