On 19.10.2020 16:10, Andrew Cooper wrote: > On 19/10/2020 14:40, Jan Beulich wrote: >> Of the state saved by the insn and reloaded by the corresponding VMLOAD >> - TR, syscall, and sysenter state are invariant while having Xen's state >> loaded, >> - FS, GS, and LDTR are not used by Xen and get suitably set in PV >> context switch code. > > I think it would be helpful to state that Xen's state is suitably cached > in _svm_cpu_up(), as this does now introduce an ordering dependency > during boot.
I've added a sentence. > Is it possibly worth putting an assert checking the TR selector? That > ought to be good enough to catch stray init reordering problems. How would checking just the TR selector help? If other pieces of TR or syscall/sysenter were out of sync, we'd be hosed, too. I'm also not sure what exactly you mean to do for such an assertion: Merely check the host VMCB field against TSS_SELECTOR, or do an actual STR to be closer to what the VMSAVE actually did? >> Suggested-by: Andrew Cooper <[email protected]> >> Signed-off-by: Jan Beulich <[email protected]> > > Either way, Acked-by: Andrew Cooper <[email protected]> Thanks. Jan
