[SOLVED] Paging issue in Bochs
Posted: Thu Oct 20, 2022 1:26 pm
Hello,
I have been working on my paging code for my bootloader, and it works in QEMU but not in Bochs. Here is the relevant code:
The page directory and table are 4K of memory reserved and zeroed, plus they are 4K aligned. The problem in Bochs is shown in the output of info tab below:
Obviously, 0x100000-0x1FFFFF should not be mapped to 0x0-0xFFFFF. What's weird is that the paging structures don't look corrupt. I used the xp command to look at the memory area containing the PTE for a page in that region, and here is what that looks like:
Looks valid to me. Is this a known Bochs bug?
In QEMU, all is fine. The output of info tlb shows everything mapped as it should be.
I have been working on my paging code for my bootloader, and it works in QEMU but not in Bochs. Here is the relevant code:
Code: Select all
# Set up paging structures
mov $pageDir, %esi # Get page directory address
add $NBLOAD_BASE, %esi
# Create PDE for mapping
mov $pageTab, %ebx # Get address of page table
add $NBLOAD_BASE, %ebx
or $3, %ebx # Set present and writable bits
mov %ebx, (%esi) # Put in page directory
# Fill page table
mov $pageTab, %edi # Get page table address
add $NBLOAD_BASE, %edi
mov $1024, %ecx # 1024 PTEs in a page table
mov $0, %edx # Start at address 0
.ptLoop:
mov %edx, %ebx # Get address in EBX
or $3, %ebx # Set present and writable bits
mov %ebx, (%edi) # Store in page table
add $0x1000, %edx # Move to next page
add $4, %edi # Move to next PTE
loop .ptLoop
mov %esi, %cr3 # Load page directory
mov %cr0, %eax # Get CR0
or $(1 << 31), %eax # Set PG bit
mov %eax, %cr0 # Enable paging
Code: Select all
0x0000000000000000-0x00000000000fffff -> 0x000000000000-0x0000000fffff
0x0000000000100000-0x00000000001fffff -> 0x000000000000-0x0000000fffff
0x0000000000200000-0x00000000002fffff -> 0x000000200000-0x0000002fffff
0x0000000000300000-0x00000000003fffff -> 0x000000200000-0x0000002fffff
Code: Select all
<bochs:4> xp /1wx 0x12400
[bochs]:
0x0000000000012400 <bogus+ 0>: 0x00100003
In QEMU, all is fine. The output of info tlb shows everything mapped as it should be.