From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: mmu_notifers, pte_dirty questions
Date: Sun, 6 Jun 2010 20:36:08 +0200
Message-ID: <20100606183608.GI28052@random.random>
References: <4C0B8F7F.507@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	KVM list <kvm@vger.kernel.org>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:48695 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751450Ab0FFSgK (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 6 Jun 2010 14:36:10 -0400
Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o56Ia9QH020467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <kvm@vger.kernel.org>; Sun, 6 Jun 2010 14:36:10 -0400
Content-Disposition: inline
In-Reply-To: <4C0B8F7F.507@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.

set_pte_at_notify might prevent a minor fault though.