Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754600AbbLPIaV (ORCPT ); Wed, 16 Dec 2015 03:30:21 -0500 Received: from mga14.intel.com ([192.55.52.115]:54919 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751846AbbLPIaT (ORCPT ); Wed, 16 Dec 2015 03:30:19 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,436,1444719600"; d="scan'208";a="842236784" Subject: Re: [PATCH 06/11] KVM: MMU: let page fault handler be aware tracked page To: Kai Huang , pbonzini@redhat.com References: <1448907973-36066-1-git-send-email-guangrong.xiao@linux.intel.com> <1448907973-36066-7-git-send-email-guangrong.xiao@linux.intel.com> <566FCB15.1000004@linux.intel.com> <566FD77F.9050009@linux.intel.com> <5671136B.3040006@linux.intel.com> Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org From: Xiao Guangrong Message-ID: <56711F97.5040705@linux.intel.com> Date: Wed, 16 Dec 2015 16:23:51 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5671136B.3040006@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1632 Lines: 37 On 12/16/2015 03:31 PM, Kai Huang wrote: > > > On 12/15/2015 05:03 PM, Xiao Guangrong wrote: >> >> >> On 12/15/2015 04:11 PM, Kai Huang wrote: >>> >>> >>> On 12/01/2015 02:26 AM, Xiao Guangrong wrote: >>>> The page fault caused by write access on the write tracked page can not >>>> be fixed, it always need to be emulated. page_fault_handle_page_track() >>>> is the fast path we introduce here to skip holding mmu-lock and shadow >>>> page table walking >>> Why can it be out side of mmu-lock? Is it OK that some other thread removes tracking of this page >>> simultaneously? Shall we assuming the emulation code should handle this case? >>> >> >> What your mentioned is the worst case, if that happen the vcpu will spend >> longer time to emulate the access rather then retry it. It is bad but it is >> the rare contention. It is worth speeding up the common / most case. > My concern is when this case happen, whether emulating the access is still the right behavior, you > know, after other thread removed the GFN from tracking.. > And as the notifier's track_write call back will be called in the emulating code, won't there be > problem if the GFN has been removed from tracking by other thread? > When the notify callback is called, the tracker should check if the gfn is what it is interested by itself. If it sees the gfn is not trackered anymore, it can skip the callback. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/