On Mon, Nov 29, 2021 at 5:16 PM Chao Gao <chao.gao@xxxxxxxxx> wrote: > >I did not find the information in intel-tdx-module-1eas.pdf nor > >intel-tdx-cpu-architectural-specification.pdf. > > > >Maybe the version I downloaded is outdated. > > Hi Jiangshan, > > Please refer to Table 22.162 MSRs that may be Modified by TDH.VP.ENTER, > in section 22.2.40 TDH.VP.ENTER leaf. No file in this link: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html has chapter 22. > > > > >I guess that the "lazy" restoration mode is not a valid optimization. > >The SEAM module should restore it to the original value when it tries > >to reset it to architectural INIT state on exit from TDX VM to KVM > >since the SEAM module also does it via wrmsr (correct me if not). > > Correct. > > > > >If the SEAM module doesn't know "the original value" of the these > >MSRs, it would be mere an optimization to save an rdmsr in SEAM. > > Yes. Just a rdmsr is saved in TDX module at the cost of host's > restoring a MSR. If restoration (wrmsr) can be done in a lazy fashion > or even the MSR isn't used by host, some CPU cycles can be saved. But it adds overall overhead because the wrmsr in TDX module can't be skipped while the unneeded potential overhead of wrmsr is added in user return path. If TDX module restores the original MSR value, the host hypervisor doesn't need to step in. I think I'm reviewing the code without the code. It is definitely wrong design to (ab)use the host's user-return-msr mechanism. > > >But there are a lot of other ways for the host to share the values > >to SEAM in zero overhead. > > I am not sure. Looks it requests a new interface between host and TDX > module. I guess one problem is how/when to verify host's inputs in case > they are invalid. > If the requirement of "lazy restoration" is being added (not seen in the published document yet), you are changing the ABI between the host and the TDX module.
