[Xen-changelog] Under some specific conditions, dom0 will lose guest timer interrupt.

[Xen patchbot -3.0-testing <patchbot-3.0-testing@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User djm@xxxxxxxxxxxxxxx
# Node ID a0d69e58540b138ba9d7d0f7c279de1d3354a2ac
# Parent  ae7f8b7e9aa24f3e4d3c38e9597cbafe131b89b6
Under some specific conditions, dom0 will lose guest timer interrupt.
Signed-off-by Anthony Xu <anthony.xu@xxxxxxxxx>
Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
The reason is that Xen/ia64 will try to pend guest timer interrupt to dom0
within each machine timer interrupt handler. To avoid duplicated delivery, 
domain_itm_last recorded domain_itm of last injection. If two are identical,
it means interrupt injected but guest has not set new itm value. Or else
corresponding pending irr bit will be turned on. That works in most cases.

However currently guest linux may try to set itm multiple times within one
handler before turn on psr.i again. Among first few settings, new guest timer
interrupt may be pended. Then once guest linux enables interrupt, a new
timer interrupt will be injected immediately. However this injection may have
itc still smaller than the domain_itm set at the last round of last handle.
In this case, guest linux will set same domain_itm as last again. However
since domain_itm_last already equals to domain_itm at last read ivr, later
no guest timer interrupt can be injected any more since Xen always thinks
an instance already injected without guest's response.

Attahced patch fixed this issue by adding sanity check upon guest timer
vector when deciding to inject interrupt into dom0. We always compare current
itc with latest domain_itm that guest really wants. So if itc < domain_itm
at this point, we simply clear the pending bit and no injection.

There's also a small fix to vcpu_read_ivr, where domain_itm_last should
be updated before clearing irr bit. Or els a small window still remains
to add a duplicate interrupt.

xen-unstable cset: f998426f9069aa9e4e060ceb48a3cd9cfc1231d9
committer: Robert Read <robert@xxxxxxxxxxxxx>

diff -r ae7f8b7e9aa2 -r a0d69e58540b xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c  Fri Dec 16 15:43:00 2005
+++ b/xen/arch/ia64/xen/vcpu.c  Thu Dec 15 14:07:47 2005
@@ -676,6 +676,7 @@
         * event injection without handle. Later guest may throw out
         * the event itself.
         */
+check_start:
        if (event_pending(vcpu) && 
                !test_bit(vcpu->vcpu_info->arch.evtchn_vector,
                        &PSCBX(vcpu, insvc[0])))
@@ -702,6 +703,15 @@
 //printf("XXXXXXX vcpu_check_pending_interrupts: got bitnum=%p...",bitnum);
        vector = bitnum+(i*64);
        mask = 1L << bitnum;
+       /* sanity check for guest timer interrupt */
+       if (vector == (PSCB(vcpu,itv) & 0xff)) {
+               uint64_t now = ia64_get_itc();
+               if (now < PSCBX(vcpu,domain_itm)) {
+                       printk("Ooops, pending guest timer before its due\n");
+                       PSCBX(vcpu,irr[i]) &= ~mask;
+                       goto check_start;
+               }
+       }
 //printf("XXXXXXX vcpu_check_pending_interrupts: got vector=%p...",vector);
        if (*r >= mask) {
                // masked by equal inservice
@@ -798,6 +808,13 @@
                firsttime[vector]=0;
        }
 #endif
+       /* if delivering a timer interrupt, remember domain_itm, which
+        * needs to be done before clearing irr
+        */
+       if (vector == (PSCB(vcpu,itv) & 0xff)) {
+               PSCBX(vcpu,domain_itm_last) = PSCBX(vcpu,domain_itm);
+       }
+
        i = vector >> 6;
        mask = 1L << (vector & 0x3f);
 //printf("ZZZZZZ vcpu_get_ivr: setting insvc mask for vector %ld\n",vector);
@@ -805,10 +822,6 @@
        PSCBX(vcpu,irr[i]) &= ~mask;
        //PSCB(vcpu,pending_interruption)--;
        *pval = vector;
-       // if delivering a timer interrupt, remember domain_itm
-       if (vector == (PSCB(vcpu,itv) & 0xff)) {
-               PSCBX(vcpu,domain_itm_last) = PSCBX(vcpu,domain_itm);
-       }
        return IA64_NO_FAULT;
 }
 

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