OSDev.org

The code is from https://wiki.osdev.org/Setting_Up_Long_Mode is working

Then I tried to labeling the tables and it instant reboot the OS.

Original code:


My mod:

Your tables aren't page aligned. They must be.

Still doesn't work

Thanks the code is working now but you are aligning the code above the tables there.

Why aligning the code too.

I assembled a source with only


versus


And both do have the same bin size. but it's not when I add my code.

When you compile with just the table data it will be aligned to start with, so no padding is inserted. When you insert your code - unless it just happens to be an exact multiple of the page size - padding will be necessary to ensure that the data is aligned.

Running your code under a debugger would let you inspect memory and the problem would-be apparent immediately.

I see, so the above code is already encapsulated inside my ongoing paging table init, that's why I have to encapsulate it inside one single page.

Else the CPU does a reset since it cannot execute code or read data that share multiple pages.

Thank you

No.

IA-32/x86-64 have weak rules regarding aligment. Any code can cross (linear) page boundaries. Any (application) data can cross page boundaries. At most you will have performance penalties.

It's specifically paging data that was the problem in this example. Any given paging structure must appear entirely on a single physical page of memory. For practical purposes, this needs to be for one reason. CR3 and the paging structures (e.g. page table entries) only have bits available for the Top-20- (32-bit paging) or Top-40- (PAE and Long Mode) -bits of of the paging structures physical address. This means it is impossible for you to reference a page table, page directory etc. with any other alignment.

EDIT: I'd like to harp on about this a little more...

Really think about this code.



Imagine your tables are misaligned such that p3_table is 0x8003. Then the first line becomes,



Ignoring the (intentional) flags for a second. This means you are placing the value 0x0000000000008003 in the first P4 entry. Go to page 132 of https://software.intel.com/content/dam/develop/external/us/en/documents-tps/253668-sdm-vol-3a.pdf and look at the structures. The "Address of page-directory-pointer table " is being set to 0xXXX0000000008XXX (where X is outside the value "Address of page-directory-pointer table " and I put it there to make it it a 64-bit number).

The 0x3 is being places in the lower part of the structure, setting the present and read/write flags.

Worse yet, because you add, rather than or'ing, your flags, you then do the sum 0x8003 + 1 + 2 + 4, giving a value of 0x800A. In this value, you are clearing the Present, Supervisor bits, setting the writable bit, and accidentally setting the page write through caching flag. This lack of present flag is what probably caused the triple fault, as the processor could have never known you intended to use a mis-aligned page.

Incidentally, I'm not sure about,



According the my reading of the page I linked above, this sets the User/Supervisor flag, not a flag setting read permissions.

That would be extremely limiting, and is not the case.

I think you may benefit from reading the Intel or AMD Programmer's Manuals to ensure that you have a thorough understanding of the basic operation of the processor. Pay particular attention to the chapter on memory management.

Yep, long reading awaits me oof



Fixed, thanks

Am I missing something here? I feel like these should be ORed and not ADDed together.

Strictly speaking, yes, but it makes no difference in this case.