graphic: 0.936 peripherals: 0.930 architecture: 0.928 performance: 0.886 files: 0.883 device: 0.882 network: 0.875 semantic: 0.871 register: 0.863 permissions: 0.863 socket: 0.856 vnc: 0.847 assembly: 0.841 user-level: 0.839 arm: 0.834 mistranslation: 0.834 debug: 0.832 ppc: 0.816 hypervisor: 0.810 TCG: 0.809 PID: 0.788 boot: 0.782 i386: 0.768 risc-v: 0.754 virtual: 0.728 VMM: 0.724 x86: 0.718 kernel: 0.700 KVM: 0.601 Incorrect handling of aarch64 ldp in some cases In some cases the ldp instruction (and presumably other multi-register loads and stores) can behave incorrectly. Given the following instruction: ldp x0, x1, [x0] This will load two 64 bit values from memory, however if each location to load is on a different page and the second page is unmapped this will raise an exception. When this happens x0 has already been updated so after the exception handler has run the operating system will try to rerun the instruction. QEMU will now try to perform an invalid load and raise a new exception. I believe this is incorrect as section D.1.14.5 of the ARMv8 reference manual B.a states that, on taking an exception, registers used in the generation of addresses are restored to their initial value, so x0 shouldn't be changed, where x1 can be un an unknown state. I found the issue running FreeBSD with the cortex-strings implementation of memcpy. This uses a similar instruction when copying between 64 and 96 bytes. I've observed this on: QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard And checked I still get the same behaviour on: QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty) Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab On 25 August 2017 at 14:50, Andrew