summaryrefslogtreecommitdiffstats
path: root/arch/m32r/Kconfig
diff options
context:
space:
mode:
authorLadi Prosek <lprosek@redhat.com>2017-04-25 16:42:44 +0200
committerPaolo Bonzini <pbonzini@redhat.com>2017-04-27 16:54:09 +0200
commit6ed071f051e12cf7baa1b69d3becb8f232fdfb7b (patch)
tree35c9e9c1b1d9a2e6d18181fce59bb1c177460b52 /arch/m32r/Kconfig
parent7a97cec26b94c909f4cbad2dc3186af3e457a522 (diff)
downloadop-kernel-dev-6ed071f051e12cf7baa1b69d3becb8f232fdfb7b.zip
op-kernel-dev-6ed071f051e12cf7baa1b69d3becb8f232fdfb7b.tar.gz
KVM: x86: fix emulation of RSM and IRET instructions
On AMD, the effect of set_nmi_mask called by emulate_iret_real and em_rsm on hflags is reverted later on in x86_emulate_instruction where hflags are overwritten with ctxt->emul_flags (the kvm_set_hflags call). This manifests as a hang when rebooting Windows VMs with QEMU, OVMF, and >1 vcpu. Instead of trying to merge ctxt->emul_flags into vcpu->arch.hflags after an instruction is emulated, this commit deletes emul_flags altogether and makes the emulator access vcpu->arch.hflags using two new accessors. This way all changes, on the emulator side as well as in functions called from the emulator and accessing vcpu state with emul_to_vcpu, are preserved. More details on the bug and its manifestation with Windows and OVMF: It's a KVM bug in the interaction between SMI/SMM and NMI, specific to AMD. I believe that the SMM part explains why we started seeing this only with OVMF. KVM masks and unmasks NMI when entering and leaving SMM. When KVM emulates the RSM instruction in em_rsm, the set_nmi_mask call doesn't stick because later on in x86_emulate_instruction we overwrite arch.hflags with ctxt->emul_flags, effectively reverting the effect of the set_nmi_mask call. The AMD-specific hflag of interest here is HF_NMI_MASK. When rebooting the system, Windows sends an NMI IPI to all but the current cpu to shut them down. Only after all of them are parked in HLT will the initiating cpu finish the restart. If NMI is masked, other cpus never get the memo and the initiating cpu spins forever, waiting for hal!HalpInterruptProcessorsStarted to drop. That's the symptom we observe. Fixes: a584539b24b8 ("KVM: x86: pass the whole hflags field to emulator and back") Signed-off-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'arch/m32r/Kconfig')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud