On 23/12/19 18:28, Liran Alon wrote: >>> Why reset CR pinned MSRs by userspace instead of KVM INIT >>> handling? >> Most MSRs are not reset by INIT, are they? >> >> Paolo >> > MSR_KVM_SYSTEM_TIME saved in vcpu->arch.time is reset at > kvmclock_reset() which is called by kvm_vcpu_reset() (KVM INIT > handler). In addition, vmx_vcpu_reset(), called from > kvm_vcpu_reset(), also resets multiple MSRs such as: > MSR_IA32_SPEC_CTRL (vmx->spec_ctrl) and MSR_IA32_UMWAIT_CONTROL > (msr_ia32_umwait_control). These probably can be removed, since they are zero at startup and at least SPEC_CTRL is documented[1] to be unaffected by INIT. However, I couldn't find information about UMWAIT_CONTROL. > Having said that, I see indeed that most of MSRs are being set by > QEMU in kvm_put_msrs() when level >= KVM_PUT_RESET_STATE. When is > triggered by qemu_system_reset() -> cpu_synchronize_all_post_reset -> > cpu_synchronize_post_reset() -> kvm_cpu_synchronize_post_reset(). > > So given current design, OK I agree with you that CR pinned MSRs > should be zeroed by userspace VMM. > > It does though seems kinda weird to me that part of CPU state is > initialised on KVM INIT handler and part of it in userspace VMM. It > could lead to inconsistent (i.e. diverging from spec) CPU behaviour. The reason for that is the even on real hardware INIT does not touch most MSRs: 9.1 Initialization overview Asserting the INIT# pin on the processor invokes a similar response to a hardware reset. The major difference is that during an INIT, the internal caches, MSRs, MTRRs, and x87 FPU state are left unchanged (although, the TLBs and BTB are invalidated as with a hardware reset). An INIT provides a method for switching from protected to real-address mode while maintaining the contents of the internal caches. Paolo [1] https://software.intel.com/security-software-guidance/api-app/sites/default/files/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
