Re: [PATCH v5 09/14] x86/sev: Add Secure TSC support for SNP guests

[Tom Lendacky]

On 11/2/23 00:36, Nikunj A. Dadhania wrote:
> On 10/31/2023 1:56 AM, Tom Lendacky wrote:
> > On 10/30/23 01:36, Nikunj A Dadhania wrote:
> > > Add support for Secure TSC in SNP enabled guests. Secure TSC allows
> > > guest to securely use RDTSC/RDTSCP instructions as the parameters
> > > being used cannot be changed by hypervisor once the guest is launched.
> > >
> > > During the boot-up of the secondary cpus, SecureTSC enabled guests
> > > need to query TSC info from AMD Security Processor. This communication
> > > channel is encrypted between the AMD Security Processor and the guest,
> > > the hypervisor is just the conduit to deliver the guest messages to
> > > the AMD Security Processor. Each message is protected with an
> > > AEAD (AES-256 GCM). Use minimal AES GCM library to encrypt/decrypt SNP
> > > Guest messages to communicate with the PSP.
> >
> > Add to this commit message that you're using the enc_init hook to perform some Secure TSC initialization and why you have to do that.
>
> Sure, will add.
>   
> > > Signed-off-by: Nikunj A Dadhania <nikunj@xxxxxxx>
> > > ---
> > >    arch/x86/coco/core.c             |  3 ++
> > >    arch/x86/include/asm/sev-guest.h | 18 +++++++
> > >    arch/x86/include/asm/sev.h       |  2 +
> > >    arch/x86/include/asm/svm.h       |  6 ++-
> > >    arch/x86/kernel/sev.c            | 82 ++++++++++++++++++++++++++++++++
> > >    arch/x86/mm/mem_encrypt_amd.c    |  6 +++
> > >    include/linux/cc_platform.h      |  8 ++++
> > >    7 files changed, 123 insertions(+), 2 deletions(-)

> > > +void __init snp_secure_tsc_prepare(void)
> > > +{
> > > +    if (!cc_platform_has(CC_ATTR_GUEST_SECURE_TSC))
> > > +        return;
> > > +
> > > +    if (snp_get_tsc_info())
> > > +        sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
> >
> > How about using SEV_TERM_SET_LINUX and a new GHCB_TERM_SECURE_TSC_INFO.
>
> Yes, we can do that, I remember you had said this will required GHCB spec change and then thought of sticking with the current return code.

No spec change needed. The base SNP support is already using it, so not an 
issue to add a new error code.

Thanks,
Tom