On 12/12/2024 2:02 AM, Borislav Petkov wrote: > On Tue, Dec 03, 2024 at 02:30:39PM +0530, Nikunj A Dadhania wrote: >> diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c >> index 774f9677458f..fa0bc52ef707 100644 >> --- a/arch/x86/mm/mem_encrypt_amd.c >> +++ b/arch/x86/mm/mem_encrypt_amd.c >> @@ -541,6 +541,10 @@ void __init sme_early_init(void) >> * kernel mapped. >> */ >> snp_update_svsm_ca(); >> + >> + /* Mark the TSC as reliable when Secure TSC is enabled */ >> + if (sev_status & MSR_AMD64_SNP_SECURE_TSC) >> + setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); > > What happens if someone writes MSR 0x10 on some CPU and thus makes the TSCs on > the host unsynchronized and that CPU runs a SecureTSC guest? > > That guest would use RDTSC and get wrong values and turn the guest into > a mess, right? No, SecureTSC guest keeps on ticking forward even when the HV has written to MSR 0x10 on the CPU where the SecureTSC guest is running. I performed following experiment to confirm the behavior: 1) Started the SecureTSC guest pinned to CPU10 host $ taskset -c 10 ./bootg_sectsc.sh 2) Read TSC MSR on guest guest $ sudo rdmsr 0x10 8005a5b2d634c 3) Set TSC MSR to 0 on CPU10 on host. host $ sudo wrmsr -p 10 0x10 0 host $ sudo rdmsr -p 10 0x10 4846ad0 4) Read TSC MSR on guest again guest $ sudo rdmsr 0x10 8005d18a7144f Regards, Nikunj
