#917 PAE support doesn't work

CPU model (187)


I'm developing my own OS and had trouble with the PAE
support in Bochs. If Bochs is compiled with
"--enable-PAE", then CPUID will report that PAE is
supported, but when the guest OS enables PAE the paging
system behaves exactly like it isn't enabled, causing
page fault exceptions until it triple faults.

Using the debugger and stepping through the code it's
possible to enable PAE and then paging, but stop before
executing the first instruction after paging is enabled
(and immediately before the page fault). This allows
you to use the debugger's memory manipulation commands
(setpmem, x and xp) to test how Bochs is emulating the
paging system.

This bug effects both Bochs 2.1.1 and the new Bochs 2.2
Beta. I've tried Bochs 2.1.1 on both Windows 98 (cygwin
on Pentium IV) and Gentoo Linux (GCC on Dual Pentium
III) with the same results. The new Bochs 2.2 Beta I've
only tried on Gentoo Linux (GCC on Dual Pentium III).
My OS's code works fine on real computers when PAE is
used, and also works fine on Bochs when PAE isn't used.

I'm not sure if Bochs has ever actually supported PAE
(in which case the existance of the "--enable-pae"
compile time option is a bug), or if Bochs should
support PAE properly.

My email address is "btrotter[AT]gmail.com"..




  • Stanislav Shwartsman

    Logged In: YES

    Bochs has only 32-bit physical address.
    If it is not a reason for the problems (i.e. even with PAE
    enabled you don't try to use physical addresses out of
    emulated address space), please post some instructions to
    reproduce. I mean disk image whgich tripple fults on Bochs
    and passes on real hardware or application which could be
    run under Windows guest and also reproduce problem.


  • Nobody/Anonymous

    Logged In: NO


    I found the bug! :-)

    First I was wrong about the symptoms. Bochs was supporting
    PAE but was using "CR3 & 0xFFFFF000" rather than "CR3 &
    0xFFFFFFE0" for the physical address of the PDPT.

    If the software sets the PAE enable bit in CR4, then sets
    CR3 and then enables paging, bochs will do "BX_CPU_THIS_PTR
    cr3_masked = value & 0xffffffe0;", which is correct.

    If the software sets CR3, then sets the PAE enable bit in
    CR4, and then enables paging, then Bochs will do
    "BX_CPU_THIS_PTR cr3_masked = value & 0xfffff000;" when CR3
    is set (as PAE isn't enabled at this time), and it won't
    update "cr3_masked" when PAE is enabled in CR4 later. This
    is what causes the problem.

    To fix this bug Bochs will need to update "cr3_masked" any
    time the state of the PAE enabled bit in CR4 is changed.

    In the file "paging.cc" replace the existing
    "pagingCR4Changed()" function with the following code:

    void BX_CPP_AttrRegparmN(2)
    BX_CPU_C::pagingCR4Changed(Bit32u oldCR4, Bit32u newCR4)
    // Modification of PGE,PAE,PSE flushes TLB cache according
    to docs.
    if ( (oldCR4 & 0x000000b0) != (newCR4 & 0x000000b0) )
    TLB_flush(1); // 1 = Flush Global entries also.

    if (bx_dbg.paging)
    BX_INFO(("pagingCR4Changed(0x%x -> 0x%x):", oldCR4,

    if ( (oldCR4 & 0x00000020) != (newCR4 & 0x00000020) ) {

    if BX_SupportPAE

    if (BX_CPU_THIS_PTR cr4.get_PAE())
    BX_CPU_THIS_PTR cr3_masked = BX_CPU_THIS_PTR cr3 &


    BX_CPU_THIS_PTR cr3_masked = BX_CPU_THIS_PTR cr3 &


    After doing this to Bochs 2.2 Beta and recompiling, my OS
    (and PAE) worked perfectly :-).



  • Stanislav Shwartsman

    Logged In: YES

    Thank you for the fix !
    I will merge to it CVS ASAP.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks