From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 00/13] KVM: MMU: fast page fault Date: Mon, 09 Apr 2012 17:25:19 +0300 Message-ID: <4F82F14F.9040009@redhat.com> References: <4F742951.7080003@linux.vnet.ibm.com> <4F82E04E.6000900@redhat.com> <4F82EA4C.1020507@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , LKML , KVM To: Xiao Guangrong Return-path: In-Reply-To: <4F82EA4C.1020507@linux.vnet.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 04/09/2012 04:55 PM, Xiao Guangrong wrote: > > Okay, let's simplify it as possible: > > - let it only fix the page fault with PFEC.P == 1 && PFEC.W = 0, that means > unlock set_spte path can be dropped > > - let it just fixes the page fault caused by dirty-log that means we always > skip the spte which write-protected by shadow page protection. > > Then, things should be fair simper: > > In set_spte path, if the spte can be writable, we set ALLOW_WRITE bit > In rmap_write_protect: > if (spte.PT_WRITABLE_MASK) { > WARN_ON(!(spte & ALLOW_WRITE)); > spte &= ~PT_WRITABLE_MASK; > spte |= WRITE_PROTECT; > } > > in fast page fault: > > if (spte & PT_WRITABLE_MASK) > return_go_guest; > > if ((spte & ALLOW_WRITE) && !(spte & WRITE_PROTECT)) > cmpxchg spte + PT_WRITABLE_MASK > > The information all we needed comes from spte it is independence from other path, > and no barriers. > > > Hmm, how about this one? > I like it. WRITE_PROTECT is better than my ALLOW_WRITES, the meaning is clearer. -- error compiling committee.c: too many arguments to function