OSDev.org

Hi everyone. My turn to ask a question rather than answer

I have been reading about the APIC (Advanced Programmable Interrupt Controller) and know that it is a necessity for multiprocessor systems if your OS is capable of using more than one processor. However, my question is, other than the included timer that comes along with it, is there any advantage to detecting, initializing, and using the APIC on a uniprocessor system or an OS that is only uniprocessor capable?

As I see it, you still have to use the (emulated) 8259 for IRQ's and still only have the 15 vectors to choose from.

If you are going to use MSI's, I guess you need to have an APIC?

Anyway, what advantages does the APIC have in a uniprocessor system, besides the extras such as the timer?

If you only support one processor, do you need to even detect and initialize the APIC?

Now, to even confuse you and myself even more, the above is considered the Local APIC. What about the I/O APIC?

The I/O APIC, from what little reading I have done so far, does allow up to 24 vectors. Eight plus one more than the 8259.
In a uniprocessor or multiprocessor system, it is probably an advantage to detect, initialize, and use the I/O APIC so that you can now use 24 IRQ lines?

Anyway, I am just looking for your opinions on this, especially with a uniprocessor system/OS.

Thank you,
Ben
http://www.fysnet.net/osdesign_book_series.htm

Yes, there are several reasons why you would want to use the APIC on modern PCs, even if they are only single core, or your OS only uses one core:

1. The legacy PIC is only there for compatibility on modern systems, and so might not even exist on some systems (which will become more common too).
2. The IOAPIC supports more interrupt sources (you can have more than 24 by adding two IOAPICs).
3. You can use MSI
4. The APIC is much faster

Hi,

BenLunt wrote:Hi everyone. My turn to ask a question rather than answer

I have been reading about the APIC (Advanced Programmable Interrupt Controller) and know that it is a necessity for multiprocessor systems if your OS is capable of using more than one processor. However, my question is, other than the included timer that comes along with it, is there any advantage to detecting, initializing, and using the APIC on a uniprocessor system or an OS that is only uniprocessor capable?

As I see it, you still have to use the (emulated) 8259 for IRQ's and still only have the 15 vectors to choose from.

If you are going to use MSI's, I guess you need to have an APIC?

Anyway, what advantages does the APIC have in a uniprocessor system, besides the extras such as the timer?

If you only support one processor, do you need to even detect and initialize the APIC?

Now, to even confuse you and myself even more, the above is considered the Local APIC. What about the I/O APIC?

Advantages of local APIC (instead of "nothing") for single-CPU:

• Provides the single best (for precision and overhead) timer that will ever exist
• Potentially useful for power management (to determine if/when the CPU has entered thermal throttling mode)
• Potentially needed for profiling and debugging (performance monitoring counter overflows, etc)
• "Send IPI to self" might (or might not) be useful or convenient for "deferred procedure call" functionality in restricted code (e.g. IRQ handlers)

Advantages of using IO APIC (instead of PIC) for single-CPU:

