All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Junaid Shahid <junaids@google.com>
Subject: Re: [PATCH v2 0/8] KVM: x86/mmu: ITLB multi-hit workaround fixes
Date: Fri, 25 Sep 2020 23:27:15 +0200	[thread overview]
Message-ID: <4eec29f9-def0-3292-4a88-1f6ff3e06b5e@redhat.com> (raw)
In-Reply-To: <20200923183735.584-1-sean.j.christopherson@intel.com>

On 23/09/20 20:37, Sean Christopherson wrote:
> Patch 1 is a minor fix for a very theoretical bug where KVM could skip
> the final "commit zap" when recovering shadow pages for the NX huge
> page mitigation.
> 
> Patch 2 is cleanup that's made possible by patch 1.
> 
> Patches 3-5 are the main course and fix bugs in the NX huge page
> accounting where shadow pages are incorrectly added to the list of
> disallowed huge pages.  KVM doesn't actually check to see if the page
> could actually have been a large page when adding to the disallowed list.
> This result in what are effectively spurious zaps.  The biggest issue is
> likely with shadow pages in the upper levels, i.e. levels 3 and 4, as they
> are either unlikely to be huge (1gb) or flat out can't be huge (512tb).
> And because of the way KVM zaps, the upper levels will be zapped first,
> i.e. KVM is likely zapping and rebuilding a decent number of its shadow
> pages for zero benefit.
> 
> Ideally, patches 3-5 would be a single patch to ease backporting.  In the
> end, I decided the change is probably not suitable for stable as at worst
> it creates an infrequent performance spike (assuming the admin isn't going
> crazy with the recovery frequency), and it's far from straightforward or
> risk free.  Cramming everything into a single patch was a mess.
> 
> Patches 6-8 are cleanups in related code.  The 'hlevel' name in particular
> has been on my todo list for a while.
> 
> v2:
>   - Rebased to kvm/queue, commit e1ba1a15af73 ("KVM: SVM: Enable INVPCID
>     feature on AMD").
> 
> Sean Christopherson (8):
>   KVM: x86/mmu: Commit zap of remaining invalid pages when recovering
>     lpages
>   KVM: x86/mmu: Refactor the zap loop for recovering NX lpages
>   KVM: x86/mmu: Move "huge page disallowed" calculation into mapping
>     helpers
>   KVM: x86/mmu: Capture requested page level before NX huge page
>     workaround
>   KVM: x86/mmu: Account NX huge page disallowed iff huge page was
>     requested
>   KVM: x86/mmu: Rename 'hlevel' to 'level' in FNAME(fetch)
>   KVM: x86/mmu: Hoist ITLB multi-hit workaround check up a level
>   KVM: x86/mmu: Track write/user faults using bools
> 
>  arch/x86/kvm/mmu/mmu.c         | 58 +++++++++++++++++++++-------------
>  arch/x86/kvm/mmu/paging_tmpl.h | 39 ++++++++++++-----------
>  2 files changed, 57 insertions(+), 40 deletions(-)
> 

Queued, thanks.

Paolo


      parent reply	other threads:[~2020-09-25 21:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 18:37 [PATCH v2 0/8] KVM: x86/mmu: ITLB multi-hit workaround fixes Sean Christopherson
2020-09-23 18:37 ` [PATCH v2 1/8] KVM: x86/mmu: Commit zap of remaining invalid pages when recovering lpages Sean Christopherson
2020-09-23 18:37 ` [PATCH v2 4/8] KVM: x86/mmu: Capture requested page level before NX huge page workaround Sean Christopherson
2020-09-23 18:37 ` [PATCH v2 5/8] KVM: x86/mmu: Account NX huge page disallowed iff huge page was requested Sean Christopherson
2020-09-23 18:37 ` [PATCH v2 6/8] KVM: x86/mmu: Rename 'hlevel' to 'level' in FNAME(fetch) Sean Christopherson
2020-09-25 21:25   ` Paolo Bonzini
2020-09-23 18:37 ` [PATCH v2 7/8] KVM: x86/mmu: Hoist ITLB multi-hit workaround check up a level Sean Christopherson
2020-09-23 18:37 ` [PATCH v2 8/8] KVM: x86/mmu: Track write/user faults using bools Sean Christopherson
2020-09-25 21:27 ` Paolo Bonzini [this message]

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=4eec29f9-def0-3292-4a88-1f6ff3e06b5e@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=junaids@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sean.j.christopherson@intel.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.