This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-changelog] [xen-unstable] hvm svm: Do not deliver virtual interrupt

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-unstable] hvm svm: Do not deliver virtual interrupts concurrently with virtual exceptions.
From: Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 16:10:43 -0700
Delivery-date: Tue, 27 Mar 2007 16:22:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-unstable] hvm svm: Do not deliver virtual interrupts concurrently with virtual exceptions., Xen patchbot-unstable <=