> From: Dave Hansen <dave.han...@intel.com>
> Sent: Thursday, October 19, 2023 8:54 AM
> To: Dexuan Cui <de...@microsoft.com>; KY Srinivasan
> [...]
> > --- a/arch/x86/hyperv/ivm.c
> > +++ b/arch/x86/hyperv/ivm.c
> > @@ -450,6 +450,16 @@ static bool hv_is_private_mmio(u64 addr)
> >     return false;
> >  }
> >
> > +static void hv_print_mem_enc_feature_info(void)
> > +{
> > +   enum hv_isolation_type type = hv_get_isolation_type();
> > +
> > +   if (type == HV_ISOLATION_TYPE_SNP)
> > +           pr_info("Memory Encryption Features active: AMD
> SEV\n");
> > +   else if (type == HV_ISOLATION_TYPE_TDX)
> > +           pr_info("Memory Encryption Features active: Intel
> > TDX\n");
> > +}
> 
> If we draw this to its logical conclusion, every paravisor will need a
> pr_info() for every hardware CoCo implementation.  That M*N pr_info()s.
> That seems nuts.

This patch only modifies x86 related files. I think it's unlikely to see
a third hardware Coco implementation for x86 in the foreseeable feature (?)
When we have a third implementation, I suppose more code, e.g., the existing
print_mem_encrypt_feature_info(),  will have to be changed as well.

Currently it looks like there is only 1 paravisor implementation. 
I think we'll know if some code can be shared only when a second paravisor
implementation appears.

I can use the below version if you think it's better:

static const char *hv_mem_enc_features[] = {
        [ HV_ISOLATION_TYPE_SNP ] = "AMD SEV",
        [ HV_ISOLATION_TYPE_TDX ] = "Intel TDX",
};

static void hv_print_mem_enc_feature_info(void)
{
        enum hv_isolation_type type = hv_get_isolation_type();

        if (type < HV_ISOLATION_TYPE_SNP || type > HV_ISOLATION_TYPE_TDX)
                return;

        pr_info("Memory Encryption Features active:: %s\n",
                hv_mem_enc_features[type]);
}

Thanks,
Dexuan

Reply via email to