a1c965da1e
Sixty-five headers sat side by side in include/, so `#include "irq.h"` said nothing about where irq.h was or what it belonged to, and errno.h, stat.h and fcntl.h at the top shadowed the system's for any host tool built with -I./include. They are in folders now -- arch/ core/ fs/ dev/ gfx/ net/ uapi/ (and ldls/ for the Linux driver layer) -- and every include names the folder, as Linux's do: "core/proc.h". Done mechanically and checked the hard way: the kernel built from this tree disassembles identically to the one built from the tree before it. The full image boots, and userland is the same set of programs. Paths in docs and comments follow; docs/guides/layout.md has a table of what is where, and tools/fix-includes.py rewrites old-style includes from the folders in the tree, for code written before this. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
2 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schunix-ioremap-and-bars | ioremap() maps device registers; never use P2V on a BAR, because firmware may place a 64-bit BAR far above the 4 GB direct map |
|
Never reach a device's registers with P2V(bar.base). Use
ioremap(pa, size) from kernel/arch/x86_64/vm.c (declared in include/core/defs.h).
Every driver used to do the P2V thing, which silently assumes the BAR lands
inside the 0-4 GB that kvmalloc() direct-maps with four 1 GB pages. Under
SeaBIOS it always does. Under OVMF it does not — virtio-gpu's 64-bit BAR came
back at about 768 GB, P2V produced an address with no translation behind
it, and the first register write page faulted, then double faulted, then triple
faulted into a reboot loop. Coming out of a driver bind, that reads as broken
hardware rather than a missing mapping.
How it works
PDPT entries 4-511 were unused: the direct map occupies 0-3, and kpml4[0],
kpml4[KERNBASE] and every process's PML4 (see setupkvm) all point at that
same table. So each MMIO region takes one 1 GB page there — no page table to
allocate, and the mapping appears in every address space at once. Entries are
PTE_PCD | PTE_PWT for the same reason the top GB of the direct map is: these
are registers, and a write sitting in a cache line is a write the device never
sees.
A physical address below 4 GB is returned unchanged, as P2V would have.
That is what makes the BIOS path — where every BAR is low — provably identical
rather than merely tested.
Where this bites next
Converted: virtio-gpu, e1000, xhci. xHCI had already been refusing to bind above 4 GB with a comment saying the mapping did not exist yet.
Any new driver that reads a BAR needs the same treatment. grep -rn 'P2V(d->bar' kernel/ should stay empty.
See schos-uefi-loader for the boot path this unblocked.