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. yea i agree with you, but i dont know either how to do it, we will probably have to look around to see how it can be done. avi any idea? > > Regards, > > Anthony Liguori > >> >> >> >> >
------------------------------------------------------------------------- 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
