From: Dave Hansen <dave.hansen@intel.com>
To: Nikunj A Dadhania <nikunj@amd.com>,
linux-kernel@vger.kernel.org, thomas.lendacky@amd.com,
bp@alien8.de, x86@kernel.org, kvm@vger.kernel.org
Cc: mingo@redhat.com, tglx@linutronix.de,
dave.hansen@linux.intel.com, pgonda@google.com,
seanjc@google.com, pbonzini@redhat.com
Subject: Re: [PATCH v12 00/19] Add Secure TSC support for SNP guests
Date: Wed, 9 Oct 2024 09:08:21 -0700 [thread overview]
Message-ID: <52279d55-11bf-490f-b3c7-69e6fe246c9d@intel.com> (raw)
In-Reply-To: <20241009092850.197575-1-nikunj@amd.com>
On 10/9/24 02:28, Nikunj A Dadhania wrote:
> Secure TSC allows guests to securely use RDTSC/RDTSCP instructions as the
> parameters being used cannot be changed by hypervisor once the guest is
> launched. More details in the AMD64 APM Vol 2, Section "Secure TSC".
>
> In order to enable secure TSC, SEV-SNP guests need to send a TSC_INFO guest
> message before the APs are booted.
Superficially, this seems kinda silly. If you ask someone, do you want
more security or less, they usually say "more".
Why do guests need to turn this on instead of just always having a
secure TSC? There must be _some_ compromise, either backward
compatibility or performance or...
next prev parent reply other threads:[~2024-10-09 16:08 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 9:28 [PATCH v12 00/19] Add Secure TSC support for SNP guests Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 01/19] virt: sev-guest: Use AES GCM crypto library Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 02/19] x86/sev: Handle failures from snp_init() Nikunj A Dadhania
2024-10-16 16:16 ` Tom Lendacky
2024-10-09 9:28 ` [PATCH v12 03/19] x86/sev: Cache the secrets page address Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 04/19] virt: sev-guest: Consolidate SNP guest messaging parameters to a struct Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 05/19] virt: sev-guest: Reduce the scope of SNP command mutex Nikunj A Dadhania
2024-10-10 18:32 ` Tom Lendacky
2024-10-09 9:28 ` [PATCH v12 06/19] virt: sev-guest: Carve out SNP message context structure Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 07/19] x86/sev: Carve out and export SNP guest messaging init routines Nikunj A Dadhania
2024-10-17 7:42 ` kernel test robot
2024-10-09 9:28 ` [PATCH v12 08/19] x86/sev: Relocate SNP guest messaging routines to common code Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 09/19] x86/cc: Add CC_ATTR_GUEST_SNP_SECURE_TSC Nikunj A Dadhania
2024-10-10 18:34 ` Tom Lendacky
2024-10-09 9:28 ` [PATCH v12 10/19] x86/sev: Add Secure TSC support for SNP guests Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 11/19] x86/sev: Change TSC MSR behavior for Secure TSC enabled guests Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 12/19] x86/sev: Prevent RDTSC/RDTSCP interception " Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 13/19] x86/sev: Mark Secure TSC as reliable clocksource Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 14/19] tsc: Use the GUEST_TSC_FREQ MSR for discovering TSC frequency Nikunj A Dadhania
2024-10-10 19:39 ` Tom Lendacky
2024-10-14 3:36 ` Nikunj A. Dadhania
2024-10-09 9:28 ` [PATCH v12 15/19] tsc: Upgrade TSC clocksource rating Nikunj A Dadhania
2024-10-09 16:16 ` Sean Christopherson
2024-10-10 6:44 ` Nikunj A. Dadhania
2024-10-09 9:28 ` [PATCH v12 16/19] x86/kvmclock: Use clock source callback to update kvm sched clock Nikunj A Dadhania
2024-10-09 15:58 ` Sean Christopherson
2024-10-10 10:14 ` Nikunj A. Dadhania
2024-10-16 8:26 ` Nikunj A. Dadhania
2024-10-09 9:28 ` [PATCH v12 17/19] x86/kvmclock: Abort SecureTSC enabled guest when kvmclock is selected Nikunj A Dadhania
2024-10-10 19:49 ` Tom Lendacky
2024-10-14 3:37 ` Nikunj A. Dadhania
2024-10-09 9:28 ` [PATCH v12 18/19] x86/cpu/amd: Do not print FW_BUG for Secure TSC Nikunj A Dadhania
2024-10-09 9:28 ` [PATCH v12 19/19] x86/sev: Allow Secure TSC feature for SNP guests Nikunj A Dadhania
2024-10-09 16:08 ` Dave Hansen [this message]
2024-10-10 6:28 ` [PATCH v12 00/19] Add Secure TSC support " Nikunj A. Dadhania
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=52279d55-11bf-490f-b3c7-69e6fe246c9d@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox