[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a82aeec-7db5-4e06-abb4-9f041aaf2fb0@citrix.com>
Date: Tue, 6 Jan 2026 20:38:17 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: seanjc@...gle.com
Cc: Andrew Cooper <andrew.cooper3@...rix.com>, chengkev@...gle.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org, pbonzini@...hat.com,
yosry.ahmed@...ux.dev
Subject: Re: [PATCH 1/2] KVM: SVM: Generate #UD for certain instructions when
SVME.EFER is disabled
> 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
Powered by blists - more mailing lists