AHCI driver

[Orycterope]

Introducing the driver for AHCI disks, for ATA and SATA devices.

Provides IPC endpoints to read and write some sectors.

For now it is a very modest single-threaded driver,
blocking on every request until the previous one is completed,
but this is prone to change as AHCI supports up to 32 simultaneous
outstanding commands.

closes #173
closes #165

[todo]

AHCI: Read CI and figure out which slot to use

For now AHCI driver is single-threaded and blocking, which means that the first slot is always available for use.
If we want to make a multi-threaded implementation, we will have to implement some logic to choose the slot.

---

https://github.com/roblabla42/KFS/blob/e6cca9bba94d175df5b4645fe89aec5fbf83a586/ahci/src/disk.rs#L71-L81

---

This comment was generated by todo based on a todo comment in e6cca9b in #206. cc @Orycterope.

[todo]

AHCI interrupts - command completion

The AHCI driver does not make any use of AHCI interruptions. To check that a command has been completed, it polls the port repeatedly until the PxCI bit cleared.
This is bad for performances, uses unnecessary time slices, and is an awful design.
We need to figure out how to make AHCI interrupts work for us.
The problem that we faced is the following:
When enabled, after a command has completed, the HBA sends an irq to the PIC. The irq kernel-side top-half `acknowledges the irq` (sends EOI to the 8259A), and delays the actual handling to the userspace-side bottom-half. It then rets to the interrupted context, and re-enables interrupts by doing so.
At this point the HBA, whose state has not been resolved, re-triggers an interrupt.
Hence the kernel is spending 100% cpu time servicing an infinite irq and the OS completely freezes.
This happens even while the 8359A is in `edge triggered mode`, which means that the PCI irq line is cycling through an HIGH and LOW, which is really odd according to the spec, where the irq are supposed to be "level sensitive".
I think a little more digging up would be necessary to find out if we just configured something incorrectly, or if AHCI interrupts truly cannot be handled in the bottom-half.
In the few open-source microkernels I reviewed that have an AHCI driver:

• Redox does not implement interrupts (well ... just like us), - HelenOS seems to allow userspace drivers to have their own top-half routine. I don't know if they run in ring 0 or ring 3, how the page-tables switching is handled, but I'm really curious and will try to find out more about it. - Minix3 seems to be actually using interrupts, through its blockdriver multithreading framework. I should look this up.

---

https://github.com/roblabla42/KFS/blob/e6cca9bba94d175df5b4645fe89aec5fbf83a586/ahci/src/hba.rs#L641-L651

---

This comment was generated by todo based on a todo comment in e6cca9b in #206. cc @Orycterope.

[todo]

IRQ capabilities at runtime

Currently IRQ capabilities are declared at compile-time.
However, for PCI, the IRQ line we want to subscribe to can only be determined at runtime by reading the `Interrupt Line` register that has been set-up during POST.
What would be the proper way to handle such a case ?

• Declaring every IRQ line in our capabilities, but only effectively using one ? - Deporting the PIC management to a userspace module, and allow it to accept dynamic irq capabilities in yet undefined way.

---

https://github.com/roblabla42/KFS/blob/e6cca9bba94d175df5b4645fe89aec5fbf83a586/ahci/src/main.rs#L185-L195

---

This comment was generated by todo based on a todo comment in e6cca9b in #206. cc @Orycterope.

[Orycterope]

Of course CI fails again ...

These reminders make me uncomfortable, not because computers are getting too smart, but because it reminds me how often I fall short of even baseline levels of conscientiousness.

[marysaka]

lgtm