Message ID | 20240227232100.478238-15-pbonzini@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-84200-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp3024866dyb; Tue, 27 Feb 2024 15:28:34 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUnt4S6dgOoCGfxvtUeRLkLcMOeK57UIWsT5dT3gcwFnE5bLuq2+ci4x7l3ABNM7OXJqw+eZoY/dPvXo8GmSL1RPicfuw== X-Google-Smtp-Source: AGHT+IFEKLYgCpt1O45Zx+dPoYJmYkjpcWTSe7MrR5a5gowEW1fPF7DslHKvsCwl1lncQbhXRYzX X-Received: by 2002:a17:906:8414:b0:a43:76d4:806c with SMTP id n20-20020a170906841400b00a4376d4806cmr3897634ejx.74.1709076514704; Tue, 27 Feb 2024 15:28:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709076514; cv=pass; d=google.com; s=arc-20160816; b=gwNLGF6ENhEtP9rXNeNLK/f/CwU6bwtiF6TuRxh819JUInr9q/Ae65zJBZxbyiN83L kYLgrA0MvJpRblAoZpPL/TI5vh3UpWL0Erqj3RH2+dzpCcAMqmWMbLzIKo5nHHjuK65t Vt0QYYxUXeydV3CXOwrolgSXfeBRvx3FGXUV/0X48V/yBivVcDdXzXa7gdhTT1UkwXnG jAppG32n8s1bka+FP42/nVh/PyUF1IT43GQTUtUxs1X9SjrvDbBy4v3D/MXM0ZAyZozQ U4kd0R3i81L79dUXX1HkX/Si/SyiPc3DDYpFl8uYIKLeOpkZTGarWrpuk6Y4XagAHvt9 DOIA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=WQWN2PaoYeGbfb484wmFXr0C+ga+oMUpdudpih+4GtY=; fh=miuXyzfw5j8qsOURKCmYrSiXirUlKyDkR37pPJ+5+/s=; b=juOCqTYYCIDI/3nPOKN5t1chjL4YJ0exiDEuOW7s5CogfEVcuO3brCkEyOghYoWdD4 bFMluH0l/kWbWKcbSKUoYHCdUciWrBIQ91yNwscVmbYkqSYSHS+3IYjwBdVqerLWO/WZ aNfalRut2cngEJ9TELFV7rmTQVOQbF+6+wHP/rqb7BejDxdSwa0dbiJzrz355IVH+J7r NuVc2ERFqwmvET6BWSO6NczVLjfVFyAWJcnxoLL2T7GeZvtilxWCyhyy1HPKxjIwcBic qg8dtgGyFHYxSQMYnBRuKRuVeRvpetXyEXyk53pbhkK90Y8Y1wIEaIMhtEvgSt5bwsZ6 CxkA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TYscmDNQ; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-84200-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-84200-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id b7-20020a170906038700b00a3e50678318si1146480eja.238.2024.02.27.15.28.34 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 15:28:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-84200-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TYscmDNQ; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-84200-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-84200-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 23BDE1F22ABB for <ouuuleilei@gmail.com>; Tue, 27 Feb 2024 23:28:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EF46D5730C; Tue, 27 Feb 2024 23:21:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TYscmDNQ" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F7A457877 for <linux-kernel@vger.kernel.org>; Tue, 27 Feb 2024 23:21:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709076071; cv=none; b=PRhVoKMrmQfUhoPVpQuc5/shlgu1ot1oq4yqCWxZUk2V+EKbsoJgiUhNcJa7QKdOdybj8V3Upvcu0InRrqzFD15yyisXzxgiCQetnVs8kfx+dNFD3eIH5geHqpWzGJGR283xcMHg0jDRvzhIJpbAND6UDUNb/4s+fOnH2E2nwe0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709076071; c=relaxed/simple; bh=ErJB7EiM6omf18IkUW6fJsRjCEcUOh0zo9UuqGLmlNU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=EBJnWps7bfJnDEAFJ7q+QUe0BmTLSh+UKBn9EI1Qsh6hgut1be6ikmzuqJ+pyaoeL5lpyMo342WpIERpT3fy5f64O3v0aBTryUMbVbnLV+G7AJUqb/EPszD/VvliwA/i9JC7C4RDDF1MIxpShKTViZPgXQPLezhqaThsBnMYpiY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TYscmDNQ; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709076067; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WQWN2PaoYeGbfb484wmFXr0C+ga+oMUpdudpih+4GtY=; b=TYscmDNQeZHXE1RFeA0SvIEHGFnjovK1AEnfFy9hahdd9AGYKaSAVIqWmluswvDgdbn+uv pan+B/tk9o2CZBs0VU6rE3RS4/5DZKjOYPE8LulbOYKLoEiX478laYOGgPGPP9HYdgqIj8 fJArPaIVBcZof+UOqJBTm1MYjCws/cE= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-169-nZ0P_-T8NH-byxOKwpEA4A-1; Tue, 27 Feb 2024 18:21:04 -0500 X-MC-Unique: nZ0P_-T8NH-byxOKwpEA4A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 320593869148; Tue, 27 Feb 2024 23:21:04 +0000 (UTC) Received: from virtlab511.virt.lab.eng.bos.redhat.com (virtlab511.virt.lab.eng.bos.redhat.com [10.19.152.198]) by smtp.corp.redhat.com (Postfix) with ESMTP id 05CFDC040F7; Tue, 27 Feb 2024 23:21:04 +0000 (UTC) From: Paolo Bonzini <pbonzini@redhat.com> To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com, isaku.yamahata@intel.com, thomas.lendacky@amd.com Subject: [PATCH 14/21] KVM: x86/mmu: pass error code back to MMU when async pf is ready Date: Tue, 27 Feb 2024 18:20:53 -0500 Message-Id: <20240227232100.478238-15-pbonzini@redhat.com> In-Reply-To: <20240227232100.478238-1-pbonzini@redhat.com> References: <20240227232100.478238-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792096615556089702 X-GMAIL-MSGID: 1792096615556089702 |
Series |
TDX/SNP part 1 of n, for 6.9
|
|
Commit Message
Paolo Bonzini
Feb. 27, 2024, 11:20 p.m. UTC
Right now the error code is not used when an async page fault is completed.
This is not a problem in the current code, but it is untidy. For protected
VMs we need to check that the page attributes match the current state of the
page. Async page faults can only occur on shared pages (because
private pages go through kvm_faultin_pfn_private() instead of
__gfn_to_pfn_memslot()), but it is risky to rely on the polarity of
PFERR_GUEST_ENC_MASK and the high 32 bits of the error code being zero.
So, for clarity and future-proofing of the code, pipe the error code
from kvm_arch_setup_async_pf() to kvm_arch_async_page_ready() via the
architecture-specific async page fault data.
Extracted from a patch by Isaku Yamahata.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/mmu/mmu.c | 14 +++++++-------
2 files changed, 8 insertions(+), 7 deletions(-)
Comments
On Tue, Feb 27, 2024, Paolo Bonzini wrote: > Right now the error code is not used when an async page fault is completed. > This is not a problem in the current code, but it is untidy. For protected > VMs we need to check that the page attributes match the current state of the > page. Async page faults can only occur on shared pages (because > private pages go through kvm_faultin_pfn_private() instead of > __gfn_to_pfn_memslot()), but it is risky to rely on the polarity of > PFERR_GUEST_ENC_MASK and the high 32 bits of the error code being zero. > So, for clarity and future-proofing of the code, pipe the error code > from kvm_arch_setup_async_pf() to kvm_arch_async_page_ready() via the > architecture-specific async page fault data. > > Extracted from a patch by Isaku Yamahata. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > arch/x86/include/asm/kvm_host.h | 1 + > arch/x86/kvm/mmu/mmu.c | 14 +++++++------- > 2 files changed, 8 insertions(+), 7 deletions(-) > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index a4514c2ef0ec..24e30ca2ca8f 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -1839,6 +1839,7 @@ struct kvm_arch_async_pf { > gfn_t gfn; > unsigned long cr3; > bool direct_map; > + u64 error_code; > }; > > extern u32 __read_mostly kvm_nr_uret_msrs; > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index f58ca6cb789a..c9890e5b6e4c 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -4260,18 +4260,18 @@ static u32 alloc_apf_token(struct kvm_vcpu *vcpu) > return (vcpu->arch.apf.id++ << 12) | vcpu->vcpu_id; > } > > -static bool kvm_arch_setup_async_pf(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, > - gfn_t gfn) > +static bool kvm_arch_setup_async_pf(struct kvm_vcpu *vcpu, > + struct kvm_page_fault *fault) > { > struct kvm_arch_async_pf arch; > > arch.token = alloc_apf_token(vcpu); > - arch.gfn = gfn; > + arch.gfn = fault->gfn; > arch.direct_map = vcpu->arch.mmu->root_role.direct; > arch.cr3 = kvm_mmu_get_guest_pgd(vcpu, vcpu->arch.mmu); > > - return kvm_setup_async_pf(vcpu, cr2_or_gpa, > - kvm_vcpu_gfn_to_hva(vcpu, gfn), &arch); > + return kvm_setup_async_pf(vcpu, fault->addr, > + kvm_vcpu_gfn_to_hva(vcpu, fault->gfn), &arch); > } > > void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work) > @@ -4290,7 +4290,7 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work) > work->arch.cr3 != kvm_mmu_get_guest_pgd(vcpu, vcpu->arch.mmu)) > return; > > - kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, 0, true, NULL); > + kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, work->arch.error_code, true, NULL); This is silly. If we're going to bother plumbing in the error code, then we should use it to do sanity checks. Things have gone off the rails if end up with an async #PF on private memory. > } > > static inline u8 kvm_max_level_for_order(int order) > @@ -4395,7 +4395,7 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > trace_kvm_async_pf_repeated_fault(fault->addr, fault->gfn); > kvm_make_request(KVM_REQ_APF_HALT, vcpu); > return RET_PF_RETRY; > - } else if (kvm_arch_setup_async_pf(vcpu, fault->addr, fault->gfn)) { > + } else if (kvm_arch_setup_async_pf(vcpu, fault)) { > return RET_PF_RETRY; > } > } > -- > 2.39.0 > >
On Wed, Feb 28, 2024 at 3:03 AM Sean Christopherson <seanjc@google.com> wrote: > > On Tue, Feb 27, 2024, Paolo Bonzini wrote: > > Right now the error code is not used when an async page fault is completed. > > This is not a problem in the current code, but it is untidy. For protected > > VMs we need to check that the page attributes match the current state of the > > page. Async page faults can only occur on shared pages (because > > private pages go through kvm_faultin_pfn_private() instead of > > __gfn_to_pfn_memslot()), but it is risky to rely on the polarity of > > PFERR_GUEST_ENC_MASK and the high 32 bits of the error code being zero. > > So, for clarity and future-proofing of the code, pipe the error code > > from kvm_arch_setup_async_pf() to kvm_arch_async_page_ready() via the > > architecture-specific async page fault data. > > > > Extracted from a patch by Isaku Yamahata. > > > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > > --- > > arch/x86/include/asm/kvm_host.h | 1 + > > arch/x86/kvm/mmu/mmu.c | 14 +++++++------- > > 2 files changed, 8 insertions(+), 7 deletions(-) > > > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > > index a4514c2ef0ec..24e30ca2ca8f 100644 > > --- a/arch/x86/include/asm/kvm_host.h > > +++ b/arch/x86/include/asm/kvm_host.h > > @@ -1839,6 +1839,7 @@ struct kvm_arch_async_pf { > > gfn_t gfn; > > unsigned long cr3; > > bool direct_map; > > + u64 error_code; > > }; > > > > extern u32 __read_mostly kvm_nr_uret_msrs; > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > index f58ca6cb789a..c9890e5b6e4c 100644 > > --- a/arch/x86/kvm/mmu/mmu.c > > +++ b/arch/x86/kvm/mmu/mmu.c > > @@ -4260,18 +4260,18 @@ static u32 alloc_apf_token(struct kvm_vcpu *vcpu) > > return (vcpu->arch.apf.id++ << 12) | vcpu->vcpu_id; > > } > > > > -static bool kvm_arch_setup_async_pf(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, > > - gfn_t gfn) > > +static bool kvm_arch_setup_async_pf(struct kvm_vcpu *vcpu, > > + struct kvm_page_fault *fault) > > { > > struct kvm_arch_async_pf arch; > > > > arch.token = alloc_apf_token(vcpu); > > - arch.gfn = gfn; > > + arch.gfn = fault->gfn; > > arch.direct_map = vcpu->arch.mmu->root_role.direct; > > arch.cr3 = kvm_mmu_get_guest_pgd(vcpu, vcpu->arch.mmu); > > > > - return kvm_setup_async_pf(vcpu, cr2_or_gpa, > > - kvm_vcpu_gfn_to_hva(vcpu, gfn), &arch); > > + return kvm_setup_async_pf(vcpu, fault->addr, > > + kvm_vcpu_gfn_to_hva(vcpu, fault->gfn), &arch); > > } > > > > void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work) > > @@ -4290,7 +4290,7 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work) > > work->arch.cr3 != kvm_mmu_get_guest_pgd(vcpu, vcpu->arch.mmu)) > > return; > > > > - kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, 0, true, NULL); > > + kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, work->arch.error_code, true, NULL); > > This is silly. If we're going to bother plumbing in the error code, then we > should use it to do sanity checks. Things have gone off the rails if end up with > an async #PF on private memory. Sure, I split this part out not just because it makes sense to do so, but also because it's not strictly necessary. I'll add the check and tweak the changelog. Paolo > > > } > > > > static inline u8 kvm_max_level_for_order(int order) > > @@ -4395,7 +4395,7 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > > trace_kvm_async_pf_repeated_fault(fault->addr, fault->gfn); > > kvm_make_request(KVM_REQ_APF_HALT, vcpu); > > return RET_PF_RETRY; > > - } else if (kvm_arch_setup_async_pf(vcpu, fault->addr, fault->gfn)) { > > + } else if (kvm_arch_setup_async_pf(vcpu, fault)) { > > return RET_PF_RETRY; > > } > > } > > -- > > 2.39.0 > > > > >
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index a4514c2ef0ec..24e30ca2ca8f 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1839,6 +1839,7 @@ struct kvm_arch_async_pf { gfn_t gfn; unsigned long cr3; bool direct_map; + u64 error_code; }; extern u32 __read_mostly kvm_nr_uret_msrs; diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index f58ca6cb789a..c9890e5b6e4c 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -4260,18 +4260,18 @@ static u32 alloc_apf_token(struct kvm_vcpu *vcpu) return (vcpu->arch.apf.id++ << 12) | vcpu->vcpu_id; } -static bool kvm_arch_setup_async_pf(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, - gfn_t gfn) +static bool kvm_arch_setup_async_pf(struct kvm_vcpu *vcpu, + struct kvm_page_fault *fault) { struct kvm_arch_async_pf arch; arch.token = alloc_apf_token(vcpu); - arch.gfn = gfn; + arch.gfn = fault->gfn; arch.direct_map = vcpu->arch.mmu->root_role.direct; arch.cr3 = kvm_mmu_get_guest_pgd(vcpu, vcpu->arch.mmu); - return kvm_setup_async_pf(vcpu, cr2_or_gpa, - kvm_vcpu_gfn_to_hva(vcpu, gfn), &arch); + return kvm_setup_async_pf(vcpu, fault->addr, + kvm_vcpu_gfn_to_hva(vcpu, fault->gfn), &arch); } void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work) @@ -4290,7 +4290,7 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work) work->arch.cr3 != kvm_mmu_get_guest_pgd(vcpu, vcpu->arch.mmu)) return; - kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, 0, true, NULL); + kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, work->arch.error_code, true, NULL); } static inline u8 kvm_max_level_for_order(int order) @@ -4395,7 +4395,7 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault trace_kvm_async_pf_repeated_fault(fault->addr, fault->gfn); kvm_make_request(KVM_REQ_APF_HALT, vcpu); return RET_PF_RETRY; - } else if (kvm_arch_setup_async_pf(vcpu, fault->addr, fault->gfn)) { + } else if (kvm_arch_setup_async_pf(vcpu, fault)) { return RET_PF_RETRY; } }