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

[Xen-devel] Re: [PATCH][FIX] Possible fix for spurious interrupts

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 14.04.06 20:42:18 >>>
>
>On 14 Apr 2006, at 18:42, Jan Beulich wrote:
>
>> This looks questionable to me (even after your follow-up mails). You 
>> are, in this mode, ack-ing the interrupt before the
>> handler even gets invoked. I would expect level triggered interrupts 
>> to fire again right away then if you don't manage
>> to run the handling domain before re-enabling interrupts. Of course, I 
>> haven't seen your later attempts at fixing the
>> problem, but am I missing something here?
>
>Yes, I ack *after* the handlers have executed. The ack is in the ->end 
>handler.

Oh, I see. I was looking at the patch only (at home), and missed that its main 
change was to the end routine.

>This is dodgy too on Xen unfortunately. All lower priority interrupts 
>are blocked until the driver domain sees fit to tell Xen it's finished 
>ISR processing. But if a large proportion of x86 hardware is screwed 
>with respect to IO-APIC masking then we have no choice but to get this 
>scheme to work. I look forward to the day when MSI is ubiquitous.

... and even worse when the interrupt belongs to a domU.

Have you heard anything from Intel on this? I am still hoping that there is a 
pattern which interrupt gets triggered by
masking a certain other one, so a (perhaps more complex, but less impacting) 
fix could be derived...

Jan

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