Hi Stefano Stefano Ceccherini <stefano.ceccherini@xxxxxxxxx> wrote: > I'm using old style interrupts atm, but HPET (I've converted the code > in the > kernel to a driver to ease testing) supports MSI interrupts too, but > not on > QEMU though) so I have to use regular interrupts as a fallback at > least. Ok, so I take it you're programming the HPET to directly generate an interrupt vector on the CPU? In that case you'll also have to take care to subtract the ARCH_INTERRUPT_BASE from the vector, just in case you weren't aware already. The MSI code should work as a simple example. > > If you're not going for MSIs then no, there's no API. The > > ioapic_is_interrupt_available() function tells you if a given > > interrupt is used by the IO-APIC, but there's no such thing > > for MSIs yet. > > Ok, I guess that could be sufficient, no? When MSIs are unavailable yes. Otherwise you'd most probably pick the same vectors as the MSI code though. What would work is to use ioapic_is_interrupt_available() if MSIs aren't available and use msi_allocate_vectors() if they are. The MSI allocation just reserves the vectors and generates an address/data pair, it doesn't actually program any hardware. So you can simply ignore the address/data returned and use the vectors how ever you see fit. Basically what's inside the MSI code right now should be made global (the sAllocatedVectors) and a generic allocate/free API very similar to the one in the MSI code right now should be implemented that is then used by SMP, legacy PIC, IO-APIC and MSI to reserve the corresponding vectors. I'll probably go ahead and implement this sooner rather than later if you don't want to do that yourself. For now the above should work (with MSIs and using msi_allocate_vectors() it'll always work, with IO-APIC or legacy PIC it'll only work as long as there aren't multiple drivers doing this though). Regards Michael