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/
Home Products Support Community News


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