kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 0/2] KVM: SEV: Improve GHCB Version Handling for SEV-ES/SEV-SNP
@ 2025-08-04  9:09 Nikunj A Dadhania
  2025-08-04  9:09 ` [PATCH v3 1/2] KVM: SEV: Drop GHCB_VERSION_DEFAULT and open code it Nikunj A Dadhania
  2025-08-04  9:09 ` [PATCH v3 2/2] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests Nikunj A Dadhania
  0 siblings, 2 replies; 5+ messages in thread
From: Nikunj A Dadhania @ 2025-08-04  9:09 UTC (permalink / raw)
  To: seanjc, pbonzini, kvm; +Cc: thomas.lendacky, santosh.shukla, nikunj

As discussed here[1]:

Refactor SEV's GHCB version handling to improve clarity and ABI stability.
* Set the default GHCB version (2) for SEV-ES guests earlier in the flow
* Remove the GHCB_VERSION_DEFAULT macro in favor of hardcoded values to
  prevent potential ABI issues
* Improve comments to better explain version requirements.
* Enforce minimum GHCB version for SEV-SNP guests.

Patches are based on kvm/next

1. https://lore.kernel.org/kvm/aHp9EGExmlq9Kx9T@google.com/

Nikunj A Dadhania (2):
  KVM: SEV: Drop GHCB_VERSION_DEFAULT and open code it
  KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests

 arch/x86/kvm/svm/sev.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)


base-commit: 196d9e72c4b0bd68b74a4ec7f52d248f37d0f030
-- 
2.43.0


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH v3 1/2] KVM: SEV: Drop GHCB_VERSION_DEFAULT and open code it
  2025-08-04  9:09 [PATCH v3 0/2] KVM: SEV: Improve GHCB Version Handling for SEV-ES/SEV-SNP Nikunj A Dadhania
@ 2025-08-04  9:09 ` Nikunj A Dadhania
  2025-08-04  9:09 ` [PATCH v3 2/2] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests Nikunj A Dadhania
  1 sibling, 0 replies; 5+ messages in thread
From: Nikunj A Dadhania @ 2025-08-04  9:09 UTC (permalink / raw)
  To: seanjc, pbonzini, kvm
  Cc: thomas.lendacky, santosh.shukla, nikunj, Michael Roth

Remove the GHCB_VERSION_DEFAULT macro and open code it with '2'. The macro
is used conditionally and is not a true default. KVM ABI does not
advertise/emumerates the default GHCB version. Any future change to this
macro would silently alter the ABI and potentially break existing
deployments that rely on the current behavior.

Additionally, move the GHCB version assignment earlier in the code flow and
update the comment to clarify that KVM_SEV_INIT2 defaults to version 2,
while KVM_SEV_INIT forces version 1.

No functional change intended.

Cc: Thomas Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
---
 arch/x86/kvm/svm/sev.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 2fbdebf79fbb..212f790eedd4 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -37,7 +37,6 @@
 #include "trace.h"
 
 #define GHCB_VERSION_MAX	2ULL
-#define GHCB_VERSION_DEFAULT	2ULL
 #define GHCB_VERSION_MIN	1ULL
 
 #define GHCB_HV_FT_SUPPORTED	(GHCB_HV_FT_SNP | GHCB_HV_FT_SNP_AP_CREATION)
@@ -421,6 +420,14 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
 	if (data->ghcb_version > GHCB_VERSION_MAX || (!es_active && data->ghcb_version))
 		return -EINVAL;
 
+	/*
+	 * KVM supports the full range of mandatory features defined by version
+	 * 2 of the GHCB protocol, so default to that for SEV-ES guests created
+	 * via KVM_SEV_INIT2 (KVM_SEV_INIT forces version 1).
+	 */
+	if (es_active && !data->ghcb_version)
+		data->ghcb_version = 2;
+
 	if (unlikely(sev->active))
 		return -EINVAL;
 
@@ -429,14 +436,6 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
 	sev->vmsa_features = data->vmsa_features;
 	sev->ghcb_version = data->ghcb_version;
 
