arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/svm.h | 1 + arch/x86/kvm/svm/sev.c | 108 ++++++++++++++++++++--------- arch/x86/kvm/svm/svm.c | 37 +++------- arch/x86/kvm/svm/svm.h | 7 +- 5 files changed, 92 insertions(+), 62 deletions(-)
This is a combination of Nikunk's series to enable secure TSC support and to
fix the GHCB version issues, along with some code refactorings to move SEV+
setup code into sev.c (we've managed to grow something like 4 flows that all
do more or less the same thing).
Note, I haven't tested SNP functionality in any way.
v11:
- Shuffle code around so that snp_is_secure_tsc_enabled() doesn't need to
be exposed outside of sev.c.
- Explicitly modify the intercept for MSR_AMD64_GUEST_TSC_FREQ (paranoia is
cheap in this case).
- Trim the changelog for the GHCB version enforcement patch.
- Continue on with snp_launch_start() if default_tsc_khz is '0'. AFAICT,
continuing on doesn't put the host at (any moer) risk. [Kai]
v10: https://lore.kernel.org/all/20250804103751.7760-1-nikunj@amd.com
v3 (GHCB): https://lore.kernel.org/all/20250804090945.267199-1-nikunj@amd.com
Nikunj A Dadhania (4):
KVM: SEV: Drop GHCB_VERSION_DEFAULT and open code it
KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests
x86/cpufeatures: Add SNP Secure TSC
KVM: SVM: Enable Secure TSC for SNP guests
Sean Christopherson (4):
KVM: SVM: Move SEV-ES VMSA allocation to a dedicated sev_vcpu_create()
helper
KVM: SEV: Move init of SNP guest state into sev_init_vmcb()
KVM: SEV: Set RESET GHCB MSR value during sev_es_init_vmcb()
KVM: SEV: Fold sev_es_vcpu_reset() into sev_vcpu_create()
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/svm.h | 1 +
arch/x86/kvm/svm/sev.c | 108 ++++++++++++++++++++---------
arch/x86/kvm/svm/svm.c | 37 +++-------
arch/x86/kvm/svm/svm.h | 7 +-
5 files changed, 92 insertions(+), 62 deletions(-)
base-commit: c17b750b3ad9f45f2b6f7e6f7f4679844244f0b9
--
2.51.0.rc1.167.g924127e9c0-goog
On 8/20/2025 5:18 AM, Sean Christopherson wrote:
> This is a combination of Nikunk's series to enable secure TSC support and to
*Nikunj's 😊 (close though!)
> fix the GHCB version issues, along with some code refactorings to move SEV+
> setup code into sev.c (we've managed to grow something like 4 flows that all
> do more or less the same thing).
>
> Note, I haven't tested SNP functionality in any way.
Tested SNP with and without Secure TSC, guest works as expected.
>
> v11:
> - Shuffle code around so that snp_is_secure_tsc_enabled() doesn't need to
> be exposed outside of sev.c.
> - Explicitly modify the intercept for MSR_AMD64_GUEST_TSC_FREQ (paranoia is
> cheap in this case).
> - Trim the changelog for the GHCB version enforcement patch.
> - Continue on with snp_launch_start() if default_tsc_khz is '0'. AFAICT,
> continuing on doesn't put the host at (any moer) risk. [Kai]
If I hack default_tsc_khz as '0', SNP guest kernel with SecureTSC spits out
couple of warnings and finally panics:
Persistent clock returned invalid value
------------[ cut here ]------------
Missing cycle counter and fallback timer; RNG entropy collection will consequently suffer.
WARNING: CPU: 0 PID: 0 at drivers/char/random.c:931 random_init+0xe7/0xf0
RIP: 0010:random_init+0xe7/0xf0
Call Trace:
<TASK>
start_kernel+0x5e9/0xb80
x86_64_start_reservations+0x18/0x30
x86_64_start_kernel+0xf5/0x140
common_startup_64+0x13e/0x141
</TASK>
...
WARNING: CPU: 0 PID: 0 at arch/x86/kernel/tsc.c:1464 determine_cpu_tsc_frequencies+0x118/0x120
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.17.0-rc2-stsc+ #1063 PREEMPT(voluntary)
RIP: 0010:determine_cpu_tsc_frequencies+0x118/0x120
Call Trace:
<TASK>
tsc_init+0x2ba/0x430
x86_late_time_init+0x29/0x40
start_kernel+0x70b/0xb80
x86_64_start_reservations+0x18/0x30
x86_64_start_kernel+0xf5/0x140
common_startup_64+0x13e/0x141
</TASK>
...
Oops: divide error: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.17.0-rc2-stsc+ #1063 PREEMPT(voluntary)
Tainted: [W]=WARN
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
RIP: 0010:pit_hpet_ptimer_calibrate_cpu+0x1be/0x410
Call Trace:
<TASK>
determine_cpu_tsc_frequencies+0xc1/0x120
tsc_init+0x2ba/0x430
x86_late_time_init+0x29/0x40
start_kernel+0x70b/0xb80
x86_64_start_reservations+0x18/0x30
x86_64_start_kernel+0xf5/0x140
common_startup_64+0x13e/0x141
</TASK>
Regards,
Nikunj
On Wed, 2025-08-20 at 14:18 +0530, Nikunj A. Dadhania wrote: > > - Continue on with snp_launch_start() if default_tsc_khz is '0'. AFAICT, > > continuing on doesn't put the host at (any moer) risk. [Kai] > > If I hack default_tsc_khz as '0', SNP guest kernel with SecureTSC spits out > couple of warnings and finally panics: > It's a surprise that the SEV_CMD_SNP_LAUNCH_START didn't fail in such configuration. :-)
On 8/20/2025 4:55 PM, Huang, Kai wrote: > On Wed, 2025-08-20 at 14:18 +0530, Nikunj A. Dadhania wrote: >>> - Continue on with snp_launch_start() if default_tsc_khz is '0'. AFAICT, >>> continuing on doesn't put the host at (any moer) risk. [Kai] >> >> If I hack default_tsc_khz as '0', SNP guest kernel with SecureTSC spits out >> couple of warnings and finally panics: >> > > It's a surprise that the SEV_CMD_SNP_LAUNCH_START didn't fail in such > configuration. :-) As mentioned here[1], this is an unsupported configuration as per the SNP Firmware ABI. Regards, Nikunj 1. https://lore.kernel.org/all/c3e638e9-631f-47af-b0d2-06cea949ec1e@amd.com/
On Wed, Aug 20, 2025, Nikunj A. Dadhania wrote: > On 8/20/2025 4:55 PM, Huang, Kai wrote: > > On Wed, 2025-08-20 at 14:18 +0530, Nikunj A. Dadhania wrote: > >>> - Continue on with snp_launch_start() if default_tsc_khz is '0'. AFAICT, > >>> continuing on doesn't put the host at (any moer) risk. [Kai] > >> > >> If I hack default_tsc_khz as '0', SNP guest kernel with SecureTSC spits out > >> couple of warnings and finally panics: > >> > > > > It's a surprise that the SEV_CMD_SNP_LAUNCH_START didn't fail in such > > configuration. :-) > > As mentioned here[1], this is an unsupported configuration as per the SNP > Firmware ABI. Yeah, but outside of AMD hardware/firmware, the usual response to an unsupported configuration is to return an error :-D Anyways, I'll fixup to the -EINVAL version from v10 when applying.
On Tue, 19 Aug 2025 16:48:25 -0700, Sean Christopherson wrote:
> This is a combination of Nikunk's series to enable secure TSC support and to
> fix the GHCB version issues, along with some code refactorings to move SEV+
> setup code into sev.c (we've managed to grow something like 4 flows that all
> do more or less the same thing).
>
> Note, I haven't tested SNP functionality in any way.
>
> [...]
Applied to kvm-x86 svm. Nikunj, can you give this one last sanity check when
you get the chance? No rush. I moved the "!kvm->arch.default_tsc_khz" check
up slightly so that it could use a direct return instead of a goto, just want
to make sure I didn't pull a stupid.
Thanks!
[1/8] KVM: SEV: Drop GHCB_VERSION_DEFAULT and open code it
https://github.com/kvm-x86/linux/commit/c78af20374a1
[2/8] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests
https://github.com/kvm-x86/linux/commit/00f0b959ffb0
[3/8] x86/cpufeatures: Add SNP Secure TSC
https://github.com/kvm-x86/linux/commit/7b59c73fd611
[4/8] KVM: SVM: Move SEV-ES VMSA allocation to a dedicated sev_vcpu_create() helper
https://github.com/kvm-x86/linux/commit/34bd82aab15b
[5/8] KVM: SEV: Move init of SNP guest state into sev_init_vmcb()
https://github.com/kvm-x86/linux/commit/3d4e882e3439
[6/8] KVM: SEV: Set RESET GHCB MSR value during sev_es_init_vmcb()
https://github.com/kvm-x86/linux/commit/baf6ed177290
[7/8] KVM: SEV: Fold sev_es_vcpu_reset() into sev_vcpu_create()
https://github.com/kvm-x86/linux/commit/f7b1f0c1620d
[8/8] KVM: SVM: Enable Secure TSC for SNP guests
https://github.com/kvm-x86/linux/commit/a311fce2b694
--
https://github.com/kvm-x86/linux/tree/next
On 8/22/2025 3:05 AM, Sean Christopherson wrote: > On Tue, 19 Aug 2025 16:48:25 -0700, Sean Christopherson wrote: >> This is a combination of Nikunk's series to enable secure TSC support and to >> fix the GHCB version issues, along with some code refactorings to move SEV+ >> setup code into sev.c (we've managed to grow something like 4 flows that all >> do more or less the same thing). >> >> Note, I haven't tested SNP functionality in any way. >> >> [...] > > Applied to kvm-x86 svm. Thanks Sean ! > Nikunj, can you give this one last sanity check when > you get the chance? No rush. I moved the "!kvm->arch.default_tsc_khz" check > up slightly so that it could use a direct return instead of a goto, just want > to make sure I didn't pull a stupid. Tested the branch with SEV, SEV-ES, SNP and SNP with SecureTSC guests, working as expected. > > Thanks! > > [1/8] KVM: SEV: Drop GHCB_VERSION_DEFAULT and open code it > https://github.com/kvm-x86/linux/commit/c78af20374a1 > [2/8] KVM: SEV: Enforce minimum GHCB version requirement for SEV-SNP guests > https://github.com/kvm-x86/linux/commit/00f0b959ffb0 > [3/8] x86/cpufeatures: Add SNP Secure TSC > https://github.com/kvm-x86/linux/commit/7b59c73fd611 > [4/8] KVM: SVM: Move SEV-ES VMSA allocation to a dedicated sev_vcpu_create() helper > https://github.com/kvm-x86/linux/commit/34bd82aab15b > [5/8] KVM: SEV: Move init of SNP guest state into sev_init_vmcb() > https://github.com/kvm-x86/linux/commit/3d4e882e3439 > [6/8] KVM: SEV: Set RESET GHCB MSR value during sev_es_init_vmcb() > https://github.com/kvm-x86/linux/commit/baf6ed177290 > [7/8] KVM: SEV: Fold sev_es_vcpu_reset() into sev_vcpu_create() > https://github.com/kvm-x86/linux/commit/f7b1f0c1620d > [8/8] KVM: SVM: Enable Secure TSC for SNP guests > https://github.com/kvm-x86/linux/commit/a311fce2b694 > > -- > https://github.com/kvm-x86/linux/tree/next Regards, Nikunj
© 2016 - 2025 Red Hat, Inc.