History log of /haiku/headers/private/kernel/arch/x86/ioapic.h
Revision Date Author Comments
# e223e8e9 29-May-2023 Augustin Cavalier <waddlesplash@gmail.com>

kernel/x86: Initialize IO-APIC only after PCI enumeration is complete.

Before the PCI refactor, PCI initialization/enumeration occurred
immediately after the PCI module was loaded, and so by the time
we got to IOAPIC initialization, it was already complete.

After the refactor, PCI enumeration is deferred until slightly later,
and so we would try to initialize IO-APICs without knowing PCI
information. This would fail, as read_irq_routing_table needs to
have that available.

Hopefully fixes #18425, #18393, #18398.

Change-Id: I1e4b06367da26eeb10085a1c6322ed39885b632b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6476
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# 8908aef9 13-May-2011 Michael Lotz <mmlr@mlotz.ch>

* Don't map the IO-APIC within the bootloader. We don't need it to set up SMP
at all and, since there can be multiple IO-APICs, we need to do the
enumeration again in the kernel anyway. Also only set ioapic_phys the first
time we encounter an IO-APIC object as it looks cleaner when we arrive at the
first IO-APIC default address.
* Therefore we don't have to worry about already mapped IO-APICs when
enumerating them in the kernel.
* Also remove the mapping function that is now not used anymore.
* We still use the ioapic_phys field of the kernel args to determine whether
there is an IO-APIC at all to avoid needlessly doing the enumeration again.

This fixes multi IO-APIC configurations, because before we would indeed map
the last IO-APIC listed in the MADT, but then in the kernel assumed we mapped
the first one. We'd end up with mapping the last listed IO-APIC twice and the
first IO-APIC never, always programming the last one when we actually targetted
the first one.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41476 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a56cbb2a 11-May-2011 Michael Lotz <mmlr@mlotz.ch>

* When initializing MSI support, don't assume a single 24 entry IO-APIC. Instead
mark the ISA interrupts as unusable and then use ioapic_is_interrupt_available
to determine if that vector is possibly taken by an IO-APIC. If IO-APICs are
not used, this will simply always return false, leaving all vectors free for
MSI use.
* The msi_init() now has to be done after a potential IO-APIC init, so it is now
done after ioapic_init() instead of inside apic_init().
* Add apic_disable_local_ints() to clear the local ints on the local APIC once
we are in APIC mode (i.e. the IO-APIC is set up and we don't need the external
routing anymore).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41445 a95241bf-73f2-0310-859d-f6bbb57e9c96


# dc14d97b 10-May-2011 Michael Lotz <mmlr@mlotz.ch>

* Move the legacy PIC and the IO-APIC code into their own source file. No
functional change intended.
* Use an appropriately sized sLevelTriggeredInterrupts for each controller type.
This also fixes an out of bound access for IO-APICs with more than 32 entries
and also returns the right mode in such cases.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41426 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8908aef9c2c62225bce2d8216e81397c872316e8 13-May-2011 Michael Lotz <mmlr@mlotz.ch>

* Don't map the IO-APIC within the bootloader. We don't need it to set up SMP
at all and, since there can be multiple IO-APICs, we need to do the
enumeration again in the kernel anyway. Also only set ioapic_phys the first
time we encounter an IO-APIC object as it looks cleaner when we arrive at the
first IO-APIC default address.
* Therefore we don't have to worry about already mapped IO-APICs when
enumerating them in the kernel.
* Also remove the mapping function that is now not used anymore.
* We still use the ioapic_phys field of the kernel args to determine whether
there is an IO-APIC at all to avoid needlessly doing the enumeration again.

This fixes multi IO-APIC configurations, because before we would indeed map
the last IO-APIC listed in the MADT, but then in the kernel assumed we mapped
the first one. We'd end up with mapping the last listed IO-APIC twice and the
first IO-APIC never, always programming the last one when we actually targetted
the first one.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41476 a95241bf-73f2-0310-859d-f6bbb57e9c96


# a56cbb2afbf4dbfb4a07dfdd95f10637a195a053 11-May-2011 Michael Lotz <mmlr@mlotz.ch>

* When initializing MSI support, don't assume a single 24 entry IO-APIC. Instead
mark the ISA interrupts as unusable and then use ioapic_is_interrupt_available
to determine if that vector is possibly taken by an IO-APIC. If IO-APICs are
not used, this will simply always return false, leaving all vectors free for
MSI use.
* The msi_init() now has to be done after a potential IO-APIC init, so it is now
done after ioapic_init() instead of inside apic_init().
* Add apic_disable_local_ints() to clear the local ints on the local APIC once
we are in APIC mode (i.e. the IO-APIC is set up and we don't need the external
routing anymore).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41445 a95241bf-73f2-0310-859d-f6bbb57e9c96


# dc14d97b7f70aa318483d53e007913b26a12f5d0 10-May-2011 Michael Lotz <mmlr@mlotz.ch>

* Move the legacy PIC and the IO-APIC code into their own source file. No
functional change intended.
* Use an appropriately sized sLevelTriggeredInterrupts for each controller type.
This also fixes an out of bound access for IO-APICs with more than 32 entries
and also returns the right mode in such cases.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41426 a95241bf-73f2-0310-859d-f6bbb57e9c96