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 irq balancing. 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|