[Qemu-devel] [Bug 1641861] Re: fail to correctly emulate FPSCR register on arm

[Peter Maydell]

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