Hi. The v8 ARM ARM defines these bits of the FPSCR as "RES0". The glossary definition of "RES0" says that for bits in a RW register it is an implementation choice whether the bits should be "hardwired to 0" (ie writes are ignored) or whether the bit can be written and read back (but has no effect on behaviour). QEMU has gone for the "can be written and read back" option.
(Previous versions of the architecture like v7 required implementations to provide the "hardwired to 0" behaviour. In any case correctly behaving guest code should never write 1s to these bits.) This is a specific example of a general situation: QEMU doesn't really pay very much attention to the edge cases of behaviour in IMPDEF or UNPREDICTABLE cases, especially where they vary between architecture versions, and we don't try to enforce "unimplemented always RAZ/RAO" bits in registers. So while it might be nice to have these bits RAZ0 it's really very low priority for us -- I'd happily review and accept a patch to do this, but am unlikely to write one myself. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1641861 Title: fail to correctly emulate FPSCR register on arm Status in QEMU: New Bug description: Hi all, we systematically tested the QEMU implementation for emulating arm user mode programs. We found that QEMU incorrectly emulate the FPSCR register. The following the proof of code: /*********** Beginning of the bug: arm.c **********/ int printf(const char *format, ...); unsigned char i0[0x10]; unsigned char o[0x10]; int main() { int k = 0; asm("mov r2, %0\n" "ldr r0, [r2]\n"::"r"((char *)(i0)));; asm("vmsr fpscr, r0"); asm("mov r2, %0\n" "vmrs r4, fpscr\n" "str r4, [r2]\n"::"r"((char *)(o)));; for (k = 0; k < 0x10; k++) printf("%02x", o[0x10 - 1 - k]); printf("\n"); } unsigned char i0[0x10] = {0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x28, 0x1c, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x00}; /*********** End fo the bug **********/ When the program is compiled into arm binary code and running on a real arm machine, and running in qemu, we have the following result $ arm-linux-gnueabihf-gcc arm.c -o arm -static $ ./arm 000000000000000000000000fff7009f $ qemu-arm arm 000000000000000000000000ffffffff According to the ARM manual, bits[19, 14:13, 6:5] of FPSCR should be reserved as zero. However, arm qemu fails to keep these bits to be zero: these bits can be actually modified in QEMU. QEMU version is 2.7.0. The operating system is Linux 3.13.0. x86_64. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1641861/+subscriptions
