stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Patch "KVM: x86: inject exceptions produced by x86_decode_insn" has been added to the 4.9-stable tree
@ 2017-12-04 10:53 gregkh
  0 siblings, 0 replies; only message in thread
From: gregkh @ 2017-12-04 10:53 UTC (permalink / raw)
  To: pbonzini, ehabkost, gregkh, rkrcmar, yfu; +Cc: stable, stable-commits


This is a note to let you know that I've just added the patch titled

    KVM: x86: inject exceptions produced by x86_decode_insn

to the 4.9-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From 6ea6e84309ca7e0e850b3083e6b09344ee15c290 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 10 Nov 2017 10:49:38 +0100
Subject: KVM: x86: inject exceptions produced by x86_decode_insn
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Paolo Bonzini <pbonzini@redhat.com>

commit 6ea6e84309ca7e0e850b3083e6b09344ee15c290 upstream.

Sometimes, a processor might execute an instruction while another
processor is updating the page tables for that instruction's code page,
but before the TLB shootdown completes.  The interesting case happens
if the page is in the TLB.

In general, the processor will succeed in executing the instruction and
nothing bad happens.  However, what if the instruction is an MMIO access?
If *that* happens, KVM invokes the emulator, and the emulator gets the
updated page tables.  If the update side had marked the code page as non
present, the page table walk then will fail and so will x86_decode_insn.

Unfortunately, even though kvm_fetch_guest_virt is correctly returning
X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as
a fatal error if the instruction cannot simply be reexecuted (as is the
case for MMIO).  And this in fact happened sometimes when rebooting
Windows 2012r2 guests.  Just checking ctxt->have_exception and injecting
the exception if true is enough to fix the case.

Thanks to Eduardo Habkost for helping in the debugging of this issue.

Reported-by: Yanan Fu <yfu@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kvm/x86.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5579,6 +5579,8 @@ int x86_emulate_instruction(struct kvm_v
 			if (reexecute_instruction(vcpu, cr2, write_fault_to_spt,
 						emulation_type))
 				return EMULATE_DONE;
+			if (ctxt->have_exception && inject_emulated_exception(vcpu))
+				return EMULATE_DONE;
 			if (emulation_type & EMULTYPE_SKIP)
 				return EMULATE_FAIL;
 			return handle_emulation_failure(vcpu);


Patches currently in stable-queue which might be from pbonzini@redhat.com are

queue-4.9/kvm-lapic-fixup-ldr-on-load-in-x2apic.patch
queue-4.9/kvm-x86-inject-exceptions-produced-by-x86_decode_insn.patch
queue-4.9/kvm-x86-exit-to-user-mode-on-ud-intercept-when-emulator-requires.patch
queue-4.9/kvm-lapic-split-out-x2apic-ldr-calculation.patch
queue-4.9/kvm-x86-pvclock-handle-first-time-write-to-pvclock-page-contains-random-junk.patch

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2017-12-04 10:54 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-12-04 10:53 Patch "KVM: x86: inject exceptions produced by x86_decode_insn" has been added to the 4.9-stable tree gregkh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).