All of lore.kernel.org
 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>,
	kvm list <kvm@vger.kernel.org>, Kai Huang <kai.huang@intel.com>,
	Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH v2 08/10] KVM: x86/mmu: Split out TDP MMU page fault handling
Date: Tue, 20 Sep 2022 14:17:20 -0700	[thread overview]
Message-ID: <Yyot4L75h2ShPSaG@google.com> (raw)
In-Reply-To: <CALzav=fg8xonNUkbFcep6kcVcBGtsp2RRW0_NKUL8DhdbQbRPA@mail.gmail.com>

On Thu, Sep 01, 2022 at 09:50:10AM -0700, David Matlack wrote:
> On Tue, Aug 30, 2022 at 4:57 PM Isaku Yamahata <isaku.yamahata@gmail.com> wrote:
> > On Fri, Aug 26, 2022 at 04:12:25PM -0700, David Matlack <dmatlack@google.com> wrote:
> > >  int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
> > >  {
> > >       /*
> > > @@ -4355,6 +4384,11 @@ int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
> > >               }
> > >       }
> > >
> > > +#ifdef CONFIG_X86_64
> > > +     if (tdp_mmu_enabled)
> > > +             return kvm_tdp_mmu_page_fault(vcpu, fault);
> > > +#endif
> > > +
> > >       return direct_page_fault(vcpu, fault);
> > >  }
> >
> > Now we mostly duplicated page_fault method.  We can go one step further.
> > kvm->arch.mmu.page_fault can be set for each case.  Maybe we can do it later
> > if necessary.
> 
> Hm, interesting idea. We would have to refactor the MTRR max_level
> code in kvm_tdp_page_fault() into a helper function, but otherwise
> that idea would work. I will give it a try in the next version.

So I took a stab at this. Refactoring the max_level adjustment for MTRRs
into a helper function is easy of course. But changing page_fault also
requires changes in kvm_mmu_do_page_fault() for CONFIG_RETPOLINE and
fault->is_tdp. I'm not saying it's not possible (it definitely is) but
it's not trivial to do it in a clean way, so I suggest we table this for
the time being.

  reply	other threads:[~2022-09-20 21:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 23:12 [PATCH v2 00/10] KVM: x86/mmu: Make tdp_mmu read-only and clean up TPD MMU fault handler David Matlack
2022-08-26 23:12 ` [PATCH v2 01/10] KVM: x86/mmu: Change tdp_mmu to a read-only parameter David Matlack
2022-08-30 10:12   ` Huang, Kai
2022-09-01 16:47     ` David Matlack
2022-09-20 16:57       ` David Matlack
2022-09-20 17:16         ` Sean Christopherson
2022-09-20 21:01         ` Huang, Kai
2022-09-20 21:13           ` David Matlack
2022-08-26 23:12 ` [PATCH v2 02/10] KVM: x86/mmu: Move TDP MMU VM init/uninit behind tdp_mmu_enabled David Matlack
2022-08-26 23:12 ` [PATCH v2 03/10] KVM: x86/mmu: Grab mmu_invalidate_seq in kvm_faultin_pfn() David Matlack
2022-08-26 23:12 ` [PATCH v2 04/10] KVM: x86/mmu: Handle error PFNs " David Matlack
2022-08-30 23:45   ` Isaku Yamahata
2022-09-01 16:48     ` David Matlack
2022-08-26 23:12 ` [PATCH v2 05/10] KVM: x86/mmu: Avoid memslot lookup during KVM_PFN_ERR_HWPOISON handling David Matlack
2022-08-26 23:12 ` [PATCH v2 06/10] KVM: x86/mmu: Handle no-slot faults in kvm_faultin_pfn() David Matlack
2022-08-26 23:12 ` [PATCH v2 07/10] KVM: x86/mmu: Initialize fault.{gfn,slot} earlier for direct MMUs David Matlack
2022-08-26 23:12 ` [PATCH v2 08/10] KVM: x86/mmu: Split out TDP MMU page fault handling David Matlack
2022-08-30 23:57   ` Isaku Yamahata
2022-09-01 16:50     ` David Matlack
2022-09-20 21:17       ` David Matlack [this message]
2022-09-21 23:43         ` Isaku Yamahata
2022-08-26 23:12 ` [PATCH v2 09/10] KVM: x86/mmu: Stop needlessly making MMU pages available for TDP MMU faults David Matlack
2022-08-26 23:12 ` [PATCH v2 10/10] KVM: x86/mmu: Rename __direct_map() to direct_map() David Matlack

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=Yyot4L75h2ShPSaG@google.com \
    --to=dmatlack@google.com \
    --cc=isaku.yamahata@gmail.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=seanjc@google.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.