From: Sean Christopherson <seanjc@google.com>
To: Isaku Yamahata <isaku.yamahata@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
isaku.yamahata@gmail.com
Subject: Re: [RFC PATCH 00/10] KVM: x86/mmu: simplify argument to kvm page fault handler
Date: Wed, 26 May 2021 21:10:47 +0000 [thread overview]
Message-ID: <YK65V++S2Kt1OLTu@google.com> (raw)
In-Reply-To: <cover.1618914692.git.isaku.yamahata@intel.com>
On Tue, Apr 20, 2021, Isaku Yamahata wrote:
> This is a preliminary clean up for TDX which complicates KVM page fault
> execution path.
Ooh, a series to complicate the page fault path! ;-)
Grammatical snarkiness aside, I'm all in favor of adding a struct to collect the
page fault collateral. Overarching feedback:
- Have kvm_mmu_do_page_fault() handle initialization of the struct. That
will allow making most of the fields const, and will avoid the rather painful
kvm_page_fault_init().
- Pass @vcpu separately. Yes, it's associated with the fault, but literally
the first line in every consumer is "struct kvm_vcpu *vcpu = kpf->vcpu;".
- Use "fault" instead of "kpf", mostly because it reads better for people that
aren't intimately familiar with the code, but also to avoid having to refactor
a huge amount of code if we decide to rename kvm_page_fault, e.g. if we decide
to use that name to return fault information to userspace.
- Snapshot anything that is computed in multiple places, even if it is
derivative of existing info. E.g. it probably makes sense to grab
write/fetch (or exec).
E.g. I'm thinking something like
struct kvm_page_fault {
const gpa_t cr2_or_gpa;
const u32 error_code;
const bool write;
const bool read;
const bool fetch;
const bool prefault;
const bool is_tdp;
gfn_t gfn;
hva_t hva;
int max_level;
kvm_pfn_t pfn;
bool map_writable;
};
int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault);
static inline int kvm_mmu_do_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
u32 err, bool prefault)
{
struct kvm_page_fault fault = {
.cr2_or_gpa = cr2_or_gpa,
.error_code = err,
.write = err & PFERR_WRITE_MASK,
.fetch = err & PFERR_FETCH_MASK,
.perm = ...
.rsvd = err & PFERR_RSVD_MASK,
.is_tdp = vcpu->arch.mmu->page_fault == kvm_tdp_page_fault,
...
};
#ifdef CONFIG_RETPOLINE
if (likely(fault.is_tdp))
return kvm_tdp_page_fault(vcpu, &fault);
#endif
return vcpu->arch.mmu->page_fault(vcpu, &fault);
}
next prev parent reply other threads:[~2021-05-26 21:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-20 10:39 [RFC PATCH 00/10] KVM: x86/mmu: simplify argument to kvm page fault handler Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 01/10] KVM: x86/mmu: make kvm_mmu_do_page_fault() receive single argument Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 02/10] KVM: x86/mmu: make kvm_mmu:page_fault " Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 03/10] KVM: x86/mmu: make direct_page_fault() " Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 04/10] KVM: x86/mmu: make try_async_pf() " Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 05/10] KVM: x86/mmu: make page_fault_handle_page_track() " Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 06/10] KVM: x86/mmu: make handle_abnormal_pfn() " Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 07/10] KVM: x86/mmu: make fast_page_fault() " Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 08/10] KVM: x86/mmu: make __direct_map() " Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 09/10] KVM: x86/mmu: make kvm_tdp_mmu_map() " Isaku Yamahata
2021-04-20 10:39 ` [RFC PATCH 10/10] KVM: x86/mmu: make FNAME(fetch) " Isaku Yamahata
2021-05-26 21:10 ` Sean Christopherson [this message]
2021-06-10 12:45 ` [RFC PATCH 00/10] KVM: x86/mmu: simplify argument to kvm page fault handler Paolo Bonzini
2021-06-10 22:00 ` Isaku Yamahata
2021-07-29 16:48 ` David Matlack
2021-07-29 17:17 ` Paolo Bonzini
2021-07-29 17:24 ` David Matlack
2021-08-06 16:07 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YK65V++S2Kt1OLTu@google.com \
--to=seanjc@google.com \
--cc=isaku.yamahata@gmail.com \
--cc=isaku.yamahata@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.