From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932383AbdCUI5L (ORCPT ); Tue, 21 Mar 2017 04:57:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35076 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932173AbdCUI5K (ORCPT ); Tue, 21 Mar 2017 04:57:10 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 24FFAC04B946 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=david@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 24FFAC04B946 Subject: Re: [PATCH v2 3/3] KVM: x86: correct async page present tracepoint To: Wanpeng Li , linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <1490069935-6232-1-git-send-email-wanpeng.li@hotmail.com> <1490069935-6232-3-git-send-email-wanpeng.li@hotmail.com> Cc: Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Wanpeng Li From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Tue, 21 Mar 2017 09:57:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1490069935-6232-3-git-send-email-wanpeng.li@hotmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 21 Mar 2017 08:57:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21.03.2017 05:18, Wanpeng Li wrote: > From: Wanpeng Li > > After async pf setup successfully, there is a broadcast wakeup w/ special > token 0xffffffff which tells vCPU that it should wake up all processes > waiting for APFs though there is no real process waiting at the moment. > > The async page present tracepoint print prematurely and fails to catch the > special token setup. This patch fixes it by moving the async page present > tracepoint after the special token setup. > > Before patch: > > qemu-system-x86-8499 [006] ...1 5973.473292: kvm_async_pf_ready: token 0x0 gva 0x0 > > After patch: > > qemu-system-x86-8499 [006] ...1 5973.473292: kvm_async_pf_ready: token 0xffffffff gva 0x0 > Wonder if there is a reason why this is traced before any work is done. Maybe we should keep that order (by breaking up the if-else). > Cc: Paolo Bonzini > Cc: Radim Krčmář > Signed-off-by: Wanpeng Li > --- > arch/x86/kvm/x86.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 1faf620..e27eb7f 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -8566,11 +8566,11 @@ void kvm_arch_async_page_present(struct kvm_vcpu *vcpu, > { > struct x86_exception fault; > > - trace_kvm_async_pf_ready(work->arch.token, work->gva); > if (work->wakeup_all) > work->arch.token = ~0; /* broadcast wakeup */ > else > kvm_del_async_pf_gfn(vcpu, work->arch.gfn); > + trace_kvm_async_pf_ready(work->arch.token, work->gva); > > if ((vcpu->arch.apf.msr_val & KVM_ASYNC_PF_ENABLED) && > !apf_put_user(vcpu, KVM_PV_REASON_PAGE_READY)) { > -- Thanks, David