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

>>> On 23.05.11 at 14:09, Thomas Goetz <tcgoetz@xxxxxxxxx> 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 

That would be a bug in the control flow then. In our (non-pvops)
kernel we make sure to clear the pending bit *before* calling
handle_irq() (and after masking the event channel), which clearly
is a requirement at least for edge triggered interrupts (not
necessarily before calling handle_irq(), but before calling the
device driver's handler, i.e. in chip->ack()).

Jan

> 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?
> 
> ---
> Tom Goetz
> tcgoetz@xxxxxxxxx 




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