In x86 virtualization environments, including TDX, RDTSC instruction is
handled without causing a VM exit, resulting in minimal overhead and
jitters. On the other hand, other clock sources (such as HPET, ACPI
timer, APIC, etc.) necessitate VM exits to implement, resulting in more
fluctuating measurements compared to TSC. Thus, those clock sources are
not effective for calibrating TSC.
In TD guests, TSC is virtualized by the TDX module, which ensures:
- Virtual TSC values are consistent among all the TD’s VCPUs;
- Monotonously incrementing for any single VCPU;
- The frequency is determined by TD configuration. The host TSC is
invariant on platforms where TDX is available.
Use TSC as the only reliable clock source in TD guests, bypassing
unstable calibration.
Signed-off-by: Kirill A. Shutemov <[email protected]>
---
arch/x86/coco/tdx/tdx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
index 1d6b863c42b0..1583ec64d92e 100644
--- a/arch/x86/coco/tdx/tdx.c
+++ b/arch/x86/coco/tdx/tdx.c
@@ -769,6 +769,9 @@ void __init tdx_early_init(void)
setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
+ /* TSC is the only reliable clock in TDX guest */
+ setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
+
cc_vendor = CC_VENDOR_INTEL;
tdx_parse_tdinfo(&cc_mask);
cc_set_mask(cc_mask);
--
2.41.0
> On Aug 30, 2023, at 12:33 AM, Thomas Gleixner <[email protected]> wrote:
>
> On Tue, Aug 29 2023 at 16:01, Jun Nakajima wrote:
>>> On Aug 25, 2023, at 10:09 AM, Thomas Gleixner <[email protected]> wrote:
>>>> The newer spec says "Virtual TSC values are consistent among all the TD’s
>>>> VCPUs at the level supported by the CPU".
>>>
>>> That means what? It's not a guarantee for consistency either. :(
>>
>> Actually (in TDX Module 1.5 spec), the sentence is "Virtual TSC values
>> are consistent among all the TD’s VCPUs at the level supported by the
>> CPU, see below”.
>>
>> And the below:
>> ---
>> The host VMM is required to do the following:
>> • Set up the same IA32_TSC_ADJUST values on all LPs before initializing the Intel TDX module.
>> • Make sure IA32_TSC_ADJUST is not modified from its initial value before calling SEAMCALL.
>>
>> The Intel TDX module checks the above as part of TDH.VP.ENTER and any
>> other SEAMCALL leaf function that reads TSC.
>
> What happens when the check detects that the host modified TSC ADJUST?
Such a SEAMCALL, e.g., TDH.VP.ENTER will fail with an error code (TDX_INCONSISTENT_MSR and MSR index of TSC ADJUST).
>
> What validates the VMCS TSC offset field?
TDX module. The VMCSs of TDs are in private (protected) memory and accessed by the TDX module only.
The host has no direct access to them.
>
>> The virtualized TSC is designed to have the following characteristics:
>> • The virtual TSC frequency is specified by the host VMM as an input
>> to TDH.MNG.INIT in units of 25MHz – it can be between 4 and 400
>> (corresponding to a range of 100MHz to 10GHz).
>
> What validates that the frequency is correct?
Validation of the real/hardware TSC frequency is part of hardware validation.
>
> How is ensured that the host does not change TSC scaling?
I guess you mean virtual TSC scaling, which is used for calculation of the TSC observed by the guest.
This is a VMCS field set by the TDX module, based on the configured virtual TSC frequency and the real TSC frequency. So, the host cannot change it (as it has no direct access to the VMCS).
---
Jun