-	/*
-	 * Currently KVM supports the full range of mandatory features defined
-	 * by version 2 of the GHCB protocol, so default to that for SEV-ES
-	 * guests created via KVM_SEV_INIT2.
-	 */
-	if (sev->es_active && !sev->ghcb_version)
-		sev->ghcb_version = GHCB_VERSION_DEFAULT;
-
 	if (vm_type == KVM_X86_SNP_VM)
 		sev->vmsa_features |= SVM_SEV_FEAT_SNP_ACTIVE;
 
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH v3 2/2] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests
  2025-08-04  9:09 [PATCH v3 0/2] KVM: SEV: Improve GHCB Version Handling for SEV-ES/SEV-SNP Nikunj A Dadhania
  2025-08-04  9:09 ` [PATCH v3 1/2] KVM: SEV: Drop GHCB_VERSION_DEFAULT and open code it Nikunj A Dadhania
@ 2025-08-04  9:09 ` Nikunj A Dadhania
  2025-08-19 18:28   ` Sean Christopherson
  1 sibling, 1 reply; 5+ messages in thread
From: Nikunj A Dadhania @ 2025-08-04  9:09 UTC (permalink / raw)
  To: seanjc, pbonzini, kvm
  Cc: thomas.lendacky, santosh.shukla, nikunj, Michael Roth

Require a minimum GHCB version of 2 when starting SEV-SNP guests through
KVM_SEV_INIT2. When a VMM attempts to start an SEV-SNP guest with an
incompatible GHCB version (less than 2), reject the request early rather
than allowing the guest kernel to start with an incorrect protocol version
and fail later with GHCB_SNP_UNSUPPORTED guest termination.

Hypervisor logs the guest termination with GHCB_SNP_UNSUPPORTED error code:

kvm_amd: SEV-ES guest requested termination: 0x0:0x2

SNP guest fails with the below error message:

KVM: unknown exit reason 24
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00a00f11
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000

Fixes: 4af663c2f64a ("KVM: SEV: Allow per-guest configuration of GHCB protocol version")
Cc: Thomas Lendacky <thomas.lendacky@amd.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>

---

Changes since
v2:
* Add new patch for removing GHCB_VERSION_DEFAULT

v1:
* Add failure logs in the commit and drop @stable tag (Sean)
---
 arch/x86/kvm/svm/sev.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 212f790eedd4..e88dce598785 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -405,6 +405,7 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
 	struct kvm_sev_info *sev = to_kvm_sev_info(kvm);
 	struct sev_platform_init_args init_args = {0};
 	bool es_active = vm_type != KVM_X86_SEV_VM;
+	bool snp_active = vm_type == KVM_X86_SNP_VM;
 	u64 valid_vmsa_features = es_active ? sev_supported_vmsa_features : 0;
 	int ret;
 
@@ -428,6 +429,9 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
 	if (es_active && !data->ghcb_version)
 		data->ghcb_version = 2;
 
+	if (snp_active && data->ghcb_version < 2)
+		return -EINVAL;
+
 	if (unlikely(sev->active))
 		return -EINVAL;
 
@@ -436,7 +440,7 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
 	sev->vmsa_features = data->vmsa_features;
 	sev->ghcb_version = data->ghcb_version;
 
-	if (vm_type == KVM_X86_SNP_VM)
+	if (snp_active)
 		sev->vmsa_features |= SVM_SEV_FEAT_SNP_ACTIVE;
 
 	ret = sev_asid_new(sev);
@@ -454,7 +458,7 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
 	}
 
 	/* This needs to happen after SEV/SNP firmware initialization. */
-	if (vm_type == KVM_X86_SNP_VM) {
+	if (snp_active) {
 		ret = snp_guest_req_init(kvm);
 		if (ret)
 			goto e_free;
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v3 2/2] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests
  2025-08-04  9:09 ` [PATCH v3 2/2] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests Nikunj A Dadhania
@ 2025-08-19 18:28   ` Sean Christopherson
  2025-08-20  5:29     ` Nikunj A. Dadhania
  0 siblings, 1 reply; 5+ messages in thread
From: Sean Christopherson @ 2025-08-19 18:28 UTC (permalink / raw)
  To: Nikunj A Dadhania
  Cc: pbonzini, kvm, thomas.lendacky, santosh.shukla, Michael Roth

On Mon, Aug 04, 2025, Nikunj A Dadhania wrote:
> Require a minimum GHCB version of 2 when starting SEV-SNP guests through
> KVM_SEV_INIT2. When a VMM attempts to start an SEV-SNP guest with an
> incompatible GHCB version (less than 2), reject the request early rather
> than allowing the guest kernel to start with an incorrect protocol version
> and fail later with GHCB_SNP_UNSUPPORTED guest termination.
> 
> Hypervisor logs the guest termination with GHCB_SNP_UNSUPPORTED error code:

