alice wan
2010-Oct-15 07:51 UTC
[Xen-devel] still lockup due to interrupt lost after backport from 2.6.31 to 2.6.32 in events.c
Hi all, Recently i met a problem about domU lockup. i traced this problem and knew that it may be caused by irq balancing.>From xen-devel community, it''s known that the workaround is to turn off irqbalancing. After testing , it actually worked. However, i studied the kernel of 2.6.32 which has already fix this bug, there''re some doubt about the difference between 2.6.32 and 2.6.31(pvops), because after i tried to backport this patch, domU still locked up. In my opinion , the difference is mainly in events.c, the important difference as following: 1. void xen_evtchn_do_upcall(struct pt_regs *regs) int irq = evtchn_to_irq[port]; struct irq_desc *desc; + mask_evtchn(port); + clear_evtchn(port); + if (irq != -1) { 2. static void ack_pirq(unsigned int irq) move_masked_irq(irq); - if (VALID_EVTCHN(evtchn)) { - mask_evtchn(evtchn); - clear_evtchn(evtchn); - } + pirq_eoi(irq); here, pirq_eoi ''ll be called by handle_fasteoi_irq function in desc->chip->eoi(irq). 3. use percpu_interrupts for IPIs and VIRQs 4. use fasteoi handler for pirq ,events,msi. *my question is how 2.6.31 drops interrupts if migrate an irq beween vcpus while an event is pending and what main points that 2.6.32 fixes about not dropping are.* i wanna know whether it matters with the advance of mask_evtchn in *Point 1*to avoid new interrupt coming or whether it matters with eoi called by handle_fasteoi_irq when status is in *IRQ_INPROGRESS*. because handle_level_irq and handle_fasteoi_irq is almost the same except the branch of IRQ_INPROGRESS. Or it matters with other points that i haven''t find. Deeply looking forward to your disabusing and advice. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel