Page fault on page that is present?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
isaacwoods
Member
Member
Posts: 47
Joined: Sun Sep 06, 2015 5:40 am

Page fault on page that is present?

Post by isaacwoods »

Hi,

I have been trying to move my Rust kernel from identity mapping to instead map the kernel at 0xffffffff80000000. There have been a bunch of problems with this, all of which I've fixed except a weird page fault when trying to create the IDT. I'm using spin::Once to create the IDT which is just a `[IdtEntry; 256]` primitive like so:

Code: Select all

static IDT : Once<Idt> = Once::new();

pub fn init()
{
...
IDT.call_once(
    || {
        let mut idt = Idt::new();
        idt
    });
...
}
On returning the IDT from the closure (`spin` then puts the return value into the static variable), a page fault occurs:

Code: Select all

check_exception old: 0xffffffff new 0xe             
     0: v=0e e=0002 i=0 cpl=0 IP=0008:ffffffff801119fe pc=ffffffff801119fe SP=0010:ffffffff80120db0 CR2=ffffffff80120dd0
From the error code and CR2, I established that the page containing 0xffffffff80120dd0 isn't present. This seemed simple - there was a bug in the code that allocates the ELF sections (this address is within the .bss section) - but the page IS present as far as I can tell.

I suspect I'm just being dim, but I don't know where to proceed from here?
User avatar
iansjack
Member
Member
Posts: 4706
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Page fault on page that is present?

Post by iansjack »

Perhaps I'm being silly, but your qemu screenshot shows all your page mappings at non-canonical addresses. That doesn't seem right.
isaacwoods
Member
Member
Posts: 47
Joined: Sun Sep 06, 2015 5:40 am

Re: Page fault on page that is present?

Post by isaacwoods »

Perhaps I'm being silly, but your qemu screenshot shows all your page mappings at non-canonical addresses. That doesn't seem right.
Yeah, I'm not sure what's up with that. The four leading 0s in each address should be Fs (the kernel is mapped at 0xffffffff80000000 + physical address), and other stuff works at these correct addresses, so I assume it's something wrong with the qemu monitor. Is it worth looking into?
Post Reply