AHCI: Page fault when enumerating HBA memory space

[kennystrawnmusic]

Can anyone explain why this would cause a page fault by overflowing the stack?

Was able to narrow the source down to precisely that stage in the AHCI initialization process by attempting to print test lines onto the screen and seeing which point those test lines would no longer print due to the page fault panic. The point at which the test lines no longer print is at the very top of the "filter_map" closure.

The only possibility I can think of is the use of heap-allocated structures (Vec<Box<dyn Disk + Send + Sync>>) to point to stack-allocated entries in HBA memory, but that makes no sense given that Redox manages to succeed at exactly that.

[kennystrawnmusic]

To further elaborate: it appears to be some sort of overflow. Attempts to access out-of-bounds memory addresses and when I go on to allocate a page at each offending address, it attempts to access even more out-of-bounds memory each and every time. Which is strange seeing as though creating a vector of disks shouldn't cause a stack overflow, and neither should what is essentially a clone of the Redox AHCI driver with kernel-mode-compatibility tweaking.

[kennystrawnmusic]

I'd also build a mechanism to reliably detect kernel stack overflow in your page-fault handler (generally with guard pages), and report it better so it doesn't seem like 'random' page-faults.

Does the bootloader provide an API for reliably detecting where to place a guard page in memory?

[kennystrawnmusic]

For further information, the address that the driver is trying to access only to trigger a page fault is 0xfffffff720. Whenever I try to map a page there, I get the same page fault at another higher address, and no matter how many pages I map, the same problem persists. Something is infinitely recursing in the code of that driver and I'm still trying to figure out where.

[kennystrawnmusic]

Here's the output thus far. You'll notice that every time I try to allocate a page at the address it faults at, it keeps faulting at a lower and lower address:

And when I attempt to put a huge page there:

So something is clearly recursing. Still struggling after months of this to figure out exactly what.

[kennystrawnmusic]

Managed to at least get it to detect a disk by moving the start of the kernel stack to the extreme high-end. Page fault still persists however; it just happens after detection of the first disk instead of before.

[kennystrawnmusic]

After a lengthy struggle attempting to find a GPLv3 replacement, finally managed to in Aero's AHCI implementation, so decided to port that instead of attempting to reinvent the wheel by rewriting the AHCI driver that comes with Redox. Page fault is now gone, but I've run into a new problem:

The IDT is only supposed to be 256 entries long, no? So why would a #NP fault expecting a 302nd entry in the IDT even be possible? Or is there something else going on here?

[kennystrawnmusic]

Nearly a whole month and an attempted complete rewrite of the AHCI driver later (by porting Aero's implementation instead of trying to rewrite Redox's since Aero is GPLv3 and so is my own kernel, so no licensing issues) I finally have a promising lead: Turns out QEMU is placing the ABAR in legacy I/O port space instead of MMIO space. The hilarious thing about this is I had to comment out the assertion check of the header type because for some reason it isn't seeing a zero (normal) there despite the fact that the pcics crate is correctly seeing it as a normal header.

Is there any way to prevent this and/or force-enable MMIO disk access from the QEMU side of things?

[kennystrawnmusic]

Finally figured out the problem after taking to StackOverflow for help: the problem is rust-osdev/x86_64#396. SelectorErrorCode::index() is performing a misaligned read of the bits in the selector code given by the fault.