From: Tom Lendacky <thomas.lendacky@amd.com>
To: <kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <x86@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
Michael Roth <michael.roth@amd.com>
Subject: [PATCH 0/2] Remove some hardcoded SEV-SNP guest policy checks during guest launch
Date: Thu, 29 May 2025 16:17:58 -0500 [thread overview]
Message-ID: <cover.1748553480.git.thomas.lendacky@amd.com> (raw)
This series removes some guest policy checks that can be better controlled
by the SEV firmware.
- Remove the check for the SMT policy bit. Currently, a check is made to
ensure the SMT policy bit is set to 1. However, there is no reason for
KVM to do this. The SMT policy bit, when 0, is used to ensure that SMT
has been disabled *in the BIOS.* As this does not require any special
support within KVM, the check can be safely removed to allow the SEV
firmware to determine whether the system meets the policy.
- Remove the check for the SINGLE_SOCKET policy bit. Currently, a check
is made to ensure the SINGLE_SOCKET policy bit is set to 0. However,
there is no reason for KVM to do this. The SINGLE_SOCKET policy bit,
when 1, is used to ensure that an SNP guest is only run on a single
socket. When the system only consists of a single socket, the SEV
firmware allows guest activation to succeed. However, if the system
has more than one socket, the SEV firmware will fail guest activation
when the SNP_ACTIVATE command is used (which is the activation command
used by KVM).
The SMT policy patch should not be controversial. The SINGLE_SOCKET policy
patch could be a bit controversial, since, when you have the SINGLE_SOCKET
policy bit set, you can have a guest that can run without issue on a
single socket system, but suddenly fail when attempted to be started on a
system with more than one socket. But, as this is opt-in behavior from
userspace, this could be viewed as providing the protection that the guest
owner desires.
In order to support use of the SINGLE_SOCKET policy bit on a system with
more than one socket, the SNP_ACTIVATE_EX command must be used and proper
scheduling support performed.
The series is based off of:
https://github.com/kvm-x86/linux.git next
Tom Lendacky (2):
KVM: SVM: Allow SNP guest policy disallow running with SMT enabled
KVM: SVM: Allow SNP guest policy to specify SINGLE_SOCKET
arch/x86/kvm/svm/sev.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
base-commit: 3f7b307757ecffc1c18ede9ee3cf9ce8101f3cc9
--
2.46.2
next reply other threads:[~2025-05-29 21:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-29 21:17 Tom Lendacky [this message]
2025-05-29 21:17 ` [PATCH 1/2] KVM: SVM: Allow SNP guest policy disallow running with SMT enabled Tom Lendacky
2025-05-29 21:18 ` [PATCH 2/2] KVM: SVM: Allow SNP guest policy to specify SINGLE_SOCKET Tom Lendacky
2025-06-24 19:38 ` [PATCH 0/2] Remove some hardcoded SEV-SNP guest policy checks during guest launch Sean Christopherson
2025-06-24 20:31 ` Tom Lendacky
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.1748553480.git.thomas.lendacky@amd.com \
--to=thomas.lendacky@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--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.