xv6 - why PIC and APIC ? [update]

[JulienDarc]

Hello,

I am still reading the xv6 and noticed it does something interesting : setup PIC and APIC.

Everywhere it is said that it is one or another. In my case, it will be APIC.

xv6 initializes both. Why ?

Thanks

[Brendan]

Hi,

I am still reading the xv6 and noticed it does something interesting : setup PIC and APIC.

Everywhere it is said that it is one or another. In my case, it will be APIC.

xv6 initializes both. Why ?

You should either:

• only use the PIC to handle IRQs, or
• only use the IO APIC to handle IRQs

If you only use the PIC chips to handle IRQs, then you must:

• mask all IRQs in both PIC chips (to be enable when the appropriate device driver is initialised)
• install suitable interrupt handlers for each PIC chip's "spurious IRQ" (which is not a real IRQ and can not be disabled)
• remap the PIC chips so that none of their IRQs conflict with anything (e.g. exceptions)

If you only use the IO APIC to handle IRQs, then you must:

• mask all IRQs in both PIC chips
• install suitable interrupt handlers for each PIC chip's "spurious IRQ" (which is not a real IRQ and can not be disabled)
• remap the PIC chips so that the spurious IRQs don't conflict with anything (e.g. exceptions)

As you can see, the PIC chip initialisation ends up virtually identical in both cases.


Cheers,

Brendan

[mikegonta]

I am still reading the xv6 and noticed it does something
interesting : setup PIC and APIC.
Everywhere it is said that it is one or another. In my case, it will be APIC.
xv6 initializes both. Why ?

To also work correctly on uniprocessors, Xv6 programs the programmable
interrupt controler (PIC)

[JulienDarc]

Thanks it answers the question.

i will remap PIC interrupts (32+) and disable them as everyone does.

Thanks both of you,

Julien

[JulienDarc]

Still,

as I look the code,

1) if we are on a uniproc, that is fine, lapic/ioapic won't be enabled
2) on a smp system, pic won't be disabled. APIC code will not disable (mask again) PIC. So we end up with enabled PIC and enabled lapic/ioapic. Both. That is wrong.

It works but it is wrong.

[JulienDarc]

Nope it is good :

Masking all interrupts disables them in the PIC.

Those two lines :

// Disable logical interrupt lines.
lapicw( LINT0 , MASKED );
lapicw( LINT1 , MASKED );

Disable the two interrupts lines used by PIC.

All is well that ends well, as expected.
For future readers, if you know that you will ONLY use multi cores, you have a mean to clean the code.

[Combuster]

Disable the two interrupts lines used by PIC.

Eh, no. By default only one is the PIC (the slave routes through the master, not directly to the processor). More importantly, the other is the NMI which is historically used as the panic line, and should typically remain configured as such.

[JulienDarc]

So that line

Code: Select all

lapicw( LINT1 , MASKED );

could be a problem then, right ?

[Brendan]

Hi,

1) if we are on a uniproc, that is fine, lapic/ioapic won't be enabled

Local APIC is awesome (e.g. the timer alone surpasses everything that's existed before or since, for both precision and overhead). IO APICs are also awesome (e.g. more IRQs and less "PCI IRQ sharing", more flexible IRQ priorities, lower overhead due to being memory mapped, etc). This applies to single CPU systems.

Intel started including a local APIC in Pentium Pro, and all later CPUs include one. Originally it was disabled on desktop systems due to silly compatibility concerns (but left enabled on single CPU servers). In the same way single CPU servers included an IO APIC; and eventually (about 15 years ago if I remember correctly) Microsoft started requiring that the IO APIC and local APIC exist on all computers (including single CPU systems) as part of their "Windows Logo Program".

Basically; for single CPU systems both local APIC and IO APIC should be used if they exist; and for a lot of single CPU systems they do exist (especially if the OS already supports them, for SMP).

Those two lines :

// Disable logical interrupt lines.
lapicw( LINT0 , MASKED );
lapicw( LINT1 , MASKED );

Disable the two interrupts lines used by PIC.

That's a very bad hack (local APIC inputs should either be left "as is" or programmed according to what ACPI tells the OS to program them; and you should not diddle with them based on random/idiotic assumptions).

At this point I'd have to ask why you're looking at the XV6 source code. I'm not convinced that it should be trusted for educational use.


Cheers,

Brendan

[JulienDarc]

Hello,

I look at the xv6 because I thought that MIT could help me to learn properly but it seems that there are many hacks that confuse me more than anything else.

The major problem I face is that for modern operating system, the resources that are simple to understand (i.e not as convoluted as the Linux kernel) and more or less up to date are difficult to find. especially when 64 bit is involved.

Minix 1/3 are a whole another design.

Tatos, os just in assembly == lol (that's cool actually, I love assembly, but.. that is too much. And I don't know if you can write a whole operating system in assembly that could compete with, say, gcc and parts of assembly).

xv6 had the advantage of being explained, even if weird at times.

I have a lot of readings but it is too theoretical. I need to code.
I like to be able to see a simple system, analyze it and get my feet wet immediatly.

That is why I have been seduced by the xv6 concept

Do you know another system that is "correct" yet simple enough (please, not Linux) to analyze (preferably in c or c++ in second choice)?

[Brendan]

Hi,

Do you know another system that is "correct" yet simple enough (please, not Linux) to analyze (preferably in c or c++ in second choice)?

To be honest, I'm not even sure that "correct" and "simple" aren't mutually exclusive.

For an example, consider getting a key press from the keyboard. To do it correctly you need a USB driver. To do a USB driver correctly you need to handle IRQs. To determine IRQs correctly you need an AML interpreter. For just this one case, "correctly" adds up to several million lines of code. In comparison, an ugly/dodgy hack that relies on the (likely broken) firmware's "legacy PS/2 emulation" is many orders of magnitude simpler.


Cheers,

Brendan

[Rusky]

As long as you continue checking xv6's assumptions regarding hardware (which are often oversimplified or wrong) you can still get a lot out of it regarding the software side of things. It's (obviously) not the best design, but it demonstrates the big picture far better than any pile of specs.

An ideal example or tutorial would probably do a lot of things the simpler/less correct way but also make sure to include exactly why it's wrong and what directions you could take instead. At that point the pile of specs is much more useful.