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
