On Wed, 2022-03-23 at 16:21 +1300, Tian, Kevin wrote: > > From: Kai Huang <kai.huang@xxxxxxxxx> > > 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
