From: Markus Armbruster <armbru@redhat.com>
To: Naveen N Rao <naveen@kernel.org>
Cc: qemu-devel <qemu-devel@nongnu.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Eric Blake" <eblake@redhat.com>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"Zhao Liu" <zhao1.liu@intel.com>,
"Nikunj A Dadhania" <nikunj@amd.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Michael Roth" <michael.roth@amd.com>,
"Roy Hopkins" <roy.hopkins@randomman.co.uk>,
"Srikanth Aithal" <srikanth.aithal@amd.com>
Subject: Re: [PATCH v3 8/9] target/i386: SEV: Add support for setting TSC frequency for Secure TSC
Date: Fri, 07 Nov 2025 10:49:30 +0100 [thread overview]
Message-ID: <87ecqacgut.fsf@pond.sub.org> (raw)
In-Reply-To: <ot37mpc4y2oferchx6yroyriqickajnkiouok7quaaijq25c7n@cpqitwnuwyz2> (Naveen N. Rao's message of "Fri, 7 Nov 2025 14:21:24 +0530")
Naveen N Rao <naveen@kernel.org> writes:
> On Thu, Nov 06, 2025 at 01:09:37PM +0100, Markus Armbruster wrote:
>> Pardon my ignorance...
>>
>> "Naveen N Rao (AMD)" <naveen@kernel.org> writes:
>>
>> > 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.
>>
>> Which property exactly?
>
> Same name: tsc-frequency specified with '-cpu'
Thanks. It's x86_64-cpu property tsc-frequency.
>>
>> > 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.
>>
>> Sounds awkward.
>>
>> Do the two properties set the same thing at different times?
>
> Yes. For regular guests, TSC frequency is set using a vCPU ioctl.
> However, TDX and SEV-SNP (with Secure TSC) require the TSC frequency to
> be set as a VM property (there is a VM ioctl for this purpose).
>
> This was Tom's question too (see v2): is there any way to re-use
> 'tsc-frequency' specified with '-cpu' for Secure TSC.
Hmm, let's see whether I can guess how this stuff works. Please correct
my misunderstandings.
When machine property confidential-guest-support is null, it's a regular
guest.
If it points to a sev-guest object, it's SEV.
If it points to a sev-snp-guest object, it's SEV-SNP.
If it points to a tdx-guest object, it's TDX.
Normally, the TSC frequency is specified with x86_64-cpu property
tsc-frequency.
Can different CPUs have different frequencies?
In certain cases (SEV-SNP or TDX guest with Secure TSC), tsc-frequency
needs to be configured before any CPUs are created. You're implementing
this for SEV-SNP, and you chose to create a sev-snp property
tsc-frequency for this.
What happens when I enable Secure TSC with sev-snp property
"secure-tsc": true, but don't set property tsc-frequency?
What happens when I do set it, and then also set the CPU property? To
the same frequency? To a different frequency?
>> > The user-provided TSC frequency is set through KVM_SET_TSC_KHZ before
>> > issuing KVM_SEV_SNP_LAUNCH_START.
>> >
>> > Attempts to set TSC frequency on both the SEV_SNP object and the cpu
>> > object result in an error from KVM (on the vCPU ioctl), so do not add
>> > separate checks for the same.
>> >
>> > 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>
>>
>> [...]
>>
>> > diff --git a/qapi/qom.json b/qapi/qom.json
>> > index c7dd2dd1b095..5daaf065b6b7 100644
>> > --- a/qapi/qom.json
>> > +++ b/qapi/qom.json
>> > @@ -1104,6 +1104,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)
>>
>> Is this likely to remain the only property that's only valied when
>> @secure-tsc is true?
>
> At this stage, yes. I am not aware of anything else that is specific to
> Secure TSC.
Alright, this makes "only valid if" reasonable.
next prev parent reply other threads:[~2025-11-07 9:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 10:43 [PATCH v3 0/9] target/i386: SEV: Add support for enabling VMSA SEV features Naveen N Rao (AMD)
2025-10-28 10:43 ` [PATCH v3 1/9] target/i386: SEV: Generalize handling of SVM_SEV_FEAT_SNP_ACTIVE Naveen N Rao (AMD)
2025-10-28 10:43 ` [PATCH v3 2/9] target/i386: SEV: Ensure SEV features are only set through qemu cli or IGVM Naveen N Rao (AMD)
2025-10-28 10:43 ` [PATCH v3 3/9] target/i386: SEV: Consolidate SEV feature validation to common init path Naveen N Rao (AMD)
2025-10-28 10:43 ` [PATCH v3 4/9] target/i386: SEV: Validate that SEV-ES is enabled when VMSA features are used Naveen N Rao (AMD)
2025-10-28 10:43 ` [PATCH v3 5/9] target/i386: SEV: Enable use of KVM_SEV_INIT2 for SEV-ES guests Naveen N Rao (AMD)
2025-10-28 10:43 ` [PATCH v3 6/9] target/i386: SEV: Add support for enabling debug-swap SEV feature Naveen N Rao (AMD)
2025-10-28 10:43 ` [PATCH v3 7/9] target/i386: SEV: Add support for enabling Secure TSC " Naveen N Rao (AMD)
2025-10-28 10:43 ` [PATCH v3 8/9] target/i386: SEV: Add support for setting TSC frequency for Secure TSC Naveen N Rao (AMD)
2025-11-06 12:09 ` Markus Armbruster
2025-11-07 8:51 ` Naveen N Rao
2025-11-07 9:49 ` Markus Armbruster [this message]
2025-11-10 10:18 ` Naveen N Rao
2025-11-07 9:59 ` Daniel P. Berrangé
2025-11-10 10:12 ` Naveen N Rao
2025-10-28 10:43 ` [PATCH v3 9/9] target/i386: SEV: Refactor check_sev_features() Naveen N Rao (AMD)
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=87ecqacgut.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=michael.roth@amd.com \
--cc=mtosatti@redhat.com \
--cc=naveen@kernel.org \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=roy.hopkins@randomman.co.uk \
--cc=srikanth.aithal@amd.com \
--cc=thomas.lendacky@amd.com \
--cc=zhao1.liu@intel.com \
/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.