Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933297AbbLOJKa (ORCPT ); Tue, 15 Dec 2015 04:10:30 -0500 Received: from mga03.intel.com ([134.134.136.65]:11439 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932275AbbLOJKZ (ORCPT ); Tue, 15 Dec 2015 04:10:25 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,431,1444719600"; d="scan'208";a="873894362" 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> Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org From: Xiao Guangrong Message-ID: <566FD77F.9050009@linux.intel.com> Date: Tue, 15 Dec 2015 17:03:59 +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: <566FCB15.1000004@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: 1736 Lines: 41 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. > Even it works for write protection, is it OK for other purpose tracking (as your tracking framework > can be extended for other purpose)? We only need to make sure that no track event is lost, i.e, we can not skip the case that the index is changed from 0 to 1. If we see index is 0, the vcpu can hold the mmu-lock and go to slow path anyway so no track event will be lost. >> >> However, if the page table is not present, it is worth making the page >> table entry present and readonly to make the read access happy > It's fine for tracking write from guest. But what if I want to track every read from guest? > Probably I am exaggerating :) > Then we do not go to the real page fault handler, just keep the shadow page entry non-present. -- 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/