Add support for configuring the TSC frequency when Secure TSC is enabled
in SEV-SNP guests through a new "tsc-frequency" property on SEV-SNP
guest objects, similar to the vCPU-specific property used by regular
guests and TDX. A new property is needed since SEV-SNP guests require
the TSC frequency to be specified during early SNP_LAUNCH_START command
before any vCPUs are created.
The user-provided TSC frequency is set through KVM_SET_TSC_KHZ before
issuing KVM_SEV_SNP_LAUNCH_START.
Sample command-line:
-machine q35,confidential-guest-support=sev0 \
-object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on,tsc-frequency=2500000000
Co-developed-by: Ketan Chaturvedi <Ketan.Chaturvedi@amd.com>
Signed-off-by: Ketan Chaturvedi <Ketan.Chaturvedi@amd.com>
Co-developed-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
---
target/i386/sev.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
qapi/qom.json | 6 +++++-
2 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 68d193402de3..8bb9faaa7779 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -178,6 +178,7 @@ struct SevSnpGuestState {
char *id_auth_base64;
uint8_t *id_auth;
char *host_data;
+ uint32_t tsc_khz;
struct kvm_sev_snp_launch_start kvm_start_conf;
struct kvm_sev_snp_launch_finish kvm_finish_conf;
@@ -536,6 +537,13 @@ static int check_sev_features(SevCommonState *sev_common, uint64_t sev_features,
__func__, sev_features, sev_common->supported_sev_features);
return -1;
}
+ if (sev_snp_enabled() && SEV_SNP_GUEST(sev_common)->tsc_khz &&
+ !(sev_features & SVM_SEV_FEAT_SECURE_TSC)) {
+ error_setg(errp,
+ "%s: TSC frequency can only be set if Secure TSC is enabled",
+ __func__);
+ return -1;
+ }
return 0;
}
@@ -1085,6 +1093,19 @@ sev_snp_launch_start(SevCommonState *sev_common)
return 1;
}
+ if (is_sev_feature_set(sev_common, SVM_SEV_FEAT_SECURE_TSC) &&
+ sev_snp_guest->tsc_khz) {
+ rc = -EINVAL;
+ if (kvm_check_extension(kvm_state, KVM_CAP_VM_TSC_CONTROL)) {
+ rc = kvm_vm_ioctl(kvm_state, KVM_SET_TSC_KHZ, sev_snp_guest->tsc_khz);
+ }
+ if (rc < 0) {
+ error_report("%s: Unable to set Secure TSC frequency to %u kHz ret=%d",
+ __func__, sev_snp_guest->tsc_khz, rc);
+ return 1;
+ }
+ }
+
rc = sev_ioctl(sev_common->sev_fd, KVM_SEV_SNP_LAUNCH_START,
start, &fw_error);
if (rc < 0) {
@@ -3131,6 +3152,28 @@ static void sev_snp_guest_set_secure_tsc(Object *obj, bool value, Error **errp)
sev_set_feature(SEV_COMMON(obj), SVM_SEV_FEAT_SECURE_TSC, value);
}
+static void
+sev_snp_guest_get_tsc_frequency(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value = SEV_SNP_GUEST(obj)->tsc_khz * 1000;
+
+ visit_type_uint32(v, name, &value, errp);
+}
+
+static void
+sev_snp_guest_set_tsc_frequency(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ uint32_t value;
+
+ if (!visit_type_uint32(v, name, &value, errp)) {
+ return;
+ }
+
+ SEV_SNP_GUEST(obj)->tsc_khz = value / 1000;
+}
+
static void
sev_snp_guest_class_init(ObjectClass *oc, const void *data)
{
@@ -3169,6 +3212,9 @@ sev_snp_guest_class_init(ObjectClass *oc, const void *data)
object_class_property_add_bool(oc, "secure-tsc",
sev_snp_guest_get_secure_tsc,
sev_snp_guest_set_secure_tsc);
+ object_class_property_add(oc, "tsc-frequency", "uint32",
+ sev_snp_guest_get_tsc_frequency,
+ sev_snp_guest_set_tsc_frequency, NULL, NULL);
}
static void
diff --git a/qapi/qom.json b/qapi/qom.json
index 52c23e85e349..c01ae70dd43d 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -1103,6 +1103,9 @@
# @secure-tsc: enable Secure TSC
# (default: false) (since 10.2)
#
+# @tsc-frequency: set secure TSC frequency. Only valid if Secure TSC
+# is enabled (default: zero) (since 10.2)
+#
# Since: 9.1
##
{ 'struct': 'SevSnpGuestProperties',
@@ -1115,7 +1118,8 @@
'*author-key-enabled': 'bool',
'*host-data': 'str',
'*vcek-disabled': 'bool',
- '*secure-tsc': 'bool' } }
+ '*secure-tsc': 'bool',
+ '*tsc-frequency': 'uint32' } }
##
# @TdxGuestProperties:
--
2.51.0On 9/25/25 05:17, Naveen N Rao (AMD) wrote:
> Add support for configuring the TSC frequency when Secure TSC is enabled
> in SEV-SNP guests through a new "tsc-frequency" property on SEV-SNP
> guest objects, similar to the vCPU-specific property used by regular
> guests and TDX. A new property is needed since SEV-SNP guests require
> the TSC frequency to be specified during early SNP_LAUNCH_START command
> before any vCPUs are created.
>
> The user-provided TSC frequency is set through KVM_SET_TSC_KHZ before
> issuing KVM_SEV_SNP_LAUNCH_START.
>
> Sample command-line:
> -machine q35,confidential-guest-support=sev0 \
> -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on,tsc-frequency=2500000000
>
> Co-developed-by: Ketan Chaturvedi <Ketan.Chaturvedi@amd.com>
> Signed-off-by: Ketan Chaturvedi <Ketan.Chaturvedi@amd.com>
> Co-developed-by: Nikunj A Dadhania <nikunj@amd.com>
> Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
> Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org>
> ---
> target/i386/sev.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> qapi/qom.json | 6 +++++-
> 2 files changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 68d193402de3..8bb9faaa7779 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -178,6 +178,7 @@ struct SevSnpGuestState {
> char *id_auth_base64;
> uint8_t *id_auth;
> char *host_data;
> + uint32_t tsc_khz;
>
> struct kvm_sev_snp_launch_start kvm_start_conf;
> struct kvm_sev_snp_launch_finish kvm_finish_conf;
> @@ -536,6 +537,13 @@ static int check_sev_features(SevCommonState *sev_common, uint64_t sev_features,
> __func__, sev_features, sev_common->supported_sev_features);
> return -1;
> }
> + if (sev_snp_enabled() && SEV_SNP_GUEST(sev_common)->tsc_khz &&
> + !(sev_features & SVM_SEV_FEAT_SECURE_TSC)) {
> + error_setg(errp,
> + "%s: TSC frequency can only be set if Secure TSC is enabled",
> + __func__);
> + return -1;
> + }
> return 0;
> }
>
> @@ -1085,6 +1093,19 @@ sev_snp_launch_start(SevCommonState *sev_common)
> return 1;
> }
>
> + if (is_sev_feature_set(sev_common, SVM_SEV_FEAT_SECURE_TSC) &&
> + sev_snp_guest->tsc_khz) {
> + rc = -EINVAL;
> + if (kvm_check_extension(kvm_state, KVM_CAP_VM_TSC_CONTROL)) {
> + rc = kvm_vm_ioctl(kvm_state, KVM_SET_TSC_KHZ, sev_snp_guest->tsc_khz);
> + }
> + if (rc < 0) {
> + error_report("%s: Unable to set Secure TSC frequency to %u kHz ret=%d",
> + __func__, sev_snp_guest->tsc_khz, rc);
> + return 1;
> + }
> + }
> +
> rc = sev_ioctl(sev_common->sev_fd, KVM_SEV_SNP_LAUNCH_START,
> start, &fw_error);
> if (rc < 0) {
> @@ -3131,6 +3152,28 @@ static void sev_snp_guest_set_secure_tsc(Object *obj, bool value, Error **errp)
> sev_set_feature(SEV_COMMON(obj), SVM_SEV_FEAT_SECURE_TSC, value);
> }
>
> +static void
> +sev_snp_guest_get_tsc_frequency(Object *obj, Visitor *v, const char *name,
> + void *opaque, Error **errp)
> +{
> + uint32_t value = SEV_SNP_GUEST(obj)->tsc_khz * 1000;
> +
> + visit_type_uint32(v, name, &value, errp);
> +}
> +
> +static void
> +sev_snp_guest_set_tsc_frequency(Object *obj, Visitor *v, const char *name,
> + void *opaque, Error **errp)
> +{
> + uint32_t value;
> +
> + if (!visit_type_uint32(v, name, &value, errp)) {
> + return;
> + }
> +
> + SEV_SNP_GUEST(obj)->tsc_khz = value / 1000;
This will cause a value that isn't evenly divisible by 1000 to be
rounded down, e.g.: tsc-frequency=2500000999. Should this name instead
just be tsc-khz or secure-tsc-khz (to show it is truly associated with
Secure TSC)?
Also, I think there is already a "tsc-freq" parameter for the -cpu
parameter (?), should there be some kind of error message if both of
these are set? Or a warning saying it is being ignored? Or ...?
Thanks,
Tom
> +}
> +
> static void
> sev_snp_guest_class_init(ObjectClass *oc, const void *data)
> {
> @@ -3169,6 +3212,9 @@ sev_snp_guest_class_init(ObjectClass *oc, const void *data)
> object_class_property_add_bool(oc, "secure-tsc",
> sev_snp_guest_get_secure_tsc,
> sev_snp_guest_set_secure_tsc);
> + object_class_property_add(oc, "tsc-frequency", "uint32",
> + sev_snp_guest_get_tsc_frequency,
> + sev_snp_guest_set_tsc_frequency, NULL, NULL);
> }
>
> static void
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 52c23e85e349..c01ae70dd43d 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -1103,6 +1103,9 @@
> # @secure-tsc: enable Secure TSC
> # (default: false) (since 10.2)
> #
> +# @tsc-frequency: set secure TSC frequency. Only valid if Secure TSC
> +# is enabled (default: zero) (since 10.2)
> +#
> # Since: 9.1
> ##
> { 'struct': 'SevSnpGuestProperties',
> @@ -1115,7 +1118,8 @@
> '*author-key-enabled': 'bool',
> '*host-data': 'str',
> '*vcek-disabled': 'bool',
> - '*secure-tsc': 'bool' } }
> + '*secure-tsc': 'bool',
> + '*tsc-frequency': 'uint32' } }
>
> ##
> # @TdxGuestProperties:
On Tue, Oct 07, 2025 at 08:31:47AM -0500, Tom Lendacky wrote:
> On 9/25/25 05:17, Naveen N Rao (AMD) wrote:
...
> > +
> > +static void
> > +sev_snp_guest_set_tsc_frequency(Object *obj, Visitor *v, const char *name,
> > + void *opaque, Error **errp)
> > +{
> > + uint32_t value;
> > +
> > + if (!visit_type_uint32(v, name, &value, errp)) {
> > + return;
> > + }
> > +
> > + SEV_SNP_GUEST(obj)->tsc_khz = value / 1000;
>
> This will cause a value that isn't evenly divisible by 1000 to be
> rounded down, e.g.: tsc-frequency=2500000999. Should this name instead
> just be tsc-khz or secure-tsc-khz (to show it is truly associated with
> Secure TSC)?
I modeled this after the existing tsc-frequency parameter on the cpu
object to keep it simple (parameter is the same, just where it is
specified differs). This also aligns with TDX which re-uses the
tsc-frequency parameter on the cpu object.
>
> Also, I think there is already a "tsc-freq" parameter for the -cpu
> parameter (?), should there be some kind of error message if both of
> these are set? Or a warning saying it is being ignored? Or ...?
This is validated when the TSC frequency is being set on the vcpu, so I didn't
add an explicit check.
As an example, with:
-cpu EPYC-v4,tsc-frequency=2500000000 \
-object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on
qemu-system-x86_64: warning: TSC frequency mismatch between VM (2500000 kHz) and host (2596099 kHz), and TSC scaling unavailable
qemu-system-x86_64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
Thanks,
Naveen
On 10/8/25 04:52, Naveen N Rao wrote:
> On Tue, Oct 07, 2025 at 08:31:47AM -0500, Tom Lendacky wrote:
>> On 9/25/25 05:17, Naveen N Rao (AMD) wrote:
>
> ...
>
>>> +
>>> +static void
>>> +sev_snp_guest_set_tsc_frequency(Object *obj, Visitor *v, const char *name,
>>> + void *opaque, Error **errp)
>>> +{
>>> + uint32_t value;
>>> +
>>> + if (!visit_type_uint32(v, name, &value, errp)) {
>>> + return;
>>> + }
>>> +
>>> + SEV_SNP_GUEST(obj)->tsc_khz = value / 1000;
>>
>> This will cause a value that isn't evenly divisible by 1000 to be
>> rounded down, e.g.: tsc-frequency=2500000999. Should this name instead
>> just be tsc-khz or secure-tsc-khz (to show it is truly associated with
>> Secure TSC)?
>
> I modeled this after the existing tsc-frequency parameter on the cpu
> object to keep it simple (parameter is the same, just where it is
> specified differs). This also aligns with TDX which re-uses the
> tsc-frequency parameter on the cpu object.
So why aren't we using the one on the cpu object instead of creating a
duplicate parameter? There should be some way to get that value, no?
Thanks,
Tom
>
>>
>> Also, I think there is already a "tsc-freq" parameter for the -cpu
>> parameter (?), should there be some kind of error message if both of
>> these are set? Or a warning saying it is being ignored? Or ...?
>
> This is validated when the TSC frequency is being set on the vcpu, so I didn't
> add an explicit check.
>
> As an example, with:
> -cpu EPYC-v4,tsc-frequency=2500000000 \
> -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on
>
> qemu-system-x86_64: warning: TSC frequency mismatch between VM (2500000 kHz) and host (2596099 kHz), and TSC scaling unavailable
> qemu-system-x86_64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
>
>
> Thanks,
> Naveen
>
On Fri, Oct 24, 2025 at 10:00:08AM -0500, Tom Lendacky wrote:
> On 10/8/25 04:52, Naveen N Rao wrote:
> > On Tue, Oct 07, 2025 at 08:31:47AM -0500, Tom Lendacky wrote:
> >> On 9/25/25 05:17, Naveen N Rao (AMD) wrote:
> >
> > ...
> >
> >>> +
> >>> +static void
> >>> +sev_snp_guest_set_tsc_frequency(Object *obj, Visitor *v, const char *name,
> >>> + void *opaque, Error **errp)
> >>> +{
> >>> + uint32_t value;
> >>> +
> >>> + if (!visit_type_uint32(v, name, &value, errp)) {
> >>> + return;
> >>> + }
> >>> +
> >>> + SEV_SNP_GUEST(obj)->tsc_khz = value / 1000;
> >>
> >> This will cause a value that isn't evenly divisible by 1000 to be
> >> rounded down, e.g.: tsc-frequency=2500000999. Should this name instead
> >> just be tsc-khz or secure-tsc-khz (to show it is truly associated with
> >> Secure TSC)?
> >
> > I modeled this after the existing tsc-frequency parameter on the cpu
> > object to keep it simple (parameter is the same, just where it is
> > specified differs). This also aligns with TDX which re-uses the
> > tsc-frequency parameter on the cpu object.
>
> So why aren't we using the one on the cpu object instead of creating a
> duplicate parameter? There should be some way to get that value, no?
I had spent some time on this, but I couldn't figure out a simple way to
make that work.
TDX uses a vcpu pre-create hook (similar to KVM) to get access to and
set the TSC value from the cpu object. For SEV-SNP, we need the TSC
frequency during SNP_LAUNCH_START which is quite early and we don't have
access to the cpu object there.
Admittedly, my qemu understanding is limited. If there is a way to
re-use the cpu tsc-frequency field, then that would be ideal.
Any ideas/suggestions?
Thanks,
Naveen
On 10/24/25 12:16, Naveen N Rao wrote:
> On Fri, Oct 24, 2025 at 10:00:08AM -0500, Tom Lendacky wrote:
>> On 10/8/25 04:52, Naveen N Rao wrote:
>>> On Tue, Oct 07, 2025 at 08:31:47AM -0500, Tom Lendacky wrote:
>>>> On 9/25/25 05:17, Naveen N Rao (AMD) wrote:
>>>
>>> ...
>>>
>>>>> +
>>>>> +static void
>>>>> +sev_snp_guest_set_tsc_frequency(Object *obj, Visitor *v, const char *name,
>>>>> + void *opaque, Error **errp)
>>>>> +{
>>>>> + uint32_t value;
>>>>> +
>>>>> + if (!visit_type_uint32(v, name, &value, errp)) {
>>>>> + return;
>>>>> + }
>>>>> +
>>>>> + SEV_SNP_GUEST(obj)->tsc_khz = value / 1000;
>>>>
>>>> This will cause a value that isn't evenly divisible by 1000 to be
>>>> rounded down, e.g.: tsc-frequency=2500000999. Should this name instead
>>>> just be tsc-khz or secure-tsc-khz (to show it is truly associated with
>>>> Secure TSC)?
>>>
>>> I modeled this after the existing tsc-frequency parameter on the cpu
>>> object to keep it simple (parameter is the same, just where it is
>>> specified differs). This also aligns with TDX which re-uses the
>>> tsc-frequency parameter on the cpu object.
>>
>> So why aren't we using the one on the cpu object instead of creating a
>> duplicate parameter? There should be some way to get that value, no?
>
> I had spent some time on this, but I couldn't figure out a simple way to
> make that work.
>
> TDX uses a vcpu pre-create hook (similar to KVM) to get access to and
> set the TSC value from the cpu object. For SEV-SNP, we need the TSC
> frequency during SNP_LAUNCH_START which is quite early and we don't have
> access to the cpu object there.
>
> Admittedly, my qemu understanding is limited. If there is a way to
> re-use the cpu tsc-frequency field, then that would be ideal.
>
> Any ideas/suggestions?
Any Qemu experts know how the SEV support would be able to access the
TSC value from the -cpu command line option at LAUNCH time?
Thanks,
Tom
>
>
> Thanks,
> Naveen
>
On Tue, Oct 28, 2025 at 10:11:13AM -0500, Tom Lendacky wrote:
> On 10/24/25 12:16, Naveen N Rao wrote:
> > On Fri, Oct 24, 2025 at 10:00:08AM -0500, Tom Lendacky wrote:
> >> On 10/8/25 04:52, Naveen N Rao wrote:
> >>> On Tue, Oct 07, 2025 at 08:31:47AM -0500, Tom Lendacky wrote:
> >>>> On 9/25/25 05:17, Naveen N Rao (AMD) wrote:
> >>>
> >>> ...
> >>>
> >>>>> +
> >>>>> +static void
> >>>>> +sev_snp_guest_set_tsc_frequency(Object *obj, Visitor *v, const char *name,
> >>>>> + void *opaque, Error **errp)
> >>>>> +{
> >>>>> + uint32_t value;
> >>>>> +
> >>>>> + if (!visit_type_uint32(v, name, &value, errp)) {
> >>>>> + return;
> >>>>> + }
> >>>>> +
> >>>>> + SEV_SNP_GUEST(obj)->tsc_khz = value / 1000;
> >>>>
> >>>> This will cause a value that isn't evenly divisible by 1000 to be
> >>>> rounded down, e.g.: tsc-frequency=2500000999. Should this name instead
> >>>> just be tsc-khz or secure-tsc-khz (to show it is truly associated with
> >>>> Secure TSC)?
> >>>
> >>> I modeled this after the existing tsc-frequency parameter on the cpu
> >>> object to keep it simple (parameter is the same, just where it is
> >>> specified differs). This also aligns with TDX which re-uses the
> >>> tsc-frequency parameter on the cpu object.
> >>
> >> So why aren't we using the one on the cpu object instead of creating a
> >> duplicate parameter? There should be some way to get that value, no?
> >
> > I had spent some time on this, but I couldn't figure out a simple way to
> > make that work.
> >
> > TDX uses a vcpu pre-create hook (similar to KVM) to get access to and
> > set the TSC value from the cpu object. For SEV-SNP, we need the TSC
> > frequency during SNP_LAUNCH_START which is quite early and we don't have
> > access to the cpu object there.
> >
> > Admittedly, my qemu understanding is limited. If there is a way to
> > re-use the cpu tsc-frequency field, then that would be ideal.
> >
> > Any ideas/suggestions?
>
> Any Qemu experts know how the SEV support would be able to access the
> TSC value from the -cpu command line option at LAUNCH time?
Bump. Any feedback on this, please?
Otherwise, kindly review v3 posted here:
http://lore.kernel.org/r/cover.1761648149.git.naveen@kernel.org
Thanks,
Naveen
© 2016 - 2026 Red Hat, Inc.