kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Matlack <dmatlack@google.com>
To: Isaku Yamahata <isaku.yamahata@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Isaku Yamahata <isaku.yamahata@intel.com>,
	kvm list <kvm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>
Subject: Re: [RFC PATCH 00/10] KVM: x86/mmu: simplify argument to kvm page fault handler
Date: Thu, 29 Jul 2021 09:48:31 -0700	[thread overview]
Message-ID: <CALzav=d2m+HffSLu5e3gz0cYk=MZ2uc1a3K+vP8VRVvLRiwd9g@mail.gmail.com> (raw)
In-Reply-To: <20210610220056.GA642297@private.email.ne.jp>

On Thu, Jun 10, 2021 at 3:05 PM Isaku Yamahata <isaku.yamahata@gmail.com> wrote:
>
> Thanks for feedback. Let me respin it.

Hi Isaku,

I'm working on a series to plumb the memslot backing the faulting gfn
through the page fault handling stack to avoid redundant lookups. This
would be much cleaner to implement on top of your struct
kvm_page_fault series than the existing code.

Are you still planning to send another version of this series? Or if
you have decided to drop it or go in a different direction?

>
> On Thu, Jun 10, 2021 at 02:45:55PM +0200,
> Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> > On 26/05/21 23:10, Sean Christopherson wrote:
> > >    - 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
> >
> > I agree with all of these (especially it was a bit weird not to see vcpu in
> > the prototypes).  Thanks Sean for the review!
> >
> > Paolo
> >
>
> --
> Isaku Yamahata <isaku.yamahata@gmail.com>

  reply	other threads:[~2021-07-29 16:49 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 ` [RFC PATCH 00/10] KVM: x86/mmu: simplify argument to kvm page fault handler Sean Christopherson
2021-06-10 12:45   ` Paolo Bonzini
2021-06-10 22:00     ` Isaku Yamahata
2021-07-29 16:48       ` David Matlack [this message]
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='CALzav=d2m+HffSLu5e3gz0cYk=MZ2uc1a3K+vP8VRVvLRiwd9g@mail.gmail.com' \
    --to=dmatlack@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=seanjc@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).