permissions: 0.126 device: 0.118 semantic: 0.109 other: 0.108 PID: 0.094 graphic: 0.081 performance: 0.078 vnc: 0.063 files: 0.051 debug: 0.047 socket: 0.043 network: 0.031 boot: 0.026 KVM: 0.024 debug: 0.279 semantic: 0.122 files: 0.118 other: 0.113 PID: 0.068 device: 0.050 graphic: 0.037 performance: 0.036 socket: 0.036 network: 0.033 KVM: 0.031 boot: 0.029 permissions: 0.028 vnc: 0.020 Addresses with 4GB differences are consider as one single address in QEMU THIS IS THE ISSUE OF USER MODE EMULATION Information about guest and host ********************************** guest: 64 bit x86 user mode binary host: 32 bit Linux OS uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP architecture: intel64 Bug Description **************** for memory reference instructions, suppose I have two addresses in guest address space(64 bit) 0x220000000 0x320000000 as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit) in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values. here is the program which i used to test: #include #include #include #define SIZE 4294967298 /* 4Gib*/ int main() { char *array; unsigned int i; array = malloc(sizeof(char) * SIZE); if(array == NULL) { fprintf(stderr, "Could not allocate that much memory"); return 1; } array[0] = 'a'; array[SIZE-2] = 'z'; printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]); return 0; } I have 8 gib RAM I compiled this program on 64 bit linux and run this on 32 bit linux with qemu QEMU command line and output ********************************** $x86_64-linux-user/qemu-x86_64 ~/ar_x86 output: array[SIZE-1] = z,array[0] = z Release information ******************** x86_64 binary is tested with latest release : qemu-0.14.1 and with current development tree as well( live code of QEMU using git) Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? [Expired for QEMU because there has been no activity for 60 days.]