qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 8/8] ahci: fix !msi interrupts


From: Alexander Graf
Subject: [Qemu-devel] Re: [PATCH 8/8] ahci: fix !msi interrupts
Date: Mon, 17 Jan 2011 17:50:11 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Jan Kiszka wrote:
> On 2011-01-17 17:33, Alexander Graf wrote:
>   
>> Jan Kiszka wrote:
>>     
>>> On 2011-01-17 17:04, Alexander Graf wrote:
>>>   
>>>       
>>>> Jan Kiszka wrote:
>>>>     
>>>>         
>>>>> On 2011-01-17 17:00, Alexander Graf wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Jan Kiszka wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> On 2010-12-20 22:13, Alexander Graf wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> When not using MSI, receiving an interrupt while the interrupt line is 
>>>>>>>> active
>>>>>>>> pulses the interrupt line. Without this, guests don't realize that a 
>>>>>>>> new
>>>>>>>> interrupt occured.
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> This doesn't look OK. The device model should look at the currently used
>>>>>>> mode and switch between edge and level triggering accordingly. As it
>>>>>>> appears like this is what it already does, this change may just paper
>>>>>>> over the real issue.
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> Well, I have this internal abstraction to make edge and level triggered
>>>>>> interrupt triggering easier. irq_lower is a simple nop for the edge case.
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> I'm concerned about the artificial edge you generate for the level
>>>>> triggered case. That's not like real hw behaves. If you need it,
>>>>> something else might still be broken.
>>>>>   
>>>>>       
>>>>>           
>>>> Hrm. So worst case we generate a spurious interrupt?
>>>>
>>>>     
>>>>         
>>> Worse might also be that unknown issue that force you to inject an IRQ
>>> here. We don't know. That's probably worst.
>>>   
>>>       
>> Well, IIRC the issue was that usually a level high interrupt line would
>> simply retrigger an interrupt after enabling the interrupt line in the
>> APIC again. Unless my memory completely fails on me, that didn't happen,
>> so I added the manual retrigger on a partial command ACK in ahci code.
>>
>>     
>
> How many other device models require this workaround? And is this a
> limitation of a specific irqchip model or of the irq layer (I can't
> believe it's the latter though)? All fairly suspicious...
>   

I don't know :).


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]