From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: KVM: MMU: add KVM_ZAP_GFN ioctl Date: Sun, 23 Mar 2008 21:23:24 +0100 Message-ID: <20080323202324.GA11834@v2.random> References: <20080312222941.GA30457@dmt> <47E253EB.3060708@qumranet.com> <20080321114214.GF7822@v2.random> <20080321133700.GA26317@dmt> <47E619CA.7000200@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm-devel To: Avi Kivity Return-path: Content-Disposition: inline In-Reply-To: <47E619CA.7000200@qumranet.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org On Sun, Mar 23, 2008 at 10:50:18AM +0200, Avi Kivity wrote: > btw, when we nuke an spte, don't we lose dirty bit information? That > doesn't matter with madvise(), but it does when removing a pte for other > reasons, say swapping. Don't we need to clear the spte with cmpxchg(), to > make sure the dirty bit is what we think it is? get_user_pages is always called with dirty=1, so we know PG_dirty will be set on the page_t when the pte is cleared. The invalidate_page method is called by the rmap code just after clearing the pte while the page_t is locked, and while the page is locked PG_dirty shouldn't disappear. So as long as we only map anonymous memory we should be safe. (hugetlbfs wasn't allowed as guest physical memory yet when I wrote that code) But if we want to also call set_page_dirty and check the spte dirty bit, that's sure safe addition to make it less dependent on mmu notifier invocation details (notably PG_lock being set). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/