Re: [PATCH v2 01/21] x86/virt/tdx: Detect SEAM

[Kai Huang <kai.huang@intel.com>]

On Wed, 2022-03-23 at 16:21 +1300, Tian, Kevin wrote:
> > From: Kai Huang <kai.huang@intel.com>
> > Sent: Sunday, March 13, 2022 6:50 PM
> > 
> > @@ -715,6 +716,8 @@ static void init_intel(struct cpuinfo_x86 *c)
> >       if (cpu_has(c, X86_FEATURE_TME))
> >               detect_tme(c);
> > 
> > +     tdx_detect_cpu(c);
> > +
> 
> TDX is not reported as a x86 feature. and the majority of detection
> and initialization have been conducted on demand in this series
> (as explained in patch04). Why is SEAM (and latter keyid) so different
> to be detected at early boot phase?
> 
> Thanks
> Kevin

Hi Kevin,

Sorry for late reply.  I was out last week.

SEAMRR and TDX KeyIDs are configured by BIOS and they are static during
machine's runtime.  On the other hand, TDX module can be updated and
reinitialized at runtime (not supported in this series but will be supported in
the future).  Theoretically, even P-SEAMLDR can be updated at runtime (although
I think unlikely to be supported in Linux).  Therefore I think detecting SEAMRR
and TDX KeyIDs at boot fits better.

It is also more flexible from some other perspectives I think: 1) There was a
request to add X86_FEATURE_SEAM bit and expose it to /proc/cpuinfo. I didn't add
it because I didn't think the use case was solid.  But in case someone has some
use case in the future we can add it, and detecting SEAMRR during boot fits this
more. 2) There was a request to expose TDX KeyID info via sysfs so userspace can
know how many TDs can be created.  It's not done in this series but it will be
done at some time in the future. Detecting KeyIDs at boot allows this info being
able to be exposed via sysfs at early stage, providing more flexibility to
userspace. 

At last, currently in this series the patch to handle kexec checks whether
SEAMRR and TDX KeyIDs are enabled and then flush cache (of course this is open
to discussion).  Detecting them at boot fits better I think.

-- 
Thanks,
-Kai