OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 30, 2017 6:50 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: Using the APIC in a uniprocessor system
PostPosted: Mon Jan 02, 2017 1:38 am 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 166
Location: USA
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


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Mon Jan 02, 2017 1:50 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 2173
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


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Mon Jan 02, 2017 3:02 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7749
Location: At his keyboard!
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Mon Jan 02, 2017 4:04 am 
Offline
Member
Member
User avatar

Joined: Thu Aug 11, 2005 11:00 pm
Posts: 1019
Location: Tartu, Estonia
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?

_________________
Programmers' Hardware Database // SF user: xenos1984; OS project: XeNOS


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Mon Jan 02, 2017 4:41 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7749
Location: At his keyboard!
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Mon Jan 02, 2017 4:59 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 2173
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.


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Mon Jan 02, 2017 6:18 am 
Offline
Member
Member
User avatar

Joined: Thu Aug 11, 2005 11:00 pm
Posts: 1019
Location: Tartu, Estonia
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.

_________________
Programmers' Hardware Database // SF user: xenos1984; OS project: XeNOS


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Tue Jan 03, 2017 8:23 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 215
Location: San Jose San Francisco Bay Area
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.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Tue Jan 03, 2017 9:50 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 166
Location: USA
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


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Tue Jan 03, 2017 10:54 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7749
Location: At his keyboard!
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Wed Jan 04, 2017 2:41 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 2173
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.


Top
 Profile  
 
 Post subject: Re: Using the APIC in a uniprocessor system
PostPosted: Wed Jan 04, 2017 3:00 am 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 166
Location: USA
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group