From: Sean Christopherson <seanjc@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Paolo Bonzini <pbonzini@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>,
Richard Herbert <rherbert@sympatico.ca>
Subject: Re: [PATCH 1/4] KVM: x86/mmu: Use -1 to flag an undefined spte in get_mmio_spte()
Date: Mon, 21 Dec 2020 09:05:03 -0800 [thread overview]
Message-ID: <X+DVv3/KjDn1+Iut@google.com> (raw)
In-Reply-To: <87tusjtrqp.fsf@vitty.brq.redhat.com>
On Fri, Dec 18, 2020, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@google.com> writes:
>
> > Return -1 from the get_walk() helpers if the shadow walk doesn't fill at
> > least one spte, which can theoretically happen if the walk hits a
> > not-present PTPDR. Returning the root level in such a case will cause
>
> PDPTR
Doh.
> > get_mmio_spte() to return garbage (uninitialized stack data). In
> > practice, such a scenario should be impossible as KVM shouldn't get a
> > reserved-bit page fault with a not-present PDPTR.
> >
> > Note, using mmu->root_level in get_walk() is wrong for other reasons,
> > too, but that's now a moot point.
> >
> > Fixes: 95fb5b0258b7 ("kvm: x86/mmu: Support MMIO in the TDP MMU")
> > Cc: Ben Gardon <bgardon@google.com>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> > arch/x86/kvm/mmu/mmu.c | 7 ++++++-
> > arch/x86/kvm/mmu/tdp_mmu.c | 2 +-
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index 7a6ae9e90bd7..a48cd12c01d7 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -3488,7 +3488,7 @@ static bool mmio_info_in_cache(struct kvm_vcpu *vcpu, u64 addr, bool direct)
> > static int get_walk(struct kvm_vcpu *vcpu, u64 addr, u64 *sptes)
> > {
> > struct kvm_shadow_walk_iterator iterator;
> > - int leaf = vcpu->arch.mmu->root_level;
> > + int leaf = -1;
> > u64 spte;
> >
> >
> > @@ -3532,6 +3532,11 @@ static bool get_mmio_spte(struct kvm_vcpu *vcpu, u64 addr, u64 *sptep)
> > else
> > leaf = get_walk(vcpu, addr, sptes);
> >
> > + if (unlikely(leaf < 0)) {
> > + *sptep = 0ull;
> > + return reserved;
> > + }
>
> When SPTE=0 is returned from get_mmio_spte(), handle_mmio_page_fault()
> will return RET_PF_RETRY -- should it be RET_PF_INVALID instead?
No, RET_PF_RETRY is the most appropriate. A pae_root entry will only be zero if
the corresponding guest PDPTR is !PRESENT, i.e. the page fault is effectively in
the guest context. The reason I say it should be an impossible condition is
because KVM should also reset the MMU whenever it snapshots the guest's PDPTRs,
i.e. it should be impossible to install a MMIO SPTE if the relevant PDPTR is
!PRESENT, and all MMIO SPTEs should be wiped out if the PDPTRs are reloaded.
I suppose by that argument, this should be a WARN_ON_ONCE, but I'm not sure if
I'm _that_ confident in my analysis :-)
Related side topic, this snippet in get_mmio_spte() is dead code, as the same
check is performed by its sole caller. I'll send a patch to remove it (unless
Paolo wants a v2 of this series, in which case I'll tack it on the end).
if (!VALID_PAGE(vcpu->arch.mmu->root_hpa)) {
*sptep = 0ull;
return reserved;
}
next prev parent reply other threads:[~2020-12-21 18:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-18 0:31 [PATCH 0/4] KVM: x86/mmu: Bug fixes and cleanups in get_mmio_spte() Sean Christopherson
2020-12-18 0:31 ` [PATCH 1/4] KVM: x86/mmu: Use -1 to flag an undefined spte " Sean Christopherson
2020-12-18 8:58 ` Vitaly Kuznetsov
2020-12-21 17:05 ` Sean Christopherson [this message]
2020-12-18 0:31 ` [PATCH 2/4] KVM: x86/mmu: Get root level from walkers when retrieving MMIO SPTE Sean Christopherson
2020-12-18 9:10 ` Vitaly Kuznetsov
2020-12-21 18:24 ` Paolo Bonzini
2020-12-21 18:30 ` Sean Christopherson
2020-12-18 0:31 ` [PATCH 3/4] KVM: x86/mmu: Use raw level to index into MMIO walks' sptes array Sean Christopherson
2020-12-18 9:18 ` Vitaly Kuznetsov
2020-12-18 0:31 ` [PATCH 4/4] KVM: x86/mmu: Optimize not-present/MMIO SPTE check in get_mmio_spte() Sean Christopherson
2020-12-18 9:33 ` Vitaly Kuznetsov
[not found] ` <2346556.XAFRqVoOGU@starbug.dom>
2020-12-18 1:27 ` [PATCH 0/4] KVM: x86/mmu: Bug fixes and cleanups " Richard Herbert
2020-12-21 18:26 ` 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=X+DVv3/KjDn1+Iut@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=rherbert@sympatico.ca \
--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.