On Mon, Nov 29, 2021 at 2:00 AM Chao Gao <chao.gao@xxxxxxxxx> wrote: > > On Thu, Nov 25, 2021 at 09:34:59PM +0100, Thomas Gleixner wrote: > >On Wed, Nov 24 2021 at 16:20, isaku yamahata wrote: > >> From: Chao Gao <chao.gao@xxxxxxxxx> > > > >> $Subject: KVM: x86: Add a helper function to restore 4 host MSRs on exit to user space > > > >Which user space are you talking about? This subject line is misleading > > Host Ring3. > > >at best. The unconditional reset is happening when a TDX VM exits > >because the SEAM firmware enforces this to prevent unformation leaks. > > Yes. > > > > >It also does not matter whether this are four or ten MSR. > > Indeed, the number of MSRs doesn't matter. > > >Fact is that > >the SEAM firmware is buggy because it does not save/restore those MSRs. > > It is done deliberately. It gives host a chance to do "lazy" restoration. > "lazy" means don't save/restore them on each TD entry/exit but defer > restoration to when it is neccesary e.g., when vCPU is scheduled out or > when kernel is about to return to Ring3. > > The TDX module unconditionally reset 4 host MSRs (MSR_SYSCALL_MASK, > MSR_START, MSR_LSTAR, MSR_TSC_AUX) to architectural INIT state on exit from > TDX VM to KVM. 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. 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). 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. But there are a lot of other ways for the host to share the values to SEAM in zero overhead. Could you provide more information?
