From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Wanpeng Li <kernellwp@gmail.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm <kvm@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Ben Gardon <bgardon@google.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH v2 07/17] KVM: x86/mmu: Check PDPTRs before allocating PAE roots
Date: Thu, 8 Apr 2021 15:48:28 +0000 [thread overview]
Message-ID: <YG8lzKqL32+JhY0Z@google.com> (raw)
In-Reply-To: <f6ae3dbb-cfa5-4d8b-26bf-92db6fc9eab1@redhat.com>
On Thu, Apr 08, 2021, Paolo Bonzini wrote:
> On 08/04/21 13:15, Wanpeng Li wrote:
> > I saw this splatting:
> >
> > BUG: sleeping function called from invalid context at
> > arch/x86/kvm/kvm_cache_regs.h:115
> > kvm_pdptr_read+0x20/0x60 [kvm]
> > kvm_mmu_load+0x3bd/0x540 [kvm]
> >
> > There is a might_sleep() in kvm_pdptr_read(), however, the original
> > commit didn't explain more. I can send a formal one if the below fix
> > is acceptable.
We don't want to drop mmu_lock, even temporarily. The reason for holding it
across the entire sequence is to ensure kvm_mmu_available_pages() isn't violated.
> I think we can just push make_mmu_pages_available down into
> kvm_mmu_load's callees. This way it's not necessary to hold the lock
> until after the PDPTR check:
...
> @@ -4852,14 +4868,10 @@ int kvm_mmu_load(struct kvm_vcpu *vcpu)
> r = mmu_alloc_special_roots(vcpu);
> if (r)
> goto out;
> - write_lock(&vcpu->kvm->mmu_lock);
> - if (make_mmu_pages_available(vcpu))
> - r = -ENOSPC;
> - else if (vcpu->arch.mmu->direct_map)
> + if (vcpu->arch.mmu->direct_map)
> r = mmu_alloc_direct_roots(vcpu);
> else
> r = mmu_alloc_shadow_roots(vcpu);
> - write_unlock(&vcpu->kvm->mmu_lock);
> if (r)
> goto out;
Freaking PDPTRs. I was really hoping we could keep the lock and pages_available()
logic outside of the helpers. What if kvm_mmu_load() reads the PDPTRs and
passes them into mmu_alloc_shadow_roots()? Or is that too ugly?
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index efb41f31e80a..e3c4938cd665 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3275,11 +3275,11 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
return 0;
}
-static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
+static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu, u64 pdptrs[4])
{
struct kvm_mmu *mmu = vcpu->arch.mmu;
- u64 pdptrs[4], pm_mask;
gfn_t root_gfn, root_pgd;
+ u64 pm_mask;
hpa_t root;
int i;
@@ -3291,11 +3291,8 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
if (mmu->root_level == PT32E_ROOT_LEVEL) {
for (i = 0; i < 4; ++i) {
- pdptrs[i] = mmu->get_pdptr(vcpu, i);
- if (!(pdptrs[i] & PT_PRESENT_MASK))
- continue;
-
- if (mmu_check_root(vcpu, pdptrs[i] >> PAGE_SHIFT))
+ if ((pdptrs[i] & PT_PRESENT_MASK) &&
+ mmu_check_root(vcpu, pdptrs[i] >> PAGE_SHIFT))
return 1;
}
}
@@ -4844,21 +4841,33 @@ EXPORT_SYMBOL_GPL(kvm_mmu_reset_context);
int kvm_mmu_load(struct kvm_vcpu *vcpu)
{
- int r;
+ struct kvm_mmu *mmu = vcpu->arch.mmu;
+ u64 pdptrs[4];
+ int r, i;
- r = mmu_topup_memory_caches(vcpu, !vcpu->arch.mmu->direct_map);
+ r = mmu_topup_memory_caches(vcpu, !mmu->direct_map);
if (r)
goto out;
r = mmu_alloc_special_roots(vcpu);
if (r)
goto out;
+
+ /*
+ * On SVM, reading PDPTRs might access guest memory, which might fault
+ * and thus might sleep. Grab the PDPTRs before acquiring mmu_lock.
+ */
+ if (!mmu->direct_map && mmu->root_level == PT32E_ROOT_LEVEL) {
+ for (i = 0; i < 4; ++i)
+ pdptrs[i] = mmu->get_pdptr(vcpu, i);
+ }
+
write_lock(&vcpu->kvm->mmu_lock);
if (make_mmu_pages_available(vcpu))
r = -ENOSPC;
else if (vcpu->arch.mmu->direct_map)
r = mmu_alloc_direct_roots(vcpu);
else
- r = mmu_alloc_shadow_roots(vcpu);
+ r = mmu_alloc_shadow_roots(vcpu, pdptrs);
write_unlock(&vcpu->kvm->mmu_lock);
if (r)
goto out;
next prev parent reply other threads:[~2021-04-08 15:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 1:10 [PATCH v2 00/17] KVM: x86/mmu: Lots of bug fixes Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 01/17] KVM: nSVM: Set the shadow root level to the TDP level for nested NPT Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 02/17] KVM: x86/mmu: Alloc page for PDPTEs when shadowing 32-bit NPT with 64-bit Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 03/17] KVM: x86/mmu: Capture 'mmu' in a local variable when allocating roots Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 04/17] KVM: x86/mmu: Allocate the lm_root before allocating PAE roots Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 05/17] KVM: x86/mmu: Allocate pae_root and lm_root pages in dedicated helper Sean Christopherson
2021-03-05 17:34 ` Paolo Bonzini
2021-03-05 1:10 ` [PATCH v2 06/17] KVM: x86/mmu: Ensure MMU pages are available when allocating roots Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 07/17] KVM: x86/mmu: Check PDPTRs before allocating PAE roots Sean Christopherson
2021-04-08 11:15 ` Wanpeng Li
2021-04-08 12:09 ` Paolo Bonzini
2021-04-08 15:48 ` Sean Christopherson [this message]
2021-04-08 15:57 ` Paolo Bonzini
2021-04-08 16:27 ` Sean Christopherson
2021-04-08 16:30 ` Paolo Bonzini
2021-03-05 1:10 ` [PATCH v2 08/17] KVM: x86/mmu: Fix and unconditionally enable WARNs to detect PAE leaks Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 09/17] KVM: x86/mmu: Use '0' as the one and only value for an invalid PAE root Sean Christopherson
2021-03-05 17:52 ` Paolo Bonzini
2021-03-05 18:22 ` Sean Christopherson
2021-03-05 18:23 ` Paolo Bonzini
2021-03-05 1:10 ` [PATCH v2 10/17] KVM: x86/mmu: Set the C-bit in the PDPTRs and LM pseudo-PDPTRs Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 11/17] KVM: x86/mmu: Mark the PAE roots as decrypted for shadow paging Sean Christopherson
2021-03-05 17:44 ` Paolo Bonzini
2021-03-05 18:02 ` Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 12/17] KVM: SVM: Don't strip the C-bit from CR2 on #PF interception Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 13/17] KVM: nVMX: Defer the MMU reload to the normal path on an EPTP switch Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 14/17] KVM: x86: Defer the MMU unload to the normal path on an global INVPCID Sean Christopherson
2021-03-05 1:10 ` [PATCH v2 15/17] KVM: x86/mmu: Unexport MMU load/unload functions Sean Christopherson
2021-03-05 1:11 ` [PATCH v2 16/17] KVM: x86/mmu: Sync roots after MMU load iff load as successful Sean Christopherson
2021-03-05 1:11 ` [PATCH v2 17/17] KVM: x86/mmu: WARN on NULL pae_root or lm_root, or bad shadow root level Sean Christopherson
2021-03-05 17:53 ` [PATCH v2 00/17] KVM: x86/mmu: Lots of bug fixes 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=YG8lzKqL32+JhY0Z@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=brijesh.singh@amd.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=thomas.lendacky@amd.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).