[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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

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
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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.