WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Losing PS/2 Interrupts
From: Thomas Goetz <tcgoetz@xxxxxxxxx>
Date: Mon, 23 May 2011 13:16:38 -0400
Cc: Simon Graham <simon.graham@xxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Mon, 23 May 2011 10:18:02 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=DHMwTz7SylpAT0Q6eJwMbrXhIzD4o+ZtFfQlL4pmv24=; b=CYwXpul2gFj2gpQ2vUtL/Cu5z0oAa/ZX8A05AfDp0mtbSSSCqQ6Pq7eZafVtlB3E3p rgETGgzWRiR2GQPhN4BkYjl45lHVxP5UgdVRvG8jTkmutq47wYWnfOtUtPMcKRqfmD70 poBfVEPHxyxY4fkiW90zubkRfWY7sRq+uOUXY=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=q+QpuHykUWJmsXA8kHzPIWTBb12u2URSnONKk0xybNS/zQMwzuHmCDBuuIqShIlYqN ls3BfnQQEmmAglOHOGsdCBR7uvnCMjQFCwQH/Z1wUkUzKSR3YKlnQIEadYIgZDVw2WNM FLgxXapdepg9HfhJoon+otb5/Acpzmz5pEejY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1105231413020.12963@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <3E2050B5-59DC-4E4F-9C8D-8C04A6B465EB@xxxxxxxxx> <F85CBA5B-F58C-416A-BF2C-ECE8BC62614F@xxxxxxxxx> <20110520175044.GA30367@xxxxxxxxxxxx> <5D477258-8216-48BD-8A93-186E044118B9@xxxxxxxxx> <4DDA366E0200007800042C71@xxxxxxxxxxxxxxxxxx> <1D3BFCDD-9D53-48BA-9ECD-D009AD535C2B@xxxxxxxxx> <alpine.DEB.2.00.1105231413020.12963@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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