• Lower overhead interface (fast memory mapped registers rather than slow legacy IO ports)
• Needed for MSI
• Typically more IRQ lines (and less IRQ sharing, even without MSI). This means less overhead when an IRQ occurs (because you don't need to ask multiple device drivers to tend to their device)

BenLunt wrote:The I/O APIC, from what little reading I have done so far, does allow up to 24 vectors. Eight plus one more than the 8259.

No; a single IO APIC with 24 inputs is just "relatively more common".

Nothing (no standard, etc) prevents a system from having (e.g.) 12 separate IO APICs with one input per IO APIC (a combined total of 12 inputs, where some legacy ISA stuff can't be connected and lots of PCI IRQ sharing would happen); and nothing prevents a system from having a single IO APIC with 128 inputs; and nothing prevents a system from having one IO APIC with 4 inputs, another IO APIC with 8 inputs and a third IO APIC with 12 inputs (a combined total of 24 inputs).

BenLunt wrote:In a uniprocessor or multiprocessor system, it is probably an advantage to detect, initialize, and use the I/O APIC so that you can now use 24 IRQ lines?

There are advantages; but there's also disadvantages - mostly, that you can't easily figure out which PCI device uses which IO APIC input without using a (disgustingly overcomplicated) APCI AML interpreter. Fortunately, MSI avoids this (so if you're very lucky and every device supports MSI, then...).


Cheers,

Brendan

Brendan wrote:Advantages of local APIC (instead of "nothing") for single-CPU:

• Provides the single best (for precision and overhead) timer that will ever exist

One thing that always bothers me is that you don't know the tick rate in advance, but have to measure it somehow using a different timer first (and so the result depends on the precision of that other timer). How would this assessment of the "best timer" compare with an HPET with known tick rate?

Hi,

XenOS wrote:

Brendan wrote:Advantages of local APIC (instead of "nothing") for single-CPU:

• Provides the single best (for precision and overhead) timer that will ever exist

One thing that always bothers me is that you don't know the tick rate in advance, but have to measure it somehow using a different timer first (and so the result depends on the precision of that other timer). How would this assessment of the "best timer" compare with an HPET with known tick rate?

I'm sometimes careful with the words I use (e.g. "best (for precision and overhead)"). For me, when talking about timers:

• Precision = smallest amount of time it can measure
• Accuracy = how accurately it measures time

For example; HPET with a 10 MHz clock has 100 ns precision, but local APIC in TSC deadline mode typically has "better than 1 nanosecond" precision (over 100 times more precise than HPET).

For accuracy (especially for long term accuracy), you mostly want a tiered system - e.g. use NTP (or GPS?) to keep HPET and/or RTC synchronised (to prevent them from drifting), then use HPET and/or RTC to keep TSC and/or local APIC timer synchronised.


Cheers,

Brendan

The APIC timer also has the problem on multicore OSes that it might either be per core or shared in mysterious ways. That means on some hardware you need to synchronize it between cores to be able to use it for anything useful. So, I'd say the HPET is quite superior for time-keeping if it exists that is.

Brendan wrote:For example; HPET with a 10 MHz clock has 100 ns precision, but local APIC in TSC deadline mode typically has "better than 1 nanosecond" precision (over 100 times more precise than HPET).

For accuracy (especially for long term accuracy), you mostly want a tiered system - e.g. use NTP (or GPS?) to keep HPET and/or RTC synchronised (to prevent them from drifting), then use HPET and/or RTC to keep TSC and/or local APIC timer synchronised.

Thanks for elaborating. Indeed, in this regard I agree.

From my understanding local-APIC sits on the CPU die and interface with each physiscal CPU. IO Apic generally faces the devices being served.
IO APIC and local APIC are connected by APIC bus and interrupts travels through this bus (obviously) as well as IPI (inter processor interrupts) are exchanged between these.

I think good place to get good understanding is look through ACPI specification's APIC tables. It tells how many IOAPIC has and how many interrupt it has. There is also unique global interrupt information to which all of the multiple IOAPIC's interrupts are uniquely mapped into. Also local APIC informatoin on each CPU as well as LAPIC ID.

Correct me anything wrong here.

Thanks for the comments everyone. I have been reading about the APIC, both local and I/O, and have done some tests to see what results are expected. The LAPIC's base can be retrieved from the MSR's as long as the MSR's are available, while the IOAPIC is not available in that manner. Looks like I need to do a little more work with my ACPI code, a little clean up and organization, then back to the APIC stuff.

Thanks,
Ben
http://www.fysnet.net/osdesign_book_series.htm

Hi,

BenLunt wrote:The LAPIC's base can be retrieved from the MSR's as long as the MSR's are available, while the IOAPIC is not available in that manner.

Don't do that. Just because Intel's manuals currently say that a specific MSR is "always" used for a specific purpose does not mean that other CPU manufacturers agree. The only correct way to obtain the local APIC's base is to get it from ACPI's "MADT/APIC" table or (if there's no ACPI) to get it from the "MultiProcessor Spec" tables.

Note that for IO APIC you need to look in those same tables anyway (so you don't avoid any extra work by making potentially false assumptions for local APIC's base).


Cheers,

Brendan

Brendan wrote:Hi,

BenLunt wrote:The LAPIC's base can be retrieved from the MSR's as long as the MSR's are available, while the IOAPIC is not available in that manner.

Don't do that. Just because Intel's manuals currently say that a specific MSR is "always" used for a specific purpose does not mean that other CPU manufacturers agree. The only correct way to obtain the local APIC's base is to get it from ACPI's "MADT/APIC" table or (if there's no ACPI) to get it from the "MultiProcessor Spec" tables.

Note that for IO APIC you need to look in those same tables anyway (so you don't avoid any extra work by making potentially false assumptions for local APIC's base).


Cheers,

Brendan

I wouldn't bother with the ancient MultiProcessor Spec. If a system doesn't have ACPI, you cannot use the APIC in any intelligent way anyway (find the IRQ mappings), it is likely old, so you are better off using the PIC instead. At least that's how I decide between PIC and APIC, and so a system must have a usable ACPI in order for my OS to use the APIC. Also, if it doesn't contain an APIC, I will run without ACPI as ACPI has no merit in a PIC configuration.

Brendan wrote:

BenLunt wrote:The LAPIC's base can be retrieved from the MSR's as long as the MSR's are available, while the IOAPIC is not available in that manner.

Don't do that. Just because Intel's manuals currently say that a specific MSR is "always" used for a specific purpose does not mean that other CPU manufacturers agree. The only correct way to obtain the local APIC's base is to get it from ACPI's "MADT/APIC" table or (if there's no ACPI) to get it from the "MultiProcessor Spec" tables.

Note that for IO APIC you need to look in those same tables anyway (so you don't avoid any extra work by making potentially false assumptions for local APIC's base).

Cheers,

Brendan

Agreed. That was a given. I was just making a comment. I have successfully re-written my ACPI code to allow a quick and easy way to retrieve both base values for the APIC or any other Mem-mapped I/O device that might be present.

Again, thanks for the comments,
Ben