From 47132af16f616422c62befdb602903bef8f4ec5e Mon Sep 17 00:00:00 2001 From: Steven Smith Date: Tue, 31 Oct 2006 11:38:55 +0000 Subject: [PV-ON-HVM] Don't generate lots of spurious interrupts when using event channel upcalls. The issue here was that the Xen platform PCI interrupt is only updated when you return from the hypervisor into guest context, and so remained asserted for a short interval after the interrupt handler ran. If it happened that the first subsequent trap to the hypervisor was for unmasking the 8259 interrupt again, the unmasking caused the interrupt to be reinjected. This caused an edge on the chaining interrupt from the slave PIC to the master. The platform interrupt on the slave would then be cleared as we returned to the guest, and so you eventually end up injecting an interrupt on the master chained interrupt with nothing pending on the slave, which shows up as a spurious interrupt in the guest. Signed-off-by: Steven Smith --- unmodified_drivers/linux-2.6/platform-pci/evtchn.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'unmodified_drivers') diff --git a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c index 4bd9592754..d07250add5 100644 --- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c +++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c @@ -167,11 +167,17 @@ irqreturn_t evtchn_interrupt(int irq, void *dev_id, struct pt_regs *regs) l2 = s->evtchn_pending[l1i] & ~s->evtchn_mask[l1i]; } } + + /* Make sure the hypervisor has a chance to notice that the + upcall_pending condition has been cleared, so that we don't + try and reinject the interrupt again. */ + (void)HYPERVISOR_xen_version(0, NULL); + return IRQ_HANDLED; } void force_evtchn_callback(void) { - evtchn_interrupt(0, NULL, NULL); + (void)HYPERVISOR_xen_version(0, NULL); } EXPORT_SYMBOL(force_evtchn_callback); -- cgit v1.2.3