From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Kevin Cheng <chengkev@google.com>,
pbonzini@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: SVM: Generate #UD for certain instructions when SVME.EFER is disabled
Date: Tue, 6 Jan 2026 15:48:37 -0800 [thread overview]
Message-ID: <aV2fVaLBrtUsccHJ@google.com> (raw)
In-Reply-To: <5uwzlb3jvmebvienef5tw7cd6r4wgvtb5m5gu3wcaxh5sery3o@crh6m6cpuaqy>
On Tue, Jan 06, 2026, Yosry Ahmed wrote:
> On Tue, Jan 06, 2026 at 10:21:40AM -0800, Sean Christopherson wrote:
> > So rather than manually handle the intercepts in svm_set_efer() and fight recalcs,
> > trigger KVM_REQ_RECALC_INTERCEPTS and teach svm_recalc_instruction_intercepts()
> > about EFER.SVME handling.
> >
> > After the dust settles, it might make sense to move the #GP intercept logic into
> > svm_recalc_intercepts() as well, but that's not a priority.
>
> Unrelated question about the #GP intercept logic, it seems like if
> enable_vmware_backdoor is set, the #GP intercept will be set, even for
> SEV guests, which goes against the in svm_set_efer():
>
> /*
> * Never intercept #GP for SEV guests, KVM can't
> * decrypt guest memory to workaround the erratum.
> */
> if (svm_gp_erratum_intercept && !sev_guest(vcpu->kvm))
> set_exception_intercept(svm, GP_VECTOR);
>
> I initially thought if userspace sets enable_vmware_backdoor and runs
> SEV guests it's shooting itself in the foot, but given that
> enable_vmware_backdoor is a module parameter (i.e. global), isn't it
> possible that the host runs some SEV and some non-SEV VMs, where the
> non-SEV VMs require the vmware backdoor?
Commit 29de732cc95c ("KVM: SEV: Move SEV's GP_VECTOR intercept setup to SEV")
moved the override to sev_init_vmcb():
/*
* Don't intercept #GP for SEV guests, e.g. for the VMware backdoor, as
* KVM can't decrypt guest memory to decode the faulting instruction.
*/
clr_exception_intercept(svm, GP_VECTOR);
I.e. init_vmcb() will set the #GP intercept, then sev_init_vmcb() will immediately
clear it.
next prev parent reply other threads:[~2026-01-06 23:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-06 4:12 [PATCH 0/2] KVM: SVM: Align SVM with APM defined behaviors Kevin Cheng
2026-01-06 4:12 ` [PATCH 1/2] KVM: SVM: Generate #UD for certain instructions when SVME.EFER is disabled Kevin Cheng
2026-01-06 18:21 ` Sean Christopherson
2026-01-06 20:38 ` Andrew Cooper
2026-01-06 23:42 ` Yosry Ahmed
2026-01-06 23:48 ` Sean Christopherson [this message]
2026-01-07 0:04 ` Yosry Ahmed
2026-01-06 4:12 ` [PATCH 2/2] KVM: SVM: Raise #UD if VMMCALL instruction is not intercepted Kevin Cheng
2026-01-06 18:29 ` Sean Christopherson
2026-01-06 18:52 ` Andrew Cooper
2026-01-06 18:57 ` Sean Christopherson
2026-01-06 20:40 ` Andrew Cooper
2026-01-06 23:31 ` Yosry Ahmed
2026-01-06 23:38 ` Sean Christopherson
2026-01-07 0:02 ` Yosry Ahmed
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=aV2fVaLBrtUsccHJ@google.com \
--to=seanjc@google.com \
--cc=chengkev@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yosry.ahmed@linux.dev \
/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.