s/Hypervisor/KVM, though I don't see any point in saying that KVM is doing
the logging, that's self-evident from the kvm_amd prefix.  Instead, I think
what's important to is to say the guest _typically_ requests termination,
because AFAICT nothing guarantees the guest will fail in this exact way.

  Not enforcing the minimum version typically causes the guest to request
  termination with GHCB_SNP_UNSUPPORTED error code:

    kvm_amd: SEV-ES guest requested termination: 0x0:0x2

> kvm_amd: SEV-ES guest requested termination: 0x0:0x2
> 
> SNP guest fails with the below error message:

This is QEMU output, not guest output.  I don't see any reason to capture this.
The fact that QEMU apparently doesn't handle KVM_EXIT_SYSTEM_EVENT isn't interesting.

> KVM: unknown exit reason 24
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=00a00f11
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
> EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0000 00000000 0000ffff 00009300
> CS =f000 ffff0000 0000ffff 00009b00
> SS =0000 00000000 0000ffff 00009300
> DS =0000 00000000 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT=     00000000 0000ffff
> IDT=     00000000 0000ffff
> CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
> DR6=00000000ffff0ff0 DR7=0000000000000400
> EFER=0000000000000000


No need for you to send a new version, I'm going to post a combined series for
this and Secure TSC.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v3 2/2] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests
  2025-08-19 18:28   ` Sean Christopherson
@ 2025-08-20  5:29     ` Nikunj A. Dadhania
  0 siblings, 0 replies; 5+ messages in thread
From: Nikunj A. Dadhania @ 2025-08-20  5:29 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: pbonzini, kvm, thomas.lendacky, santosh.shukla, Michael Roth



On 8/19/2025 11:58 PM, Sean Christopherson wrote:
> On Mon, Aug 04, 2025, Nikunj A Dadhania wrote:
>> Require a minimum GHCB version of 2 when starting SEV-SNP guests through
>> KVM_SEV_INIT2. When a VMM attempts to start an SEV-SNP guest with an
>> incompatible GHCB version (less than 2), reject the request early rather
>> than allowing the guest kernel to start with an incorrect protocol version
>> and fail later with GHCB_SNP_UNSUPPORTED guest termination.
>>
>> Hypervisor logs the guest termination with GHCB_SNP_UNSUPPORTED error code:
> 
> s/Hypervisor/KVM, though I don't see any point in saying that KVM is doing
> the logging, that's self-evident from the kvm_amd prefix.  Instead, I think
> what's important to is to say the guest _typically_ requests termination,
> because AFAICT nothing guarantees the guest will fail in this exact way.
> 
>   Not enforcing the minimum version typically causes the guest to request
>   termination with GHCB_SNP_UNSUPPORTED error code:
> 
>     kvm_amd: SEV-ES guest requested termination: 0x0:0x2

Looks good.

>> kvm_amd: SEV-ES guest requested termination: 0x0:0x2
>>
>> SNP guest fails with the below error message:
> 
> This is QEMU output, not guest output.  I don't see any reason to capture this.
> The fact that QEMU apparently doesn't handle KVM_EXIT_SYSTEM_EVENT isn't interesting.
> 
>> KVM: unknown exit reason 24
>> EAX=00000000 EBX=00000000 ECX=00000000 EDX=00a00f11
>> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
>> EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
>> ES =0000 00000000 0000ffff 00009300
>> CS =f000 ffff0000 0000ffff 00009b00
>> SS =0000 00000000 0000ffff 00009300
>> DS =0000 00000000 0000ffff 00009300
>> FS =0000 00000000 0000ffff 00009300
>> GS =0000 00000000 0000ffff 00009300
>> LDT=0000 00000000 0000ffff 00008200
>> TR =0000 00000000 0000ffff 00008b00
>> GDT=     00000000 0000ffff
>> IDT=     00000000 0000ffff
>> CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
>> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
>> DR6=00000000ffff0ff0 DR7=0000000000000400
>> EFER=0000000000000000
> 
> 
> No need for you to send a new version, I'm going to post a combined series for
> this and Secure TSC.

Thank you.

Regards
Nikunj

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-08-20  5:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-04  9:09 [PATCH v3 0/2] KVM: SEV: Improve GHCB Version Handling for SEV-ES/SEV-SNP Nikunj A Dadhania
2025-08-04  9:09 ` [PATCH v3 1/2] KVM: SEV: Drop GHCB_VERSION_DEFAULT and open code it Nikunj A Dadhania
2025-08-04  9:09 ` [PATCH v3 2/2] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests Nikunj A Dadhania
2025-08-19 18:28   ` Sean Christopherson
2025-08-20  5:29     ` Nikunj A. Dadhania

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).