Branch: refs/heads/master Home: https://github.com/qemu/qemu Commit: 161dfd1e7fad1203840c0390f235030eba3fd23c https://github.com/qemu/qemu/commit/161dfd1e7fad1203840c0390f235030eba3fd23c Author: Peter Maydell <peter.mayd...@linaro.org> Date: 2018-04-16 (Mon, 16 Apr 2018)
Changed paths: M tcg/mips/tcg-target.inc.c Log Message: ----------- tcg/mips: Handle large offsets from target env to tlb_table The MIPS TCG target makes the assumption that the offset from the target env pointer to the tlb_table is less than about 64K. This used to be true, but gradual addition of features to the Arm target means that it's no longer true there. This results in the build-time assertion failing: In file included from /home/pm215/qemu/include/qemu/osdep.h:36:0, from /home/pm215/qemu/tcg/tcg.c:28: /home/pm215/qemu/tcg/mips/tcg-target.inc.c: In function ‘tcg_out_tlb_load’: /home/pm215/qemu/include/qemu/compiler.h:90:36: error: static assertion failed: "not expecting: offsetof(CPUArchState, tlb_table[NB_MMU_MODES - 1][1]) > 0x7ff0 + 0x7fff" #define QEMU_BUILD_BUG_MSG(x, msg) _Static_assert(!(x), msg) ^ /home/pm215/qemu/include/qemu/compiler.h:98:30: note: in expansion of macro ‘QEMU_BUILD_BUG_MSG’ #define QEMU_BUILD_BUG_ON(x) QEMU_BUILD_BUG_MSG(x, "not expecting: " #x) ^ /home/pm215/qemu/tcg/mips/tcg-target.inc.c:1236:9: note: in expansion of macro ‘QEMU_BUILD_BUG_ON’ QEMU_BUILD_BUG_ON(offsetof(CPUArchState, ^ /home/pm215/qemu/rules.mak:66: recipe for target 'tcg/tcg.o' failed An ideal long term approach would be to rearrange the CPU state so that the tlb_table was not so far along it, but this is tricky because it would move it from the "not cleared on CPU reset" part of the struct to the "cleared on CPU reset" part. As a simple fix for the 2.12 release, make the MIPS TCG target handle an arbitrary offset by emitting more add instructions. This will mean an extra instruction in the fastpath for TCG loads and stores for the affected guests (currently just aarch64-softmmu). Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> Reviewed-by: Richard Henderson <richard.hender...@linaro.org> Acked-by: Michael S. Tsirkin <m...@redhat.com> Message-id: 20180413142336.32163-1-peter.mayd...@linaro.org Commit: aac8f55633f4470e2cb0952bf1a6be3e57d16211 https://github.com/qemu/qemu/commit/aac8f55633f4470e2cb0952bf1a6be3e57d16211 Author: Peter Maydell <peter.mayd...@linaro.org> Date: 2018-04-16 (Mon, 16 Apr 2018) Changed paths: M linux-user/signal.c Log Message: ----------- linux-user/signal.c: Put AArch64 frame record in the right place AArch64 stack frames include a 'frame record' which holds a pointer to the next frame record in the chain and the LR on entry to the function. The procedure calling standard doesn't mandate where exactly this frame record is in the stack frame, but for signal frames the kernel puts it right at the top. We used to put it there too, but in commit 7f0f4208b3a96f22 we accidentally put the "enlarge to the 4K reserved space minimum" check after the "allow for the frame record" code, rather than before it, with the effect that the frame record would be inside the reserved space and immediately after the last used part of it. Move the frame record back out of the reserved space to where we used to put it. This bug shouldn't break any sensible guest code, but test programs that deliberately look at the internal details of the signal frame layout will not find what they are expecting to see. Fixes: 7f0f4208b3a96f22 Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> Reviewed-by: Richard Henderson <richard.hender...@linaro.org> Reviewed-by: Laurent Vivier <laur...@vivier.eu> Message-id: 20180412140222.2096-1-peter.mayd...@linaro.org Compare: https://github.com/qemu/qemu/compare/ae2b1b4e1bb8...aac8f55633f4