[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAH4kHZVdZtU3MGLTuuxMZyBF1xO=UzpdVhqSE6szCxMLkHFvQ@mail.gmail.com>
Date: Wed, 6 Dec 2023 10:45:31 -0800
From: Dionna Amalie Glaze <dionnaglaze@...gle.com>
To: nikunj@....com
Cc: linux-kernel@...r.kernel.org, thomas.lendacky@....com,
x86@...nel.org, kvm@...r.kernel.org, bp@...en8.de,
mingo@...hat.com, tglx@...utronix.de, dave.hansen@...ux.intel.com,
pgonda@...gle.com, seanjc@...gle.com, pbonzini@...hat.com
Subject: Re: [PATCH v6 12/16] x86/sev: Prevent RDTSC/RDTSCP interception for
Secure TSC enabled guests
> >> + if (sev_status & MSR_AMD64_SNP_SECURE_TSC)
> >> + return ES_VMM_ERROR;
> >
> > Is this not a cc_platform_has situation? I don't recall how the
> > conversation shook out for TDX's forcing X86_FEATURE_TSC_RELIABLE
> > versus having a cc_attr_secure_tsc
>
> For SNP, SecureTSC is an opt-in feature. AFAIU, for TDX the feature is
> turned on by default. So SNP guests need to check if the VMM has enabled
> the feature before moving forward with SecureTSC initializations.
>
> The idea was to have some generic name instead of AMD specific SecureTSC
> (cc_attr_secure_tsc), and I had sought comments from Kirill [1]. After
> that discussion I have added a synthetic flag for Secure TSC[2].
>
So with regards to [2], this sev_status flag check should be
cpu_has_feature(X86_FEATURE_SNP_SECURE_TSC)? I'm not sure if that's
available in early boot where this code is used, so if it isn't,
probably that's worth a comment.
--
-Dionna Glaze, PhD (she/her)
Powered by blists - more mailing lists