From: Sean Christopherson <seanjc@google.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Reima Ishii <ishiir@g.ecc.u-tokyo.ac.jp>
Subject: Re: [PATCH 5/5] KVM: x86/mmu: Use dummy root, backed by zero page, for !visible guest roots
Date: Tue, 25 Jul 2023 08:53:19 -0700 [thread overview]
Message-ID: <ZL/v7xDEllr5rU6W@google.com> (raw)
In-Reply-To: <20230725113628.z7vzxk5g6zdqlftg@linux.intel.com>
On Tue, Jul 25, 2023, Yu Zhang wrote:
> > diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
> > index 122bfc0124d3..e9d4d7b66111 100644
> > --- a/arch/x86/kvm/mmu/paging_tmpl.h
> > +++ b/arch/x86/kvm/mmu/paging_tmpl.h
> > @@ -646,6 +646,17 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault,
> > if (WARN_ON(!VALID_PAGE(vcpu->arch.mmu->root.hpa)))
> > goto out_gpte_changed;
> >
> > + /*
> > + * Load a new root and retry the faulting instruction in the extremely
> > + * unlikely scenario that the guest root gfn became visible between
> > + * loading a dummy root and handling the resulting page fault, e.g. if
> > + * userspace create a memslot in the interim.
> > + */
> > + if (unlikely(kvm_mmu_is_dummy_root(vcpu->arch.mmu->root.hpa))) {
> > + kvm_mmu_unload(vcpu);
>
> Do we really need a kvm_mmu_unload()? Could we just set
> vcpu->arch.mmu->root.hpa to INVALID_PAGE here?
Oof, yeah. Not only is a full unload overkill, if this code were hit it would
lead to deadlock because kvm_mmu_free_roots() expects to be called *without*
mmu_lock held.
Hmm, but I don't love the idea of open coding a free/reset of the current root.
I'm leaning toward
kvm_make_request(KVM_REQ_MMU_FREE_OBSOLETE_ROOTS, vcpu);
since it's conceptually similar to KVM unloading roots when a memslot is deleted
or moved, just reversed. That would obviously tie this code to KVM's handling of
the dummy root just as much as manually invalidating root.hpa (probably more so),
but that might actually be a good thing because then the rule for the dummy root
is that it's always considered obsolete (when checked), and that could be
explicitly documented in is_obsolete_root().
next prev parent reply other threads:[~2023-07-25 15:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-22 1:23 [PATCH 0/5] KVM: x86/mmu: Don't synthesize triple fault on bad root Sean Christopherson
2023-07-22 1:23 ` [PATCH 1/5] KVM: x86/mmu: Add helper to convert root hpa to shadow page Sean Christopherson
2023-07-22 1:23 ` [PATCH 2/5] KVM: x86/mmu: Harden new PGD against roots without shadow pages Sean Christopherson
2023-07-22 1:23 ` [PATCH 3/5] KVM: x86/mmu: Harden TDP MMU iteration against root w/o shadow page Sean Christopherson
2023-07-25 10:39 ` Yu Zhang
2023-07-25 15:56 ` Sean Christopherson
2023-07-26 3:55 ` Yu Zhang
2023-07-22 1:23 ` [PATCH 4/5] KVM: x86/mmu: Disallow guest from using !visible slots for page tables Sean Christopherson
2023-07-22 1:23 ` [PATCH 5/5] KVM: x86/mmu: Use dummy root, backed by zero page, for !visible guest roots Sean Christopherson
2023-07-25 11:36 ` Yu Zhang
2023-07-25 15:53 ` Sean Christopherson [this message]
2023-07-26 9:20 ` Yu Zhang
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=ZL/v7xDEllr5rU6W@google.com \
--to=seanjc@google.com \
--cc=ishiir@g.ecc.u-tokyo.ac.jp \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yu.c.zhang@linux.intel.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).