From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: mmu_notifers, pte_dirty questions Date: Mon, 07 Jun 2010 08:09:47 +0300 Message-ID: <4C0C7F1B.5070802@redhat.com> References: <4C0B8F7F.507@redhat.com> <20100606183608.GI28052@random.random> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , KVM list To: Andrea Arcangeli Return-path: Received: from mx1.redhat.com ([209.132.183.28]:29901 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751679Ab0FGFJv (ORCPT ); Mon, 7 Jun 2010 01:09:51 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5759ocp008191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Jun 2010 01:09:50 -0400 In-Reply-To: <20100606183608.GI28052@random.random> Sender: kvm-owner@vger.kernel.org List-ID: On 06/06/2010 09:36 PM, Andrea Arcangeli wrote: > On Sun, Jun 06, 2010 at 03:07:27PM +0300, Avi Kivity wrote: > >> Why no notifer when testing and clearing the dirty bit? >> >> (*clear_flush_dirty)(...). >> >> >>> static int page_mkclean_one(struct page *page, struct vm_area_struct *vma, >>> unsigned long address) >>> { >>> struct mm_struct *mm = vma->vm_mm; >>> pte_t *pte; >>> spinlock_t *ptl; >>> int ret = 0; >>> >>> pte = page_check_address(page, mm, address,&ptl, 1); >>> if (!pte) >>> goto out; >>> >>> if (pte_dirty(*pte) || pte_write(*pte)) { >>> pte_t entry; >>> >>> flush_cache_page(vma, address, pte_pfn(*pte)); >>> entry = ptep_clear_flush_notify(vma, address, pte); >>> entry = pte_wrprotect(entry); >>> entry = pte_mkclean(entry); >>> set_pte_at(mm, address, pte, entry); >>> >> set_pte_at_notify()? without this (or clear_flush_dirty) Linux will >> assume all ptes are now clean; if the guest writes to a page nothing >> will catch it. >> >> -> with set_pte_at_notify(), we can drop the spte and mark the page as >> dirty, so the next write will re-instantiate the spte >> -> with ->clear_flush_dirty(), we can track the dirty state without >> dropping the spte. >> >> >>> ret = 1; >>> } >>> >>> pte_unmap_unlock(pte, ptl); >>> out: >>> return ret; >>> >> I'm probably missing something big as I can't see how this works. >> > Under the PT lock it's safe to keep the PTE zero, just the pte must be > non zero again before pte_unmap_unlock. > > The sptes are all gone by the time ptep_clear_flush_notify returns > (also gup-fast is stopped with the IPI of the flush) and no spte can > be established again before pte_unmap_unlock runs, so it's all safe as > far as I can tell. > > Somehow I missed the ptep_clear_flush_notify()... so all should be fine. > set_pte_at_notify might prevent a minor fault though. > I'm thinking of how to implement speculative write access for kvm: consider a read fault for a writeable page. We could install a writeable spte with the dirty bit clear, and examine the dirty bit at pte_clear_flush_notify() time and transfer it to the page flags. However I can't see where the mm code checks the pte dirty bit for anonymous pages? Does it assume anonymous pages are always dirty? (they could have a clean copy in swap, no?) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.