From: Andrew Cooper <andrew.cooper3@citrix.com>
To: seanjc@google.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
chengkev@google.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, pbonzini@redhat.com,
yosry.ahmed@linux.dev
Subject: Re: [PATCH 1/2] KVM: SVM: Generate #UD for certain instructions when SVME.EFER is disabled
Date: Tue, 6 Jan 2026 20:38:17 +0000 [thread overview]
Message-ID: <7a82aeec-7db5-4e06-abb4-9f041aaf2fb0@citrix.com> (raw)
In-Reply-To: <aV1StCzKWxAQ-B93@google.com>
> What about STGI? Per the APM, it #UDs if:
>
> Secure Virtual Machine was not enabled (EFER.SVME=0) and both of the following
> conditions were true:
> • SVM Lock is not available, as indicated by CPUID Fn8000_000A_EDX[SVML] = 0.
> • DEV is not available, as indicated by CPUID Fn8000_0001_ECX[SKINIT] = 0.
15.31 states this more clearly.
"On processors that support the SVM-Lock feature, SKINIT and STGI can be
executed even if EFER.SVME=0."
SKINIT is AMD's version of Intel TXT. The Secure Loader (15.27.1,
equivalent of the TXT ACM, left as an exercise to the programmer) is
started with GIF=0, and is expected to execute a single STGI instruction
when it's in a happy state to start taking interrupts.
SVM-Lock is a rough equivalent of Intel's
FEAT_CTRL.VMX_{IN,OUT}SIDE_SMX. I still don't understand why the TCG
insisted on there being a way to lock out hypervisor support when using
DTRM, but if you don't implement SVM Lock and SKINIT, then AFAICT STGI
has the same fault behaviour as CLGI,
Be aware that SVM was added in the K8 RevF, and SKINIT was added in
Fam10h RevC, 3 generations later, so there were CPUs which had SVM and
no SVM-Lock. It's not clear if there were CPUs with SVM-Lock but not
SKINIT, but given that it's enumerated separately, I expect there might be.
~Andrew
next prev parent reply other threads:[~2026-01-06 20:38 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 [this message]
2026-01-06 23:42 ` Yosry Ahmed
2026-01-06 23:48 ` Sean Christopherson
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=7a82aeec-7db5-4e06-abb4-9f041aaf2fb0@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=chengkev@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®