Re: [Xen-devel] Re: Losing PS/2 Interrupts

[Thomas Goetz <tcgoetz@xxxxxxxxx>]

On May 23, 2011, at 9:45 AM, Stefano Stabellini wrote:

> On Mon, 23 May 2011, Thomas Goetz wrote:
>> My assumption is that at the point that the i8042 driver reads the data 
>> register a new interrupt happens. There is gap in
>> time between when the data register is read and when the event channel 
>> pending state is cleared. Since the hypervisor
>> ACKed the previous real interrupt before delivering it to the guest, there 
>> is nothing to stop the i8042 device from
>> interrupting immediately after the data register is read. If it interrupt 
>> before the event channel pending state is
>> cleared, then it will not be delivered to the guest and the EOI mechanism 
>> will be set up, but I haven't found anything in
>> that that will set up a delayed delivery of the second interrupt.
>> 
>> In this situation the i8042 device has every reason to believe the second 
>> interrupt will be delivered. The previous
>> interrupt was received and handled. Nothing is masked.
>> 
>> Am I missing something?
> 
> 
> I am assuming you have the latest version of my fixes to
> drivers/xen/events.c

I'll have a version ported from your 2.6.39 tree to my 2.6.38 tree. I'll update 
my copy of your tree and make sure it's up to date.

> 
> The problem you are describing shouldn't happen because the interrupt
> handler returned by request_irq to i8042 is handle_edge_irq that calls
> chip->irq_ack() before handle_irq_event().

I checked on which method it is using and it's using handle_fasteoi_irq. In 
fatc all of the IRQs under 16 are despite most being edge. Log snippet below. 
I'm looking into why pirq_needs_eoi is returning the wrong answer now.

> We implement irq_ack with a clear_evtchn() so by the time
> i8042_interrupt is called the event channel should have already been
> cleared.
> 
> If a second interrupt is asserted right after i8042_interrupt reads the
> data port, handle_edge_irq is called again and this time because another
> interrupt of the same kind is already being handled, it will call
> mask_ack_irq().
> On Xen this translates to mask_evtchn() and clear_evtchn(), so once
> again the event channel pending bit should be cleared.

May 23 16:52:00 jcf kernel: [   35.075367]  [<ffffffff8143fb71>] ? 
i8042_interrupt+0x221/0x410
May 23 16:52:00 jcf kernel: [   35.075373]  [<ffffffff81292f8b>] ? 
radix_tree_lookup+0xb/0x10
May 23 16:52:00 jcf kernel: [   35.075379]  [<ffffffff810ce014>] ? 
handle_IRQ_event+0x54/0x180
May 23 16:52:00 jcf kernel: [   35.075384]  [<ffffffff810d08b4>] ? 
handle_fasteoi_irq+0x84/0x110
May 23 16:52:00 jcf kernel: [   35.075389]  [<ffffffff81324077>] ? 
__xen_evtchn_do_upcall+0x1a7/0x270
May 23 16:52:00 jcf kernel: [   35.075395]  [<ffffffff81007c6f>] ? 
xen_restore_fl_direct_end+0x0/0x1
May 23 16:52:00 jcf kernel: [   35.075399]  [<ffffffff81325def>] ? 
xen_evtchn_do_upcall+0x2f/0x50
May 23 16:52:00 jcf kernel: [   35.075404]  [<ffffffff8100ceae>] ? 
xen_do_hypervisor_callback+0x1e/0x30
May 23 16:52:00 jcf kernel: [   35.075407]  <EOI>  [<ffffffff810012eb>] ? 
hypercall_page+0x2eb/0x1000

[    0.000000] xen_map_pirq_gsi: irq 1 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 2 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 3 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 4 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 5 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 6 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 7 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 8 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9
[    0.000000] xen_map_pirq_gsi: irq 10 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 11 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 12 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 13 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 14 handle_fasteoi_irq
[    0.000000] xen_map_pirq_gsi: irq 15 handle_fasteoi_irq

 1:          8          0  xen-pirq-ioapic-edge  i8042
 3:          1          0  xen-pirq-ioapic-edge
 4:          1          0  xen-pirq-ioapic-edge
 5:          1          0  xen-pirq-ioapic-edge
 7:          1          0  xen-pirq-ioapic-edge
 8:          0          0  xen-pirq-ioapic-edge  rtc0
 9:       1129          0  xen-pirq-ioapic-level  acpi
10:          1          0  xen-pirq-ioapic-edge
11:          1          0  xen-pirq-ioapic-edge
12:       4032          0  xen-pirq-ioapic-edge  i8042
14:        153          0  xen-pirq-ioapic-edge  ata_piix
15:          0          0  xen-pirq-ioapic-edge  ata_piix

---
Tom Goetz
tcgoetz@xxxxxxxxx




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