On 2011-01-18 13:05, Alexander Graf wrote: > > On 18.01.2011, at 10:08, Gerd Hoffmann wrote: > >> Hi, >> >>>> 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. >> >> edge triggered interrupts wouldn't though. > > The code change doesn't change anything for edge triggered interrupts - they > work fine. Only !msi (== level) ones are broken. > >> >>> 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. >> >> That re-trigger smells like you are not clearing the interrupt line where >> you should. For starters try calling ahci_check_irq() after guest writes to >> PORT_IRQ_STAT. > > The problem happened when I had the following: > > ahci irq bits = 0 > <events happen> > ahci irq bits = 1 | 2 > irq line trigger > guest clears 1 > ahci bits = 2 > <no irq line trigger, since we're still irq high> > > On normal hardware, the high state of the irq line would simply trigger > another interrupt in the guest when it gets ACKed on the LAPIC. Somehow it > doesn't get triggered here. I don't see why clearing the interrupt line would > help? It's not what real hardware would do, no? >
No, real devices would simply leave the line asserted as long as there is a reason to. So again my question: With which irqchips do you see this effect, kvm's in-kernel model and/or qemu's user space model? If there is an issue with retriggering a CPU interrupt while the source is still asserted, that probably needs to be fixed. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
