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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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

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().
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.

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