Anthony Liguori wrote: > Izik Eidus wrote: > >>> That's not quite what I was wondering. >>> >>> When you do an madvise() in userspace, the result is that when that >>> memory is accessed again, linux will demand-fault in a zero page and >>> COW it appropriately. If we do madvise() on the VA representing >>> guest physical memory, what I'm curious about is whether the guest >>> will actually see this change. If the guest happens to have the page >>> mapped before we do the madvise(), what triggers KVM to kick any >>> shadow page table entries out of it's cache? >>> >>> IIUC, today, after the madvise, the guest will have access to the old >>> page until that entry gets evicted and reloaded from the shadow page >>> table cache. >>> >> ok i am no familier with madvise() so i might talk nonsense but, >> if the guest have the page mapped before the madvise(), this mean we >> have high refernce to it, this is our only protection and as far as i >> understand this should be enough >> > > Right, we will have a reference to the page. But we want to propagate > this change to the guest. So madvise() may be a bad example. > > What if you wanted to do shared memory for multiple guests. You start > out with an anonymous mmap(), and you now what to mmap() a file in > /dev/shm to be shared among multiple guests so you mmap(MAP_FIXED) to > phys_ram_base + guest_pa in each guest. > > So what if guest_pa was in the guest's shadow page cache? In order for > the guest to see the right hpa (the new shared memory), we have to be > able to evict guest_pa. We could do this with something like > mmu_unshadow(). > > What I don't understand, is how we can have something like > mmu_unshadow() called automatically when an mmap() is initiated from > userspace. We could just add an ioctl() to do it from userspace but I > think it would be nicer if it Just Worked. >
Behold the magic of pte notifiers! Every time the host touches a host page table entry, it calls kvm which zaps the corresponding shadow pte entries and invalidates any tlb entries in running vcpus. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
