From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.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,
Ben Gardon <bgardon@google.com>
Subject: Re: [PATCH 0/4] KVM: x86/mmu: Zap invalid TDP MMU roots when unmapping
Date: Wed, 15 Dec 2021 20:41:09 +0000 [thread overview]
Message-ID: <YbpS5UZdC/a5PgoO@google.com> (raw)
In-Reply-To: <b4295e77-aaf1-f0f5-cfd5-2a4fda923fb4@redhat.com>
On Wed, Dec 15, 2021, Paolo Bonzini wrote:
> On 12/15/21 02:15, Sean Christopherson wrote:
> > Patches 01-03 implement a bug fix by ensuring KVM zaps both valid and
> > invalid roots when unmapping a gfn range (including the magic "all" range).
> > Failure to zap invalid roots means KVM doesn't honor the mmu_notifier's
> > requirement that all references are dropped.
> >
> > set_nx_huge_pages() is the most blatant offender, as it doesn't elevate
> > mm_users and so a VM's entire mm can be released, but the same underlying
> > bug exists for any "unmap" command from the mmu_notifier in combination
> > with a memslot update. E.g. if KVM is deleting a memslot, and a
> > mmu_notifier hook acquires mmu_lock while it's dropped by
> > kvm_mmu_zap_all_fast(), the mmu_notifier hook will see the to-be-deleted
> > memslot but won't zap entries from the invalid roots.
> >
> > Patch 04 is cleanup to reuse the common iterator for walking _only_
> > invalid roots.
> >
> > Sean Christopherson (4):
> > KVM: x86/mmu: Use common TDP MMU zap helper for MMU notifier unmap
> > hook
> > KVM: x86/mmu: Move "invalid" check out of kvm_tdp_mmu_get_root()
> > KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU
> > KVM: x86/mmu: Use common iterator for walking invalid TDP MMU roots
> >
> > arch/x86/kvm/mmu/tdp_mmu.c | 116 +++++++++++++++++--------------------
> > arch/x86/kvm/mmu/tdp_mmu.h | 3 -
> > 2 files changed, 53 insertions(+), 66 deletions(-)
> >
>
> Queued 1-3 for 5.16 and 4 for 5.17.
Actually, can you please unqueue patch 4? I think we can actually kill off
kvm_tdp_mmu_zap_invalidated_roots() entirely. I don't know if that code will be
ready for 5.17, but if it is then this patch is unnecesary. And if not, it
shouldn't be difficult to re-queue this a bit later.
Thanks!
next prev parent reply other threads:[~2021-12-15 20:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-15 1:15 [PATCH 0/4] KVM: x86/mmu: Zap invalid TDP MMU roots when unmapping Sean Christopherson
2021-12-15 1:15 ` [PATCH 1/4] KVM: x86/mmu: Use common TDP MMU zap helper for MMU notifier unmap hook Sean Christopherson
2021-12-15 1:15 ` [PATCH 2/4] KVM: x86/mmu: Move "invalid" check out of kvm_tdp_mmu_get_root() Sean Christopherson
2021-12-15 1:15 ` [PATCH 3/4] KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU Sean Christopherson
2021-12-15 1:15 ` [PATCH 4/4] KVM: x86/mmu: Use common iterator for walking invalid TDP MMU roots Sean Christopherson
2021-12-15 17:20 ` [PATCH 0/4] KVM: x86/mmu: Zap invalid TDP MMU roots when unmapping Paolo Bonzini
2021-12-15 20:41 ` Sean Christopherson [this message]
2021-12-16 0:44 ` Sean Christopherson
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=YbpS5UZdC/a5PgoO@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--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.