-
-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(x86_64): real abstraction for ISA IRQs, unfuck I/O APIC (#490)
Basically, the current way you interact with ISA standard PC interrupts in the Mycelium x86_64 HAL is nonsensical, in several ways: 1. For some reason, we were mapping the I/O APIC ISA IRQs and the PIC ISA IRQs to separate regions in the IDT, even though you can only ever have either an I/O APIC *or* a PIC. Because of this, we were creating separate entries for each ISA interrupt's ISR in the PIC region and the I/O APIC region of the IDT. This doesn't actually break anything, but it's stupid and dumb and I don't know why I did that. 2. I made an attempt to have an interface for controlling ISA interrupts that abstracts over the I/O APIC and PIC interrupt models. But, currently, you can't actually *use* this thing to do anything you might want to do in an abstract way (mask/unmask/acknowledge an interrupt). Instead, you have to actually inspect which interrupt model you have. So, it's pointless. 3. Apparently the motherboard manufacturer gets to route ISA interrupts to I/O APIC pins in "whatever random order they want to". Currently, we hard-code the PS/2 keyboard and PIT timer interrupts to the vectors they *happen* to be on when I run `qemu-system-x86_64 -cpu qemu64` on *my* computer, but in real life, they could be anything. There's a thing in the ACPI tables that tells you how these are routed, but we're not using it. This is bad. 4. Also there's a bug where apparently when we unmask the PIT interrupt, it might fire spuriously, even if we haven't actually done an `sti`. I don't get this and it seems wrong, but it results in the IRQ being raised *before* configuring the static that tells you whether you have the APIC or PIC interrupt model so when you try to actually send an EOI, you dereference uninitialized memory and the kernel just hangs. This happens occasionally when running in QEMU with the default settings, and seems to happen consistently with `-machine accel=kvm`, so that suggests it is maybe worth worrying about. This branch, uh, fixes all of that stuff. I made the abstraction for ISA interrupts actually usable, and you can now mask/unmask/acknowledge them from ISRs or anywhere else by interrupt name, instead of having to know what interrupt model we have. Also, we now do the correct thing with regard to MADT interrupt source overrides (read: we actually know about them), and I fixed the spooky spurious interrupt behavior with the PIT by not unmasking it until after the interrupt controller static is initialized. Please clap.
- Loading branch information
Showing
5 changed files
with
411 additions
and
128 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.