From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry@kernel.org>
Cc: Yosry Ahmed <yosry.ahmed@linux.dev>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] KVM: SVM: Triple fault L1 on unintercepted EFER.SVME clear by L2
Date: Mon, 2 Mar 2026 14:48:21 -0800 [thread overview]
Message-ID: <aaYTtTBFmlzfb7tX@google.com> (raw)
In-Reply-To: <CAO9r8zPvQ1+_HGNuRZJuOTQ_YJHgMB=52-68rHFXKF8mWy6CNw@mail.gmail.com>
On Fri, Feb 27, 2026, Yosry Ahmed wrote:
> > > What if we key off vcpu->wants_to_run?
> >
> > That crossed my mind too.
> >
> > > It's less protection against false positives from things like
> > > kvm_vcpu_reset() if it didn't leave nested before clearing EFER, but
> > > more protection against the #VMEXIT case you mentioned. Also should be
> > > much lower on the fugliness scale imo.
> >
> > Yeah, I had pretty much the exact same thought process and assessment. I suggested
> > the WRMSR approach because I'm not sure how I feel about using wants_to_run for
> > functional behavior. But after realizing that hooking WRMSR won't handle RSM,
> > I'm solidly against my WRMSR idea.
> >
> > Honestly, I'm leaning slightly towards dropping this patch entirely since it's
> > not a bug fix. But I'm definitely not completely against it either. So what if
> > we throw it in, but plan on reverting if there are any more problems (that aren't
> > obviously due to goofs elsewhere in KVM).
>
> I am okay with that.
>
> >
> > Is this what you were thinking?
>
> Yeah, exactly.
Nice. No need for a v3, I'll fixup when applying (it might be a while before
this gets any "thanks", as I want to land it behind all of the stable@ fixes).
next prev parent reply other threads:[~2026-03-02 22:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 19:51 [PATCH v2 0/2] KVM: nSVM: Handle L2 clearing EFER.SVME properly Yosry Ahmed
2026-02-09 19:51 ` [PATCH v2 1/2] KVM: SVM: Triple fault L1 on unintercepted EFER.SVME clear by L2 Yosry Ahmed
2026-02-26 16:36 ` Yosry Ahmed
2026-02-26 18:20 ` Sean Christopherson
2026-02-27 20:03 ` Yosry Ahmed
2026-02-28 0:41 ` Sean Christopherson
2026-02-28 0:46 ` Yosry Ahmed
2026-03-02 22:48 ` Sean Christopherson [this message]
2026-02-09 19:51 ` [PATCH v2 2/2] KVM: selftests: Add a test for L2 clearing EFER.SVME without intercept Yosry Ahmed
2026-03-05 17:08 ` [PATCH v2 0/2] KVM: nSVM: Handle L2 clearing EFER.SVME properly 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=aaYTtTBFmlzfb7tX@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yosry.ahmed@linux.dev \
--cc=yosry@kernel.org \
/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.