OSDev.org

Hi!

After I created a single-core kernel using a reprogrammed PIT,
I'm interested in how to move I/O handling to a higher level, applying I/O APIC.

My questions are:
* how to redirect all hw interrupts to a single core?
I've read articles about it. I'd like to see a correct example of the redirection table's setup.
* Should I replace again the IRQs replaced once using PIT?
* How to redirect IRQ 0 to all cores?
That's all for now, thanks for the help

move I/O handling to a higher level, applying I/O APIC.

Hello Pat, don't waste too much time with IOAPIC like me.

It is more recent than PIC but still 1996 vintage. For example VM devs consider their IOAPIC implementations "legacy code that's not used by modern OS, a security risk".

For timer you want lapic's timer

For Interrupt you want MSI

* how to redirect all hw interrupts to a single core?

physical mode, set the core's lapic number as target.

* Should I replace again the IRQs replaced once using PIT?

could you clarify? replace again replaced?

How to redirect IRQ 0 to all cores?

I don't know, it may not be possible to broadcast from IOAPIC in physical mode and I've never used logical mode.

xeyes wrote:For timer you want lapic's timer

I never understood the LAPIC timer. How is it calibrated? How do we make it fire once a millisecond? I stick to the IOAPIC and the HPET, as the HPET is more precise.

nexos wrote: How is it calibrated?

See nullplan's plan in this thread:
viewtopic.php?f=1&t=39818

nexos wrote:fire once a millisecond?

You have to look at your CPU and use the plan above to calibrate. For example, if it runs at 1Ghz, divider 64 + initial value 15625 would make it fire once a millisecond.

nexos wrote:HPET is more precise.

So we should probably reserve it for things that need such precision rather than using it for once a millisecond. But if it works for you it works

xeyes wrote: It is more recent than PIC but still 1996 vintage. For example VM devs consider their IOAPIC implementations "legacy code that's not used by modern OS, a security risk"

Interesting. So what you're saying is modern osses use MSIs exclusively and don't even touch IOAPIC to begin with? And iirc hpet supports msis too

IMO it makes sense to only use the HPET instead of setting up just to make the LAPIC timer work. HPET offers quite a few channels (maybe ), so we can have one for general timing every 1 millisecond, and then one for timing on a nanosecond basis.
I think were off topic now. Oops.

8infy wrote:

xeyes wrote: It is more recent than PIC but still 1996 vintage. For example VM devs consider their IOAPIC implementations "legacy code that's not used by modern OS, a security risk"

Interesting. So what you're saying is modern osses use MSIs exclusively and don't even touch IOAPIC to begin with? And iirc hpet supports msis too

Sorry I didn't put it clear enough. Not exactly never touch but more like seldomly use.

See http://events17.linuxfoundation.org/sit ... ning_0.pdf for more details.

Yes HPET can support MSI but IIRC aren't required to support it.

xeyes wrote:Not exactly never touch but more like seldomly use.

But they do still use it. My laptop (less than a year old!) still has a PS/2 keyboard and keyboard controller. It won't work without the IOAPIC.

Octocontrabass wrote:

xeyes wrote:Not exactly never touch but more like seldomly use.

But they do still use it. My laptop (less than a year old!) still has a PS/2 keyboard and keyboard controller. It won't work without the IOAPIC.

Exactly, and there are other devices too that doesn't support MSI or MSI-X. However, I agree that if there is an option to avoid the IOAPIC and use MSI or MSI-X instead, that's certainly better.

Octocontrabass wrote:

xeyes wrote:Not exactly never touch but more like seldomly use.

But they do still use it. My laptop (less than a year old!) still has a PS/2 keyboard and keyboard controller. It won't work without the IOAPIC.

Just sharing my findings on what KVM/Qemu guys' take on IOAPIC.

I'm of the opinion that anyone taking on an OS project is perfectly capable of deciding on whether to build dependency on components potentially on the way of being deprecated. And also capable of making things work regardless of the decision.

We are indeed a bit off topic now, maybe you could share some insights on the original questions? Like can IOAPIC broadcast in physical mode maybe using all 1s (0xfff...) as destination?

xeyes wrote:We are indeed a bit off topic now, maybe you could share some insights on the original questions? Like can IOAPIC broadcast in physical mode maybe using all 1s (0xfff...) as destination?

Probably not. None of the IOAPIC implementation datasheets mentioned the possibility, although some did say a physical destination of all 1s is reserved. (Unfortunately, it seems like there's no IOAPIC specification, just datasheets for different implementations.)

But why would you want to do that in the first place?

Octocontrabass wrote:

xeyes wrote:We are indeed a bit off topic now, maybe you could share some insights on the original questions? Like can IOAPIC broadcast in physical mode maybe using all 1s (0xfff...) as destination?

Probably not. None of the IOAPIC implementation datasheets mentioned the possibility, although some did say a physical destination of all 1s is reserved. (Unfortunately, it seems like there's no IOAPIC specification, just datasheets for different implementations.)

But why would you want to do that in the first place?

Same here didn't find any info. I guessed all 1s because that's how lapic broadcasts and the other fields of IOAPIC entries are same/similar to lapic's ICR fields.

You have to ask the OP for the reason but my guess is that PIT or HPET interrupts can be broadcasted to all cores to serve as a timer tick.

It probably works as long as the cores disable EOI broadcast and sync with each other to send EOI directly to IOAPIC correctly?

But like my post above, lapic timer seems like a better idea.

Thanks for the responses. It turned out that the emulator I tested on not fully support IOAPIC.
Cannot prove for sure, but probably this caused the problem.