All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Matlack <dmatlack@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Robert Hoo <robert.hu@linux.intel.com>,
	Greg Thelen <gthelen@google.com>, Ben Gardon <bgardon@google.com>,
	Mingwei Zhang <mizhang@google.com>
Subject: Re: [PATCH 4/5] KVM: x86/mmu: Don't install TDP MMU SPTE if SP has unexpected level
Date: Tue, 20 Dec 2022 10:24:22 -0800	[thread overview]
Message-ID: <Y6H91qfq24CaCi6l@google.com> (raw)
In-Reply-To: <Y5jBXIF26odk6jWC@google.com>

On Tue, Dec 13, 2022 at 06:15:56PM +0000, Sean Christopherson wrote:
> On Tue, Dec 13, 2022, David Matlack wrote:
> > On Mon, Dec 12, 2022 at 7:30 PM Sean Christopherson <seanjc@google.com> wrote:
> > >
> > > Don't install a leaf TDP MMU SPTE if the parent page's level doesn't
> > > match the target level of the fault, and instead have the vCPU retry the
> > > faulting instruction after warning.  Continuing on is completely
> > > unnecessary as the absolute worst case scenario of retrying is DoSing
> > > the vCPU, whereas continuing on all but guarantees bigger explosions, e.g.
> > 
> > Would it make sense to kill the VM instead via KVM_BUG()?
> 
> No, because if bug that hits this escapes to a release, odds are quite high that
> retrying will succeed.  E.g. the fix earlier in this series is for a rare corner
> case that I was able to hit consistently only by hacking KVM to effectively
> synchronize the page fault and zap.  Other than an extra page fault, no harm has
> been done to the guest, e.g. there's no need to kill the VM to protect it from
> data corruption.

Good points, agreed!

  reply	other threads:[~2022-12-20 18:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13  3:30 [PATCH 0/5] KVM: x86/mmu: TDP MMU fixes for 6.2 Sean Christopherson
2022-12-13  3:30 ` [PATCH 1/5] KVM: x86/mmu: Don't attempt to map leaf if target TDP MMU SPTE is frozen Sean Christopherson
2022-12-14 11:57   ` Robert Hoo
2022-12-13  3:30 ` [PATCH 2/5] KVM: x86/mmu: Map TDP MMU leaf SPTE iff target level is reached Sean Christopherson
2022-12-13  3:30 ` [PATCH 3/5] KVM: x86/mmu: Re-check under lock that TDP MMU SP hugepage is disallowed Sean Christopherson
2022-12-14 11:58   ` Robert Hoo
2022-12-15  0:11     ` Sean Christopherson
2022-12-15  6:26       ` Robert Hoo
2022-12-13  3:30 ` [PATCH 4/5] KVM: x86/mmu: Don't install TDP MMU SPTE if SP has unexpected level Sean Christopherson
2022-12-13 17:59   ` David Matlack
2022-12-13 18:15     ` Sean Christopherson
2022-12-20 18:24       ` David Matlack [this message]
2022-12-13  3:30 ` [PATCH 5/5] KVM: x86/mmu: Move kvm_tdp_mmu_map()'s prolog and epilog to its caller Sean Christopherson
2022-12-20 17:53   ` David Matlack
2022-12-21 18:32     ` Sean Christopherson
2022-12-29 19:51       ` David Matlack
2022-12-29 21:06         ` Paolo Bonzini
2023-01-03 22:21           ` David Matlack
2022-12-14 12:01 ` [PATCH 0/5] KVM: x86/mmu: TDP MMU fixes for 6.2 Robert Hoo
2022-12-14 15:48   ` Sean Christopherson
2022-12-23 17:32 ` 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=Y6H91qfq24CaCi6l@google.com \
    --to=dmatlack@google.com \
    --cc=bgardon@google.com \
    --cc=gthelen@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@linux.intel.com \
    --cc=seanjc@google.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.