From mboxrd@z Thu Jan 1 00:00:00 1970 From: Izik Eidus Subject: Re: [PATCH 0/4] Swapping Date: Mon, 15 Oct 2007 22:15:11 +0200 Message-ID: <4713CA4F.8050607@qumranet.com> References: <47102823.2000600@qumranet.com> <4713ACF8.6010809@codemonkey.ws> <4713AF9C.8000609@qumranet.com> <4713B97F.7090403@codemonkey.ws> <4713BCA4.3080103@qumranet.com> <4713BFB3.8060701@codemonkey.ws> <4713C46E.9020107@qumranet.com> <4713C7A3.4050805@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <4713C7A3.4050805-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/