[Xen-changelog] [xen-unstable] hvm svm: Do not deliver virtual interrupts concurrently with virtual exceptions.

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User kfraser@xxxxxxxxxxxxxxxxxxxxx
# Date 1175018748 -3600
# Node ID 6664a713f55f8699f41063ae5c8b404a8f5d803a
# Parent  c489a25c9f9a68268728ffdb33176759763b1cd5
hvm svm: Do not deliver virtual interrupts concurrently with virtual exceptions.
Signed-off-by: Keir Fraser <keir@xxxxxxxxxxxxx>
---
 xen/arch/x86/hvm/svm/intr.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+)

diff -r c489a25c9f9a -r 6664a713f55f xen/arch/x86/hvm/svm/intr.c
--- a/xen/arch/x86/hvm/svm/intr.c       Tue Mar 27 18:53:05 2007 +0100
+++ b/xen/arch/x86/hvm/svm/intr.c       Tue Mar 27 19:05:48 2007 +0100
@@ -68,6 +68,20 @@ asmlinkage void svm_intr_assist(void)
     int intr_vector = -1;
 
     /*
+     * Do not deliver a virtual interrupt (vintr) if an exception is pending.
+     * This is because the delivery of the exception can arbitrarily delay
+     * the injection of the vintr (for example, if the exception is handled
+     * via an interrupt gate, hence zeroing RFLAGS.IF). In the meantime the
+     * vTPR can be modified upwards and we can end up delivering the vintr
+     * when it is not in fact valid to do so (because we do not re-check the
+     * vTPR value). Moreover, the guest will be able to see the updated
+     * APIC/PIC state (as if the interrupt had been acknowledged) yet will not
+     * have actually received the interrupt. This could confuse the guest!
+     */
+    if ( vmcb->eventinj.fields.v )
+        return;
+
+    /*
      * Previous Interrupt delivery caused this intercept?
      * This will happen if the injection is latched by the processor (hence
      * clearing vintr.fields.irq) but then subsequently a fault occurs (e.g.,

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog