direct-io.hg

changeset 14596:6664a713f55f

hvm svm: Do not deliver virtual interrupts concurrently with virtual exceptions.
Signed-off-by: Keir Fraser <keir@xensource.com>
author kfraser@localhost.localdomain
date Tue Mar 27 19:05:48 2007 +0100 (2007-03-27)
parents c489a25c9f9a
children 104fc282e53c
files xen/arch/x86/hvm/svm/intr.c
line diff
     1.1 --- a/xen/arch/x86/hvm/svm/intr.c	Tue Mar 27 18:53:05 2007 +0100
     1.2 +++ b/xen/arch/x86/hvm/svm/intr.c	Tue Mar 27 19:05:48 2007 +0100
     1.3 @@ -68,6 +68,20 @@ asmlinkage void svm_intr_assist(void)
     1.4      int intr_vector = -1;
     1.5  
     1.6      /*
     1.7 +     * Do not deliver a virtual interrupt (vintr) if an exception is pending.
     1.8 +     * This is because the delivery of the exception can arbitrarily delay
     1.9 +     * the injection of the vintr (for example, if the exception is handled
    1.10 +     * via an interrupt gate, hence zeroing RFLAGS.IF). In the meantime the
    1.11 +     * vTPR can be modified upwards and we can end up delivering the vintr
    1.12 +     * when it is not in fact valid to do so (because we do not re-check the
    1.13 +     * vTPR value). Moreover, the guest will be able to see the updated
    1.14 +     * APIC/PIC state (as if the interrupt had been acknowledged) yet will not
    1.15 +     * have actually received the interrupt. This could confuse the guest!
    1.16 +     */
    1.17 +    if ( vmcb->eventinj.fields.v )
    1.18 +        return;
    1.19 +
    1.20 +    /*
    1.21       * Previous Interrupt delivery caused this intercept?
    1.22       * This will happen if the injection is latched by the processor (hence
    1.23       * clearing vintr.fields.irq) but then subsequently a fault occurs (e.g.,