On 13/02/17 16:01, Jan Beulich wrote: >>>> On 13.02.17 at 15:32, <andrew.coop...@citrix.com> wrote: >> To avoid leaking host MSR state into guests, guest LSTAR, STAR and >> SYSCALL_MASK state is unconditionally loaded when switching into guest >> context. >> >> Attempting to dirty-track the state is pointless; host state is always >> restoring upon exit from guest context, meaning that guest state is always >> considered dirty. >> >> Drop struct vmx_msr_state, enum VMX_INDEX_MSR_* and msr_index[]. The guests >> MSR values are stored plainly in arch_vmx_struct, in the same way as >> shadow_gs >> and cstar are. vmx_restore_guest_msrs() and long_mode_do_msr_write() ensure >> that the hardware MSR values are always up-to-date. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Reviewed-by: Jan Beulich <jbeul...@suse.com> > > However, the description above made me think whether always > saving/restoring these MSRs is really needed (and desirable): > We don't need the host values in place unless we context switch > to a PV guest, so perhaps we should rather write them in > paravirt_ctxt_switch_to()?
That would leak the values between different HVM guests. In principle we could skip the update if context switching to the idle cpu, but that would involve leaking a VT-x-ism into the common code. SVM on the other hand automatically switches these MSRs on all vmentries/exits so Xen always has its MSRs in context. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
