architecture: 0.655 ppc: 0.653 TCG: 0.644 performance: 0.604 device: 0.574 arm: 0.558 socket: 0.479 semantic: 0.462 network: 0.446 vnc: 0.436 kernel: 0.405 risc-v: 0.399 PID: 0.398 mistranslation: 0.384 graphic: 0.376 register: 0.370 hypervisor: 0.368 permissions: 0.359 VMM: 0.343 boot: 0.342 files: 0.342 assembly: 0.333 debug: 0.312 x86: 0.286 i386: 0.271 virtual: 0.262 peripherals: 0.251 KVM: 0.248 user-level: 0.220 No check for unaligned data access in ARM32 instructions hi According to the ARM documentation, there are alignment requirements of load/store instructions. Alignment fault should be raised if the alignment check is failed. However, it seems that QEMU doesn't implement this, which is against the documentation of ARM. For example, the instruction LDRD/STRD/LDREX/STREX must check the address is word alignment no matter what value the SCTLR.A is. I attached a testcase, which contains a instruction at VA 0x10240: ldrd r0,[pc.#1] in the main function. QEMU can successfully load the data in the unaligned address. The test is done in QEMU 5.1.0. I can provide more testcases for the other instructions if you need. Many thanks. To patch this, we need a check while we translate the instruction to tcg. If the address is unaligned, a signal number (i.e., SIGBUS) should be raised. Regards Muhui We don't implement SCTLR.A, but you're right that we should be checking the mandatory alignments. Note! Any fix will only apply to system mode (qemu-system-arm) and not user-only mode (qemu-arm). Thanks for confirmation. Btw: I was wondering why the fix will only apply to system mode rather than user-only mode. Unaligned data access is not permitted in user level programs, either. Because for user-only, we cheat and use host load/store operations directly. This makes for much faster emulation but imposes a number of limitations -- including ignoring of the alignment bits on hosts that have native unaligned accesses. As a corollary, when running user-only on a host that enforces alignment, you cannot emulate a guest that *allows* unaligned accesses. Proposed patches: https://