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: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 8/8] ahci: fix !msi interrupts
Date: Mon, 17 Jan 2011 17:48:19 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

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