OSDev.org

FlashBurn wrote:The first thing is, if I want to use lowest priority mode for sending the interrupts, what have I to write into the destination field of the int in the io-apic?

FlashBurn wrote:And how have I to init the local apics to get the ints on the cpu which has the lowest priority? I mean if I only want to change the value in the task priority register and what do I have to write into the arbitration and processor priority register?

• use suitable priorities for all interrupts (where an interrupt's priority is determined by which interrupt vector it uses)
• set the Task Priority Register (in each CPU) according to how important the code running on the CPU is

FlashBurn wrote:Thanks, you also answered questions I forgot to ask But 1 question is still unanswered. Whai have I to write into the destination field of the int in the io-apic? Or is it equal if I use lowest priority?

• Destination Field = the logical destination (bits that are set or clear depend on what you want and how the local APIC's DFR and LDR are setup)
• Interrupt Mask = must be clear to enable the interrupt
• Trigger Mode = level or edge triggered, depends on what the MP specification tables or ACPI tables say for the interrupt
• Interrupt Input Pin Polarity = active high or active low, depends on what the MP specification tables or ACPI tables say for the interrupt
• Destination Mode = logical destination mode (physical destination mode can't be used for "send to lowest priority CPU")
• Delivery Mode = 001b ("Lowest Priority")
• Interrupt Vector = which IDT entry the IRQ uses, also determines IRQ priority (e.g. "priority = vector & 0xF0")

FlashBurn wrote:The only thing is that in I don´t know from where to get the PCI routing (which PCI int goes to which pin of the I/O-Apic or PIC).

FlashBurn wrote:What happens if all cpus have the same priority?

FlashBurn wrote:So I hope I finished this code. Because I also have only 32 priorities (0 - 0x1f) I also set the TPR to the value of the priority of the actual thread and if a cpu is idle I set the TPR to 32, so that all interrupts go to the lowest priority cpu, but one that is not idle. Also if all cpus are idle the interrupt will be delivered, because my irqs start at 0xD0.

Owen wrote:MSI capable devices send interrupts directly to the local APIC (By performing a bus master write).

The four interrupt lines are for LSI (Level Signalled Interrupt) devices, which don't support MSI.

FlashBurn wrote:This whole IO-APIC thing is a mess

I will only support 1 IO-APIC, because more than 1 cause only trouble.

FlashBurn wrote:So if I rely on the MPS, I get even more problems if my code runs on a pc with PCI Express, because there every slot is a unique bus and my code only recognizes 1 PCI bus.

FlashBurn wrote:So the PCI bus has 4 ints, A till D, and an actual IO-APIC has 24 input pins. So does this mean that 4 input pins are only for MSI capable PCI devices?

FlashBurn wrote:How are you initing the IO-APIC and when? (because I´m doing it in my loader) And how do you solve the problem of a variable number of interrupt handlers? I have hardcoded 24 interrupt handlers for the IO-APIC in my kernel, but how could I make this variable?

FlashBurn wrote:For now I will create my own data structure where stands which ISA irq goes to which global interrupt and which PCI device goes into which global interrupt.

FlashBurn wrote:So maybe I have to change how my loader and kernel works, but I hope that I get a better idea how to solve problems with the init of the IO-APIC.

How are you initing the IO-APIC and when? (because I´m doing it in my loader) And how do you solve the problem of a variable number of interrupt handlers? I have hardcoded 24 interrupt handlers for the IO-APIC in my kernel, but how could I make this variable?

For now I will create my own data structure where stands which ISA irq goes to which global interrupt and which PCI device goes into which global interrupt.

Owen wrote:Hardcode 256 interrupt handlers. Yes, it's wasteful, but your root interrupt handlers should be small anyway.

Brendan wrote:Sounds like a good idea, just don't forget that the same IRQ can be shared by multiple devices (a simple "device_ID = interruptTable[IO_APIC_input_number]" array won't work) and the same device can have multiple interrupts (a simple "IO_APIC_input_number = interruptTable[device_ID]" array won't work either).

struct ioapicPCIbus_t {
 uint8t busID;
 uint8t ioapicID;
 uint8t inputPin[4];
};