Isaac Woods

[`b9dbbaf`](https://github.com/IsaacWoods/pebble/commit/b9dbbaf6a8166e1574d13414d9ad42ed9ed22b74) seems to have changed the issue from a `#PF` from trying to `sysretq` to `0x0` into a `#GP` at the following `ret` instruction, even on the version of QEMU...

I've built some basic stacktracing abilities to help debug this issue, which has created some interesting output: ``` [INFO][kernel_x86_64::interrupts::exception] BREAKPOINT: InterruptStackFrame { r15: 0x0, r14: 0x0, r13: 0x0, r12: 0x0,...

~~This bug appears to have been fixed for good this time by fixing some edge-cases in our arbitrary mapping algorithm. I'm still not totally sure how it was causing this...

Just braindumping for now because I picked this up while trying to solve another issue, but after updating to `rustc 1.48.0-nightly (d006f5734 2020-08-28)`, we seem to be getting much further...

What with med school, I unfortunately don't really have the mental bandwidth to sit down and work out what I'm sure is just some dumb bug somewhere in the paging...

Re-enabled all the stuff we'd turned off to try and isolate the issue today and it uh, got worse. However, it's more obvious what has actually happened here: the entire...

So I've fixed the problem where we needed to keep the UEFI boot services memory mapped in the kernel page tables, which does **not** fix this problem, but gets rid...

Note: for KVM to publish the `0x4000_0010` leaf, we need to add the `vmware-cpuid-freq` and `invtsc` cpu features

Turns out this isn't as easy as I thought it'd be. It doesn't look like UEFI `MPServices` has any capability for booting an AP without it wanting you to return...

Since this is aimed at Long Mode only, I would argue we should make use of more of the virtual address space. Why not map the kernel at 0xffffffff80000000 (-2GiB),...