From: "Nikunj A. Dadhania" <nikunj@amd.com>
To: Xiaoyao Li <xiaoyao.li@intel.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 v13 05/13] x86/sev: Prevent RDTSC/RDTSCP interception for Secure TSC enabled guests
Date: Thu, 24 Oct 2024 14:14:00 +0530 [thread overview]
Message-ID: <de0b0551-003d-0cc8-9015-9124c25f5d43@amd.com> (raw)
In-Reply-To: <aff9bf82-e11e-43d9-8661-aefa328242ad@intel.com>
On 10/24/2024 1:26 PM, Xiaoyao Li wrote:
> On 10/21/2024 1:51 PM, Nikunj A Dadhania wrote:
>> The hypervisor should not be intercepting RDTSC/RDTSCP when Secure TSC is
>> enabled. A #VC exception will be generated if the RDTSC/RDTSCP instructions
>> are being intercepted. If this should occur and Secure TSC is enabled,
>> terminate guest execution.
>
> There is another option to ignore the interception and just return back to
> guest execution.
That is not correct, RDTSC/RDTSCP should return the timestamp counter value
computed using the GUEST_TSC_SCALE and GUEST_TSC_OFFSET part of VMSA.
> I think it better to add some justification on why make it> fatal and terminate the guest is better than ignoring the interception.
How about the below updated commit message:
The hypervisor should not be intercepting RDTSC/RDTSCP when Secure TSC is
enabled. A #VC exception will be generated if the RDTSC/RDTSCP instructions
are being intercepted. If this should occur and Secure TSC is enabled,
terminate guest execution as the guest cannot rely on the TSC value provided
by the hypervisor.
Regards
Nikunj
next prev parent reply other threads:[~2024-10-24 8:44 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 5:51 [PATCH v13 00/13] Add Secure TSC support for SNP guests Nikunj A Dadhania
2024-10-21 5:51 ` [PATCH v13 01/13] x86/sev: Carve out and export SNP guest messaging init routines Nikunj A Dadhania
2024-10-21 7:48 ` Christophe JAILLET
2024-10-22 4:12 ` Nikunj A. Dadhania
2024-10-21 5:51 ` [PATCH v13 02/13] x86/sev: Relocate SNP guest messaging routines to common code Nikunj A Dadhania
2024-10-21 5:51 ` [PATCH v13 03/13] x86/sev: Add Secure TSC support for SNP guests Nikunj A Dadhania
2024-10-21 8:12 ` Christophe JAILLET
2024-10-22 4:15 ` Nikunj A. Dadhania
2024-10-21 5:51 ` [PATCH v13 04/13] x86/sev: Change TSC MSR behavior for Secure TSC enabled guests Nikunj A Dadhania
2024-10-23 3:25 ` Xiaoyao Li
2024-10-24 6:24 ` Nikunj A. Dadhania
2024-10-24 7:31 ` Xiaoyao Li
2024-10-24 10:16 ` Nikunj A. Dadhania
2024-10-21 5:51 ` [PATCH v13 05/13] x86/sev: Prevent RDTSC/RDTSCP interception " Nikunj A Dadhania
2024-10-24 7:56 ` Xiaoyao Li
2024-10-24 8:44 ` Nikunj A. Dadhania [this message]
2024-10-24 15:34 ` Xiaoyao Li
2024-10-21 5:51 ` [PATCH v13 06/13] x86/sev: Prevent GUEST_TSC_FREQ MSR " Nikunj A Dadhania
2024-10-21 14:08 ` Tom Lendacky
2024-10-22 4:20 ` Nikunj A. Dadhania
2024-10-21 5:51 ` [PATCH v13 07/13] x86/sev: Mark Secure TSC as reliable clocksource Nikunj A Dadhania
2024-10-21 5:51 ` [PATCH v13 08/13] x86/cpu/amd: Do not print FW_BUG for Secure TSC Nikunj A Dadhania
2024-10-21 5:51 ` [PATCH v13 09/13] tsc: Use the GUEST_TSC_FREQ MSR for discovering TSC frequency Nikunj A Dadhania
2024-10-21 14:33 ` Tom Lendacky
2024-10-22 4:24 ` Nikunj A. Dadhania
2024-10-21 5:51 ` [PATCH v13 10/13] tsc: Upgrade TSC clocksource rating Nikunj A Dadhania
2024-10-21 5:51 ` [PATCH v13 11/13] tsc: Switch to native sched clock Nikunj A Dadhania
2024-10-21 14:37 ` Tom Lendacky
2024-10-22 4:26 ` Nikunj A. Dadhania
2024-10-21 21:30 ` kernel test robot
2024-10-21 23:03 ` kernel test robot
2024-10-21 5:51 ` [PATCH v13 12/13] x86/kvmclock: Abort SecureTSC enabled guest when kvmclock is selected Nikunj A Dadhania
2024-10-21 15:00 ` Tom Lendacky
2024-10-22 4:28 ` Nikunj A. Dadhania
2024-10-21 5:51 ` [PATCH v13 13/13] x86/sev: Allow Secure TSC feature for SNP guests 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=de0b0551-003d-0cc8-9015-9124c25f5d43@amd.com \
--to=nikunj@amd.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=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox