This might not be a big problem, but it's just something I've encountered while debugging the kernel.

Between the elfloader jumping to the kernel and mapping the kernel window, printing is effectively disabled as the kernel UART drivers use a UART_PPTR virtual address. This means that when an assert fails the user may experience kernel "hanging" without any definite reason/clues as to why.

The workaround for this is to change the UART VA to the PA value instead, as the elfloader identity mapping will still be active at this point (mapping the kernel window).

Just wondering if a debug early-UART implementation that makes use of the elfloader 1:1 mapping makes sense.

Side note: similarly, there is a small gap between activate_kernel_vspace() and setVtable(). In this gap, the elfloader vtable will no longer be useable, and we may miss exceptions.