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
