Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I've recently noticed that on VMWare + real hardware (unlike QEMU) I get 2 IRQs for any command,
first with D2H interrupt status (which also clears the command issue bit), and second with no interrupt status bits set, which I find kind of weird.
I don't set the interrupt on completion bit in the PDT entries, and even if I did I would expect to see bit 5
in the port interrupt status set. (I should also say that I get 2 IRQS no matter how many PRDT entries I have)
I've tried looking at the spec but didn't find anything useful. Thanks.
UPD: Actually, it does happen on QEMU as well, but the HBA interrupt status is set to 0 by the time I get the second one, heres QEMU log:
I've recently noticed that on VMWare + real hardware (unlike QEMU) I get 2 IRQs for any command,
first with D2H interrupt status (which also clears the command issue bit), and second with no interrupt status bits set, which I find kind of weird.
I've recently noticed that on VMWare + real hardware (unlike QEMU) I get 2 IRQs for any command,
first with D2H interrupt status (which also clears the command issue bit), and second with no interrupt status bits set, which I find kind of weird.
Is the IRQ shared with any other devices?
Wow, turns out it was a subtle but stupid mistake. AHCI controller sends an IRQ each time it sees that a port interrupt status (PxIS) bit is set while
HBA port IRQ status (IS.IPS) is cleared. I was clearing IS.IPS before actually servicing the port interrupt properly, so the controller was seeing that difference
multiple times therefore causing multiple IRQs.
And to answer your question im using MSIs, so it shouldnt be possible, at least in my setup. Thanks!
TBH I wish the system allowed us a larger set of interrupts. 256 interrupts is nice until you realize that you only have access to 224 of them because the other 32 are reserved, and when you've got such a small number space its easy to generate interrupt numbers that conflict with another device. And yeah, I suppose you could have a loop to check to see if an interrupt is already used but... What happens when you run out of interrupts but you still have devices left?
Ethin wrote:TBH I wish the system allowed us a larger set of interrupts. 256 interrupts is nice until you realize that you only have access to 224 of them because the other 32 are reserved, and when you've got such a small number space its easy to generate interrupt numbers that conflict with another device. And yeah, I suppose you could have a loop to check to see if an interrupt is already used but... What happens when you run out of interrupts but you still have devices left?
I would imagine if you have that many devices you also have APIC and multiple CPUs, so you'd be able to spread the IRQs around.
But as long as we're wishing, why couldn't Intel have designed the original system so that the interrupt or exception number is put on the stack along with the error code, so you don't have to create 256 separate handler stubs just to jump to a common dispatcher?
