From: "Pratik R. Sampat" <prsampat@amd.com>
To: <kvm@vger.kernel.org>, <x86@kernel.org>, <linux-kernel@vger.kernel.org>
Cc: <tglx@kernel.org>, <mingo@redhat.com>, <bp@alien8.de>,
<dave.hansen@linux.intel.com>, <seanjc@google.com>,
<pbonzini@redhat.com>, <thomas.lendacky@amd.com>,
<kim.phillips@amd.com>, <nikunj@amd.com>, <michael.roth@amd.com>,
<ashish.kalra@amd.com>, <prsampat@amd.com>
Subject: [Patch v2 0/4] Introduce Enhanced SMT Protection for SEV-SNP
Date: Tue, 6 Oct 2026 16:54:57 +0000 [thread overview]
Message-ID: <cover.1791302373.git.prsampat@amd.com> (raw)
Enhanced SMT Protection (ESMTP) allows an SEV-SNP VM to require that,
while one of its vCPUs is in guest mode, every SMT sibling thread on
that physical core is either idle in host mode or running a vCPU the
guest itself has declared a legal sibling. This mitigates the
side-channel risk of sharing core resources with untrusted host threads
or with another guest.
Unlike core scheduling, where co-residency is a host kernel policy
expressed with cookies, ESMTP is enforced by hardware. The sibling mask
lives in the VMSA. The host is not trusted to run arbitrary kernel,
userspace, or interrupt-handling work on a sibling thread while an ESMTP
vCPU is active on that core.
Both KVM and the guest fully set the VCPU_SIBLING_MASK, which places
every vCPU of the guest in one group so that any two of them may be
co-resident. Combined with the ASID check, the sibling of a vCPU in
guest mode is then always either another vCPU of that same guest or a
thread idle in host mode.
Usage
-----
Requires patched OVMF [1] and QEMU [2] builds (unchanged from v1).
Launch an SEV-SNP guest with ESMTP enabled on the sev-snp-guest object:
-object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,esmtp=on
ESMTP is opt-in because it carries a performance cost as VMRUN stalls
until the sibling runs work from a trusted vCPU or is in host idle.
The guest reports the feature in dmesg among the SNP feature names:
# dmesg | grep -i SEV
... SEV-SNP ... ESMTProt ...
Empirical test
--------------
* Identify siblings via:
cat /sys/devices/system/cpu/cpuX/topology/thread_siblings_list
* Pin the guest on the siblings
* Spawn a load in the guest e.g. via stress-ng --cpu 2 for SMT=2.
Expect the guest utilization % for both sibling CPUs to be at 100% as
the vCPU siblings are deemed trusted
* Spawn a load in the host latched onto one of the siblings.
E.g. taskset -C X stress-ng --cpu 1
* Expect CPU X's utilization to be shared between host and guest %.
Also expect drop in CPU utilization on the thread Sibling CPU as when
the host task runs the guest will be forced idle.
Patches based on cryptodev-2.6
v2:
* Move idle wakeup ICR programming to svm_enable_virtualization_cpu()
instead of sev_hardware_setup() - Sashiko
* Remove cond_sched() in ESMTP exit paths - Sashiko
* Add a VMSA builing of ESMTP fields for hyperv - Sashiko
* Add ESMTP to SNP_FEATURES_IMPL and SNP_FEATURES_IMPL_REQ - Local
Claude Sashiko instance
* Cover hotplug CPUs / SMT changes by programming the ICR for all CPUs
- local Claude Sashiko instance
* Add esmtp timeout documentation to kernel paramters
Not syncing msr-index changes since several bits apart from ESMTP are
also changed and perf tooling maintainers generally sync that. However,
if needed I drop in a patch that syncs the MSRs too.
v1: https://lore.kernel.org/kvm/cover.1789399214.git.prsampat@amd.com
[1]: https://github.com/tianocore/edk2/pull/13128
[2]: https://lore.kernel.org/qemu-devel/cover.1789399242.git.prsampat@amd.com/
Pratik R. Sampat (4):
KVM: SVM: Re-queue events that were never injected
KVM: SVM: Add host support for Enhanced SMT Protection
x86/sev: Add guest support for Enhanced SMT Protection
x86/hyperv: Add guest support for Enhanced SMT Protection
.../admin-guide/kernel-parameters.txt | 19 ++++++++
arch/x86/boot/compressed/sev.c | 6 ++-
arch/x86/coco/sev/core.c | 13 +++++
arch/x86/hyperv/ivm.c | 11 +++++
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 5 +-
arch/x86/include/asm/svm.h | 12 ++++-
arch/x86/include/uapi/asm/svm.h | 9 +++-
arch/x86/kernel/cpu/scattered.c | 1 +
arch/x86/kvm/svm/sev.c | 48 ++++++++++++++++++-
arch/x86/kvm/svm/svm.c | 41 ++++++++++++++--
arch/x86/kvm/svm/svm.h | 2 +
12 files changed, 157 insertions(+), 11 deletions(-)
--
2.43.0
next reply other threads:[~2026-10-06 16:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 16:54 Pratik R. Sampat [this message]
2026-10-06 16:54 ` [Patch v2 1/4] KVM: SVM: Re-queue events that were never injected Pratik R. Sampat
2026-10-06 17:12 ` sashiko-bot
2026-10-09 19:21 ` Tom Lendacky
2026-10-06 16:54 ` [Patch v2 2/4] KVM: SVM: Add host support for Enhanced SMT Protection Pratik R. Sampat
2026-10-06 17:08 ` sashiko-bot
2026-10-09 19:05 ` Tom Lendacky
2026-10-09 19:40 ` Pratik R. Sampat
2026-10-09 20:05 ` Tom Lendacky
2026-10-06 16:55 ` [Patch v2 3/4] x86/sev: Add guest " Pratik R. Sampat
2026-10-06 17:03 ` sashiko-bot
2026-10-09 19:18 ` Tom Lendacky
2026-10-09 19:43 ` Pratik R. Sampat
2026-10-06 16:55 ` [Patch v2 4/4] x86/hyperv: " Pratik R. Sampat
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=cover.1791302373.git.prsampat@amd.com \
--to=prsampat@amd.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kim.phillips@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=x86@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.