OSDev.org

Techflash wrote:Log of this is at: https://gist.github.com/techflashYT/3c5 ... 7f08cfffe7

Techflash wrote:Perhaps I should fill out the entire rest of the IDT with stub entries instead of just zeroes?

nullplan wrote:you have 2 bytes for the push and at most 5 for the jump, makes 7 in total, aligned to 8

nullpan wrote:This defines a new symbol, "external interrupt", that handles interrupt 32. You need to define your own function "interrupt_common". It is entered with an IRET frame and the interrupt number less 128 on the stack.

nullplan wrote:

Techflash wrote:Perhaps I should fill out the entire rest of the IDT with stub entries instead of just zeroes?

That is generally a good idea. Between IOAPIC, local APIC, and MSI, you can generally not know how many interrupts you will have ahead of time these days. Filling the entire IDT can be done as simply as:

Code: Select all

.align 8
.global external_interrupt
external_interrupt:
.set interrupt,32
.rept 256-32
  pushq interrupt-128
  jmpq interrupt_common
.align 8
.set interrupt, interrupt+1
.endr

This defines a new symbol, "external interrupt", that handles interrupt 32. You need to define your own function "interrupt_common". It is entered with an IRET frame and the interrupt number less 128 on the stack. The encoding is chosen such that for all possible values of "interrupt", the encoding of the push instruction is the short encoding. This means that all interrupt handlers are exactly 8 bytes apart from one another (you have 2 bytes for the push and at most 5 for the jump, makes 7 in total, aligned to . So now you can define in C:

Code: Select all

extern const char external_interrupt[];
for (int i = 0; i < 256-32; i++)
  set_idt_entry(i + 32, external_interrupt + 8 * i);

Your "interrupt_common" function will then need to save all registers, probably fix up the interrupt number on stack, then call whatever interrupt handler you need to. Then restore registers and do whatever work is required when returning from interrupt.

• Instead of using push + jmp, you can use call and calculate the index from the offset ($rip - external_interrupt) (example). Each call instruction is always exactly 5 bytes.
• You can avoid the setup loop at runtime by putting the table at a known location and calculating the offset from a constant. Personally, I put it at the start address of the kernel. (example link.ld, example compile time loop)

Octocontrabass wrote:As I mentioned in my previous post, that suggests a problem with your GDT. Use "info gdt" to check it.

Global Descriptor Table (base=0xffffffffffe07120, limit=39):
GDT[0x0000]=??? descriptor hi=0x00000000, lo=0x00000000
GDT[0x0008]=Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Non-Conforming, 32-bit
GDT[0x0010]=Data segment, base=0x00000000, limit=0xffffffff, Read/Write, Accessed
GDT[0x0018]=Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Non-Conforming, 32-bit
GDT[0x0020]=Data segment, base=0x00000000, limit=0xffffffff, Read/Write
You can list individual entries with 'info gdt [NUM]' or groups with 'info gdt [NUM] [NUM]'

Octocontrabass wrote:Looks mostly correct to me. The only problem with your GDT is that your code segments are 32-bit instead of 64-bit.

This also means that your code to reload the segment registers is not reloading CS, since the CPU doesn't switch to 32-bit mode!

Techflash wrote:I can't seem to figure out why it's 32-bit.

Octocontrabass wrote:

Techflash wrote:I can't seem to figure out why it's 32-bit.

You've set the granularity byte to 0xCF. A 64-bit code segment would use the value 0xAF here.

You should also take a closer look at this instruction since it isn't loading CS.

Techflash wrote:Out of nowhere after the IDT init it randomly jumps to 0x000..023? (an illegal instruction)

Techflash wrote:Also what do you mean that the instruction isn't loading CS?

Octocontrabass wrote:

Techflash wrote:Out of nowhere after the IDT init it randomly jumps to 0x000..023? (an illegal instruction)

You're receiving an IRQ, and your IDT says that's where the handler is. No idea which IRQ though, you still haven't initialized the interrupt controllers.

Techflash wrote:Also what do you mean that the instruction isn't loading CS?

It's not a far JMP, so CS doesn't change - it still contains the old descriptor from the bootloader's GDT. It's easier to see that it's not a far JMP after translating it to Intel syntax. There's no way to encode a far JMP with a 64-bit destination in long mode, so you'll have to use something else (far RET is the usual choice).

Octocontrabass wrote:That's because you're still filling your IDT with something that isn't the addresses of your handlers.

07416545692e[CPU0  ] iret64: return CS selector null
07416545750e[CPU0  ] RET_Op64: canonical RIP violation
07416545772e[CPU0  ] access_read_linear(): canonical failure
...
*the following repeat A LOT*
07421046755p[APIC0 ] >>PANIC<< APIC read at address 0x0000fee000b0 spans 32-bit boundary !
...
07421046763p[APIC0 ] >>PANIC<< APIC write with len=8 (should be 4)
...
07421046787p[APIC0 ] >>PANIC<< APIC read at address 0x0000fee00030 spans 32-bit boundary !
*end of huge repeat*
07421292285e[HPET  ] read: timer id out of range
07421292285e[HPET  ] write: timer id out of range
...