i386: 0.940
architecture: 0.847
virtual: 0.732
boot: 0.722
x86: 0.709
register: 0.697
device: 0.683
performance: 0.677
graphic: 0.648
mistranslation: 0.598
ppc: 0.584
permissions: 0.562
semantic: 0.560
kernel: 0.557
socket: 0.455
files: 0.428
PID: 0.423
network: 0.422
peripherals: 0.417
vnc: 0.392
assembly: 0.343
debug: 0.284
user-level: 0.267
VMM: 0.239
hypervisor: 0.238
risc-v: 0.231
arm: 0.211
TCG: 0.192
KVM: 0.086
--------------------
i386: 0.998
x86: 0.997
assembly: 0.981
kernel: 0.844
boot: 0.827
debug: 0.449
architecture: 0.265
TCG: 0.259
files: 0.076
semantic: 0.031
register: 0.022
PID: 0.020
performance: 0.012
hypervisor: 0.010
user-level: 0.009
network: 0.007
virtual: 0.004
device: 0.003
VMM: 0.002
socket: 0.002
peripherals: 0.001
permissions: 0.001
mistranslation: 0.001
risc-v: 0.001
graphic: 0.001
vnc: 0.001
ppc: 0.001
KVM: 0.000
arm: 0.000

target-i386 cpu_get_phys_page_debug checks bits in wrong order

In target-i386 cpu_get_phys_page_debug, the CR4_PAE bit is checked before CR0_PG. This means that if paging is disabled but the PAE bit has been set in CR4, cpu_get_phys_page_debug will return the wrong result (it will try to translate the address as virtual rather than using it as a physical address).

Although this might seem like an unusual case, it in fact happens consistently when booting Linux on amd64 (from linux-2.6.32.60/arch/x86/boot/compressed/head_64.S):

    /* Enable PAE mode */
    xorl    %eax, %eax
    orl $(X86_CR4_PAE), %eax
    movl    %eax, %cr4
[... code to set up page tables omitted ...]
    /* Enter paged protected Mode, activating Long Mode */
    movl    $(X86_CR0_PG | X86_CR0_PE), %eax /* Enable Paging and Protected mode */
    movl    %eax, %cr0

The most noticeable effect of this bug is that using the disassembler during this time will fetch the wrong data by trying to read from page tables that aren't there. One symptom is that booting Linux amd64 with -d in_asm will result in several "Disassembler disagrees with translator over instruction decoding" messages.

Attached is a patch that moves the CR0_PG check to the beginning. I'm still not 100% certain that the logic of cpu_get_phys_page_debug matches cpu_x86_handle_mmu_fault, but it's a start.



Can you still reproduce this problem with the latest version of QEMU? If so, could you please send a refreshed patch to the qemu-devel mailing list? We do not pick up patches from the bug tracker. Thanks!

[Expired for QEMU because there has been no activity for 60 days.]