OSDev.org

Posted: **Fri Apr 10, 2020 6:30 pm**

Hi everyone,

Today I stumbled upon an issue I cannot resolve at the moment.

It is located in the boot code for my AP, when I try to load some data in high addresses.
My code is the following:

Code: Select all

... /* Code before jumpt to 64 bits */
   ; Set CR3
    mov eax, [OFFSET_ADDR(_ap_boot_pgdir)]
    mov cr3, eax

    ; Enable PAE
    mov eax, cr4 
    or  eax, 0x20
    mov cr4, eax 

    ; Switch to compatibility mode 
    mov ecx, 0xC0000080
    rdmsr
    or  eax, 0x00000100
    wrmsr

    ; Enable paging 
    mov eax, cr0
    or  eax, 0x80010000
    mov cr0, eax 

    ; Far jump to 64 bit mode
    jmp CODE64:OFFSET_ADDR(__ap_loader_lm)

[bits 64]
__ap_loader_lm:
    cli 

    ; Init data segments
    mov ax, DATA64
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax

    ; Get stack index
    mov rax, init_cpu_count
    mov rbx, [rax]
    inc rbx
.... /* Rest of the code

Everything goes well until I reach the

Code: Select all

; Get stack index
    mov rax, init_cpu_count
    mov rbx, [rax]

When executing the mov to rbx from the address contained in rax, I get a fault and since I didn't set any IDT, triple fault.

I tried to set the IDT but I got a triple fault on the lidt instruction too.

The address in RAX is mapped before the instruction is executed, the AP is in ring 0.

Do you have any idea about what could happen?
Thanks!

Posted: **Sat Apr 11, 2020 12:30 am**

Oxmose wrote:The address in RAX is mapped before the instruction is executed,

How did you verify this?

Posted: **Sat Apr 11, 2020 7:29 am**

Octocontrabass wrote:
Oxmose wrote:The address in RAX is mapped before the instruction is executed,
How did you verify this?

Debug intil the offending instruction. Just before steping on the instruction I check the content of RAX, the page directory, the content of cr3, use the Qemu monitor with the "info tlb" and "info mem" commands. All these checks leds me to think that the content of RAX is mapped.

Posted: **Sat Apr 11, 2020 8:08 am**

Since you appear to have a GitHub account, could you put your entire OS project in there with the latest version (that fails) and describe what you need to do to reproduce the problem so that we can take a look?

Posted: **Sat Apr 11, 2020 8:21 am**

Oxmose wrote:Qemu

Add "-d int" to your command line and QEMU will log the CPU state when the exception occurs. (It actually logs every interrupt, not just exceptions, so there will be a lot of information in the log.) You might also want to use "-no-reboot" if you aren't already.

Posted: **Sat Apr 11, 2020 8:29 am**

Oxmose wrote:All these checks leds me to think that the content of RAX is mapped.

You have to be wrong. How can the instruction fail other than through a Page Fault (assuming you are using a flat memory model)?

Did you actually check the contents of the address in rax in the qemu monitor by using the "x" command?

The fact that you can't use lidt is the first error to investigate.

Posted: **Sat Apr 11, 2020 10:20 am**

Hi everyone and thanks for your help and hints.

After a night of rest the solution appeared to be really dumb.

I am starting my AP core using the already created paging structures currently in use by my main core. However all pages that are not related to code have the NXE bit set.
I realized I forgot to enable the NXE feature in EFER for the AP. So everything was mapped, all the debug tools seemed to have access to the data. But since the NXE bit was not enabled
the CPU crashed.

By enabling the NXE feture everything is back to normal.

OSDev.org

[SOLVED] Triple fault on data loading

[SOLVED] Triple fault on data loading

Re: Triple fault on data loading

Re: Triple fault on data loading

Re: Triple fault on data loading

Re: Triple fault on data loading

Re: Triple fault on data loading

Re: Triple fault on data loading